ГОСТ Р 34.1984-92 Информационная технология. Взаимосвязь открытых систем. Спецификация протокола базисного класса для передачи и обработки заданий

ГОСТ Р 34.1984-92
(ИСО 8832-89)

Группа П85

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ.
СПЕЦИФИКАЦИЯ ПРОТОКОЛА БАЗИСНОГО КЛАССА
ДЛЯ ПЕРЕДАЧИ И ОБРАБОТКИ ЗАДАНИЙ

Information technology. Open Systems Interconnection.
Specification of Basic Class Protocol for Job Transfer and Manipulation

ОКСТУ 0034

Дата введения 1994-01-01

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. ПОДГОТОВЛЕН И ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационная технология"

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 28.12.92 N 1580

Настоящий стандарт подготовлен методом прямого применения международного стандарта ИСО 8832-89 "Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола базисного класса для передачи и обработки заданий" и полностью ему соответствует

3. ВВЕДЕН ВПЕРВЫЕ

4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Настоящий стандарт распространяется на протоколы виртуального задания базовой эталонной модели взаимосвязи открытых систем (ВОС) и определяет обеспечение протокола базисного, класса с использованием сервисного элемента прикладного уровня для выполнения работы в сети взаимосвязанных открытых систем по концепциям базовой эталонной модели.

ВВЕДЕНИЕ

ВВЕДЕНИЕ

Данный стандарт определяет свойства сервисного элемента прикладного уровня, с помощью которого обеспечивается услуга базисного класса для передачи и обработки заданий (ПОЗ), определенная в стандарте ИСО 8831.

Сервисные элементы прикладного уровня содержат сервисные примитивы, на которые имеются ссылки в других стандартах ВОС, но в большинстве общих случаев эти сервисные примитивы используются реализующими системами средств доставки, которые предназначены для взаимодействия с человеком, с устройствами или программами, разработанными на языках программирования общего назначения. В последнем случае мы считаем, что сервисные примитивы представляются реализующими системами в события, возникающие в реальной области.

Стандартизация таких представлений для определенных специфических устройств и языков программирования не отрицается, но в настоящее время не гарантируется организацией ИСО.

Для того чтобы обеспечить выполнение сервисных примитивов, сервисный элемент прикладного уровня использует услугу уровня представления, возможно с расширенной функцией, при использовании одного или нескольких общих сервисных элементов прикладного уровня, или он использует сервисные примитивы, обеспечиваемые некоторым другим сервисным элементом прикладного уровня.

Сервисный элемент прикладного уровня службы ПОЗ (JTM) содержит сервисные примитивы, на которые могут иметься ссылки из других сервисных элементов прикладного уровня, или которые могут быть представлены с помощью реализующей системы на интерфейсы устройств, человека или на интерфейсы языков программирования. Чтобы обеспечить услугу службы ПОЗ, этот элемент использует услугу уровня представления, которая определена в ГОСТ 34.971, сервисный элемент прикладного уровня для управления ассоциацией, который определен в ГОСТ 34.981, и общий сервисный элемент прикладного уровня для операций совершения действий, параллельности выполнения действий и восстановления при ошибках (элемент СПиВ (CCR) - Commitment, Concurrency and Recovery - Совершение, параллельность и восстановление).

Процедуры элемента СПиВ (CCR) также включаются реализующей системой службы ПОЗ (JTM) для всей активности, когда эта реализующая система выполняет операции доступа к агентствам службы ПОЗ (JTM).

Когда реализующая система принимает вводимый примитив индикации P-DATA, она должна определить, что такое взаимодействие предполагается, чтобы включить эти процедуры в данный стандарт. Эти процедуры представляют контекст прикладного уровня. Этот контекст прикладного уровня называется "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" и устанавливается до передачи элемента передачи службы ПОЗ (JTM), используя услуги, описанные в ГОСТ 34.981.

Когда начинают взаимодействовать две реализующие системы с контекстом типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", необходимо согласовать следующие условия уровня представления:

правила кодирования, которые должны применяться к таким типам данных, абстрактный синтаксис которых определяется в элементе СПиВ (CCR), (используя нотацию АСН.1);

правила кодирования, которые должны применяться к таким типам данных, абстрактный синтаксис которых определяется (используя нотацию АСН.1) в разд.2 данного стандарта, и

правила кодирования, которые должны применяться к таким типам данных, с помощью которых формируются документы, которые должны передаваться службой ПОЗ (JTM).

С помощью таких согласований формируются контексты уровня представления для элемента СПиВ (CCR), для службы ПОЗ (JTM) и для передачи документов. Эти контексты согласовываются при использовании услуги уровня представления. Обязательный набор правил кодирования (который должен обеспечиваться всеми реализующими системами) для контекста службы ПОЗ (JTM) указан в разд.5 данного стандарта, а обязательный набор правил кодирования для контекста уровня представления элемента СПиВ (CCR) указан в стандарте ИСО 9805. Обязательный набор правил кодирования для документов вместе с определением типа документа указан в приложении Б данного стандарта.

В разд.2 данного стандарта описывается абстрактный синтаксис типов данных службы ПОЗ (JTM), использующий нотацию, определенную в ГОСТ 34.973.

В разд.3 данного стандарта описываются процедуры, которым должна следовать реализующая система, когда сервисные примитивы вводятся в контексте прикладного уровня, который включает в себя "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС". (Другой контекст прикладного уровня включает в себя "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", если услуги службы ПОЗ указывают другой стандарт.)

В разд.4 описываются требования, применяемые к реализующей системе службы ПОЗ (JTM) базисного класса, и определяется множество терминов, которые могут использоваться разработчиком для описания соответствующей реализующей системы службы ПОЗ (JTM) базисного класса. В этом разделе также описываются обязательные правила кодирования с помощью ссылки на базисные правила кодирования нотации АСН.1, определенные в ГОСТ 34.974.

В разд.5 описываются правила установления и разъединения ассоциации прикладного уровня, которая должна использоваться для выполнения передачи службы ПОЗ (JTM), и параметры примитивов, используемые для установления такой ассоциации и управления передачей службы ПОЗ (JTM).

Приложение А составляет часть данного стандарта и описывает такие функции локальной системы административного управления, на которые имеются ссылки в процедурах, описанных в разд.3, но детальное описание работы этой локальной системы административного управления не подлежит стандартизации. Предполагается, что многие реализующие системы будут производить значения, возвращаемые такими функциями, которые разработаны пользователем реализующей системы; такое средство требуется (см. п.4.3) для незначительного числа функций.

Приложение Б составляет часть данного стандарта и описывает некоторое количество типов документов, которые предполагается обеспечивать реализующими системами службы ПОЗ (JTM) базисного класса общего назначения.

В приложении В описываются общие свойства некоторого множества тестовых процедур, которые могут применяться к реализующей системе службы ПОЗ (JTM) базисного класса. Предполагается, что с помощью данного приложения можно формировать базу для стандартизации тестовых процедур службы ПОЗ (JTM), но это приложение включено в данный стандарт в качестве предварительного обеспечения.

В приложении Г резюмируется назначение значений OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) и OBJECT DESCRIPTOR (ОПИСАТЕЛЬ ОБЪЕКТА).

В приложении Д представлены консультативные примеры некоторых протокольных последовательностей.

РАЗДЕЛ 1. ОБЩЕЕ ОПИСАНИЕ

1.1. Обзор

Данный стандарт определяет режим, которому должна следовать реализующая система, соответствующая данному стандарту.

В стандарте определены такие понятия, как динамическое согласование и статическое согласование. На данный стандарт могут указываться ссылки из других стандартов ВОС (используя нотацию, указанную в определении услуги службы ПОЗ (JTM)), чтобы можно было использовать процедуры, представленные в данном стандарте.

Данный стандарт должен использоваться разработчиком при разработке соответствующей реализующей системы; на данный стандарт можно ссылаться, когда указываются требования для реализующей системы.

Средства, обеспечиваемые реализующей системой службы ПОЗ (JTM), применимы к любому полю активности, в которой должно иметь место асинхронное перемещение документов.

Данный стандарт не полностью определяет синтаксис передачи, который должен использоваться в частном случае логического соединения, но указывает синтаксис передачи, который требуется для обеспечения всех реализующих систем.

Данный стандарт определяет:

имя контекста прикладного уровня, которое должно использоваться для указания процедур данного стандарта при согласовании контекста прикладного уровня;

имя абстрактного синтаксиса, которое должно использоваться для указания абстрактного синтаксиса элемента передачи службы ПОЗ (JTM). При использовании нотации АСН.1 в данном стандарте указаны данные пользователя элемента СПиВ (CCR) и документы, определенные службой ПОЗ (JTM);

имя синтаксиса передачи, которое должно использоваться для указания синтаксиса передачи, получаемого с помощью применения базисных правил кодирования нотации АСН.1 для абстрактного синтаксиса, указанного при использовании нотации АСН.1.

Стандарт определяет множество функций локальной системы административного управления, которые необходимы для того, чтобы обеспечить работу реализующей системы службы ПОЗ (JTM). Эти функции локальной системы административного управления включаются с помощью сервисного элемента прикладного уровня службы ПОЗ (JTM). Они не моделируются в качестве операций в логическом объекте прикладного уровня и не составляют часть обычных услуг, обеспечиваемых или допускаемых сервисным элементом прикладного уровня службы ПОЗ (JTM). Эти функции представляют собой средства уточнения степени гибкости, которая разрешается или требуется реализующими системами, соответствующими данному стандарту.

1.2. Нормативные ссылки

Следующие стандарты содержат положения, которые с помощью ссылок в тексте составляют положения данного стандарта.

ИСО 8571-3* "Системы обработки информации. Взаимосвязь открытых систем. Передача файлов, доступ к файлам и административное управление файлами. Часть 3. Определение файловых услуг".
________________
* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет ВНИИКИ.

ГОСТ 34.981 (ИСО 8649) "Информационная технология. Взаимосвязь открытых систем. Определение услуг для сервисного элемента управления ассоциацией".

ИСО 8650* "Системы обработки информации. Взаимосвязь открытых систем. Протокольная спецификация для сервисного элемента управления ассоциацией".
________________
* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет ВНИИКИ.

ГОСТ 34.971 (ИСО 8822) "Информационная технология. Взаимосвязь открытых систем. Определение услуг уровня представления, с установлением соединения".

ГОСТ 34.973 (ИСО 8824) "Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)".

ГОСТ 34.974 (ИСО 8825) "Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)".

ИСО 8831* "Системы обработки информации. Взаимосвязь открытых систем. Концепции и услуги для передачи заданий и манипулирования заданиями".

ИС0 9804* "Системы обработки информации. Взаимосвязь открытых систем. Определение услуг для сервисного элемента совершения, параллельности и восстановления".

ИСО 9805* "Системы обработки информации. Взаимосвязь открытых систем. Протокольная спецификация для сервисного элемента "Совершение, параллельность и восстановление".
________________
* До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет ВНИИКИ.

1.3. Определения

Определения - в соответствии со стандартами ИСО 8831* и ГОСТ 34.981 и пп.1.3.1-1.3.17.

1.3.1. Статическое согласование (static conformance) - предложение запроса при обеспечении реализующей системой допустимого множества средств из тех, которые определены данным стандартом.

1.3.2. Динамическое согласование (dynamic conformance) - предложение запроса для реализующей системы придерживаться режима, предписанного данным стандартом для частного случая логического соединения.

1.3.3. Элемент передачи (transfer element) - часть протокольного блока данных службы ПОЗ (JTM), которая используется для передачи информации службы ПОЗ (JTM) (семантики), содержащейся в спецификации работы, между открытыми системами.

1.3.4. Начальная обработка (initial processing) - процедуры, выполняемые реализующей системой службы ПОЗ (JTM) до выдачи сообщения о совершении элементарного действия, которое сформировало спецификацию работы в этой системе.

1.3.5. Отсроченная обработка (deferred processing) - процедуры, выполняемые реализующей системой службы ПОЗ (JTM) по спецификации работы (задержаны в качестве сохраненных данных) после того, как реализующая система приняла на себя ответственность за эту спецификацию работы.

1.3.6. Тип примитива (primitive type) - имя для множества значений.

1.3.7. Абстрактный синтаксис (элемента передачи службы ПОЗ (JTM) или документа) (abstract syntax (of the JTM transfer element or of a document)) - определение типа данных, выполняемое при использовании репертуара типов примитивов и средств для их комбинирования, чтобы определить множество возможных значений элемента передачи или документа таким способом, при котором полностью не определяется представление этого элемента передачи или документа во время передачи.

1.3.8. Нотация для определения абстрактного синтаксиса (notation for abstract syntax definition) - набор правил для определения абстрактного синтаксиса.

1.3.9. Ориентируемый октет (oriented octet) - октет, конечные биты которого поименовываются и различаются, обычно терминами самого старшего и самого младшего бита.

1.3.10. Синтаксис передачи (элемента передачи службы ПОЗ (JTM) или документа) (transfer syntax (of the JTM transfer element or of a document)) - представление элемента передачи службы ПОЗ (JTM) или документа во время передачи, выраженное в качестве значения последовательности ориентируемых октетов.

Примечание. Представление последовательности ориентируемых октетов на параллельных или последовательных каналах связи указывается стандартами нижнего уровня и не относится к сфере службы ПОЗ (JTM).

1.3.11. Правила кодирования (encoding rules) - множество правил, связанных нотацией для определения абстрактного синтаксиса, чтобы включить синтаксис передачи, который должен быть получен для любого типа данных, чей абстрактный синтаксис указывается при использовании этой нотации.

1.3.12. Имя контекста прикладного уровня (application-context name) - имя, которое явно указывает полное множество определений абстрактных синтаксисов (и их семантики), которые должны использоваться во время ассоциации прикладного уровня, и процедуры которых необходимо придерживаться при отправлении или получении этих определений.

1.3.13. Имя абстрактного синтаксиса (abstract syntax name) - имя, которое явно указывает абстрактный синтаксис идентифицируемого набора определений типов данных.

1.3.14. Имя синтаксиса передачи (transfer syntax name) - имя, которое явно указывает правила кодирования для абстрактного синтаксиса.

1.3.15. Локальные функции системы административного управления (local management functions) - функции (внутренние детали работы которых не стандартизованы), которые возвращают значения, с помощью которых формируются значения, определенных полей спецификации работы или которые производят выбор протокола (Полное описание имеется в приложении А данного стандарта.)

1.3.16. Читаемый текст (human-readable text) - текст, полностью поясняющий определенный код диагностического сообщения и предназначенный для чтения и понимания этого сообщения человеком.

Примечание. Язык, на котором выполняется читаемый текст, не определен в данном стандарте. Реализующая система может иметь такую конфигурацию, чтобы можно было выполнить текст на любом из нескольких языков, использующих различные наборы символов. Поля примитивов элемента СПиВ (CCR) используются для указания набора символов и, следовательно, для указания предпочитаемого языка: текст выполняется с помощью идентификации используемого набора символов.

1.3.17. Сервисный элемент прикладного уровня службы ПОЗ (JTM) - абстрактное представление таких частей открытой системы, которые выполняют процедуры, указанные в данном стандарте.

1.4. Сокращения

1.5. Взаимодействие службы ПОЗ (JTM) с другими службами

1.5.1. Архитектура службы ПОЗ (JTM)

Данный стандарт определяет функционирование сервисного элемента прикладного уровня службы ПОЗ (JTM) базисного класса.

Данный сервисный элемент прикладного уровня может функционировать как часть такого логического объекта прикладного уровня, который содержит только сервисный элемент прикладного уровня службы ПОЗ (JTM) базисного класса, сервисный элемент прикладного уровня элемента СПиВ (CCR) и сервисный элемент прикладного уровня сервисного элемента управления ассоциацией. Он может предоставлять свои услуги непосредственно пользователю.

Агентства службы ПОЗ (JTM) являются концептуальной моделью структур и функционирования элемента пользователя.

Сервисный элемент прикладного уровня службы ПОЗ (JTM) базисного класса может также функционировать как часть такого логического объекта прикладного уровня, который содержит другие сервисные элементы прикладного уровня, использующие услуги службы ПОЗ (JTM). Для сервисного элемента прикладного уровня службы ПОЗ (JTM) базисного класса безразлично, кому он предоставляет свои услуги - непосредственно элементу пользователя или некоторым другим сервисным элементам прикладного уровня. Настоящий стандарт определяет требования статического согласования для ситуации, когда сервисный элемент прикладного уровня службы ПОЗ (JTM) базисного класса предоставляет услуги непосредственно элементу пользователя. Если сервисный элемент прикладного уровня службы ПОЗ (JTM) базисного класса используется некоторым другим сервисным элементом прикладного уровня, то требования статического согласования определяются с помощью стандартов, указывающих такой сервисный элемент прикладного уровня, который используется услугами службы ПОЗ (JTM).

1.5.2. Сервисные элементы прикладного уровня службы ПОЗ (JTM) и агентства

Поставщик услуг службы ПОЗ (JTM) представляется совокупностью сервисных элементов прикладного уровня службы ПОЗ (JTM) в логических объектах прикладного уровня. Каждый логический объект прикладного уровня либо не содержит ни одного, либо содержит одно или несколько концептуальных агентств службы ПОЗ (JTM) и один-единственный сервисный элемент прикладного уровня службы ПОЗ (JTM). (Ссылка к единственному сервисному элементу прикладного уровня (статическому) службы ПОЗ (JTM) не препятствует одновременному функционированию нескольких (динамических) экземпляров этого сервисного элемента прикладного уровня для выполнения независимых передач службы ПОЗ (JTM). Система реального компьютера может обеспечивать несколько логических объектов прикладного уровня с одним и тем же сервисным элементом прикладного уровня службы ПОЗ (JTM), а один-единственный логический объект прикладного уровня может моделировать работу нескольких реальных компьютеров. Реальный общепринятый эквивалент агентств службы ПОЗ (JTM) указывается реализующей системой, которая также указывает реальные общепринятые события (которые могут быть географически разнесены) в соответствии с введением сервисных примитивов службы ПОЗ (JTM). В этом случае можно распознавать и тестировать введение сервисных примитивов службы ПОЗ (JTM) в реализующую систему.

Примечание. Если реализующая система соответствует другому стандарту, в котором имеется ссылка на данный стандарт, тогда сервисные примитивы службы ПОЗ (JTM) могут распознаваться с помощью действий, определяемых другим стандартом.


Сервисные примитивы прикладного уровня службы ПОЗ (JTM) совместно обрабатывают спецификацию работы (созданную в результате обработки примитива J-INITIATE, уведомления или порождения). Ответственность за выполнение спецификации работы всегда принадлежит непосредственно одному сервисному элементу прикладного уровня службы ПОЗ (JTM). Эта ответственность передается при отправлении элемента "Элемент передачи" (спецификация работы в определенной синтаксической форме) от одного сервисного элемента прикладного уровня службы ПОЗ (JTM) другому в качестве элементарного действия.

Сервисный элемент прикладного уровня службы ПОЗ (JTM), который несет ответственность за спецификацию работы, содержит достаточную информацию о качестве сохраненных данных для полного определения этой спецификации работы. Отметим, что спецификация работы является семантической конструкцией и может быть сохранена в локальной системе любым способом.

1.5.3. Использование услуги уровня представления

При взаимодействии сервисных элементов прикладного уровня службы ПОЗ (JTM) используется тип данных, который называется "Элемент передачи", абстрактный синтаксис и семантика которого полностью определены в данном стандарте. Этот элемент передается, используя синтаксис передачи, определенный при согласовании уровня представления.

Полный элемент передачи вместе с каким-либо соответствующим документом передается с помощью использования одного примитива P-DATA. Этот примитив вводится во время ассоциации прикладного уровня. Эти сервисные примитивы для установления и использования ассоциации прикладного уровня определены в ГОСТ 34.981 и в ГОСТ 34.971, а их использование описывается в разд.5.

Следует отметить, что помимо использования элемента СПиВ (CCR) для гарантирования надежности и возврата диагностических сообщений передача службы ПОЗ (JTM) в базисном классе имеет простой характер. Он состоит только в передаче примитива P-DATA в одном направлении.

1.5.4. Использование сервисного элемента прикладного уровня сервисного элемента управления ассоциацией

Сервисный элемент прикладного уровня сервисного элемента управления ассоциацией используется для установления и завершения использования ассоциации прикладного уровня в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС".

Сервисные примитивы для выполнения этой работы указаны в ГОСТ 34.981, а их использование указано в разд.5.

Требования локального планирования могут вызвать отказ от контекста типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" (или взаимосвязи, лежащей в основе уровня представления). Позднее, восстановление при ошибках (повторная синхронизация) выполняется при использовании примитива C-RESTART в новом контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", установленного между теми же самыми логическими объектами прикладного уровня.

При завершении активности службы ПОЗ (JTM) во время ассоциации эта ассоциация остается для использования примитивов сервисного элемента прикладного уровня сервисного элемента управления ассоциацией.

1.5.5. Использование сервисного элемента прикладного уровня элемента СПиВ (CCR)

Сервисный элемент прикладного уровня службы ПОЗ (JTM) использует сервисный элемент прикладного уровня элемента СПиВ (CCR) для взаимосвязи:

а) с другими сервисными элементами прикладного уровня службы ПОЗ (JTM), используя услугу уровня представления с сервисными примитивами элемента ПОЗ (CCR); и

б) с агентствами службы ПОЗ (JTM), используя сервисные примитивы типа J-, которые включают в себя семантику элемента СПиВ (CCR).

В любой момент времени, по крайней мере, одна из взаимосвязей относится к управляющему логическому объекту элемента СПиВ (CCR) сервисного элемента прикладного уровня службы ПОЗ (JTM), а остальные взаимосвязи относятся к управляемому логическому объекту элемента СПиВ (CCR). Процедуры этого элемента СПиВ (CCR) (определенные в терминах всех полученных или введенных примитивов элемента СПиВ (CCR)) применяются для полной активности сервисного элемента прикладного уровня службы ПОЗ (JTM).

Применение процедур этого элемента СПиВ (CCR) через использование общего сервисного элемента прикладного уровня гарантирует надежную передачу ответственности за спецификацию работы и совместимость выполнения операции.

Примитивы элемента СПиВ (CCR) также обеспечивают возврат диагностической информации при отказах на выполнение начальной обработки. (После начальной обработки при отказе диагностическая информация возвращается с помощью механизмов выполнения уведомлений службы ПОЗ (JTM).

И наконец, примитивы элемента СПиВ (CCR) обеспечивают (дополнительно) передачу информации, которая может использоваться реализующей системой для того, чтобы решить, когда повторить попытку выполнения посылки элемента передачи другому логическому объекту службы ПОЗ (JTM) или когда отказаться от попытки обработать полученный элемент передачи во время начальной обработки и возвратиться к совершению операции на более низком уровне совершения операций.

Данный стандарт не требует, чтобы сервисный элемент прикладного уровня службы ПОЗ (JTM) обеспечивал эту временную информацию для удаленного сервисного элемента прикладного уровня службы ПОЗ (JTM), поэтому сервисный элемент прикладного уровня службы ПОЗ (JTM) должен быть подготовлен к выбору соответствующего локального алгоритма при отсутствии информации.

Примечание. Соответствующий алгоритм должен быть таким, чтобы выполнялась попытка передачи в возрастающих по экспоненте интервалах времени в течение нескольких дней, затем принять во внимание попытку, при которой имел место отказ, и вызвать процедуры обработки ошибок службы ПОЗ (JTM).

1.5.6. Сервисные примитивы, на которые имеются ссылки в данном стандарте

Сервисными примитивами, которые вызывают процедуры службы ПОЗ (JTM), являются:

а) примитив индикации P-DATA в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", содержащий значение данных в контексте уровня представления службы ПОЗ (JTM);

б) примитив запроса J-INITIATE-WORK;

в) примитив запроса J-INITIATE-WORK-MAN;

г) примитив запроса J-END-SIGNAL;

д) примитив запроса J-MESSAGE;

е) все примитивы индикации и подтверждения элемента СПиВ (CCR) в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС";

ж) примитивы индикации и подтверждения A-ASSOCIATE, A-P-ABORT, A-ABORT и A-RELEASE (cм. п.3.3.4).

Сервисными примитивами, вызываемыми процедурами службы ПОЗ (JTM), являются:

а) примитив запроса P-DATA в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС";

б) примитивы индикации и ответа J-DISPOSE;

в) примитивы индикации и ответа J-GIVE;

г) примитив индикации J-STATUS;

д) примитив индикации J-KILL;

е) примитив индикации J-STOP;

ж) все примитивы запроса и ответа элемента СПиВ (CCR);

з) примитивы запроса и ответа A-ASSOCIATE, A-ABORT, A-RELEASE (см. п.3.3.4).

1.5.7. Краткое описание архитектуры службы ПОЗ (JTM)

Архитектура службы ПОЗ (JTM) представлена на черт.1.

Черт.1. Архитектура верхних уровней службы ПОЗ (JTM)

Архитектура верхних уровней службы ПОЗ (JTM).
Реальные устройства и интерфейсы, моделируемые элементом пользователя
(агентства службы ПОЗ (JTM).

Сервисные примитивы типа J-

Черт.1

Отметим, что в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС"

а) сервисные примитивы типа Р-, содержащие значения данных в контексте уровня представления элемента СПиВ (CCR), распознаются только как сервисные примитивы типа С-;

б) сервисные примитивы типа Р-, содержащие значения данных в контексте службы ПОЗ (JTM) и в контексте уровня представления документов, распознаются как примитив P-DATA;

в) сервисные примитивы типа Р-, содержащие значения данных в контексте уровня представления сервисного элемента прикладного уровня сервисного элемента управления ассоциацией, служат для установления или завершения использования контекста типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС".

1.6. Согласование

1.6.1. Описание в п.1.5 представлено в качестве основы. В п.1.5 не представлены требования по согласованию. Если описание, представленное в п.1.5, расходится с описанием, представленным в других пунктах, предпочтение отдается описанию в этих других пунктах.

1.6.2. Динамическое согласование описывается в разд.3 и 5, в которых используются определения типов данных, представленных в разд.2.

1.6.3. Статическое согласование описывается в разд.4.

РАЗДЕЛ 2. ТИПЫ ДАННЫХ СЛУЖБЫ ПОЗ (JTM)

2.1. Введение в определения типов данных службы ПОЗ (JTM)

В данном разделе определяются типы данных службы ПОЗ (JTM). Здесь используется нотация стандарта ГОСТ 34.973 (нотация АСН.1) для определения абстрактного типа данных "Элемент передачи", который формирует часть или весь протокольный блок данных службы ПОЗ (JTM). (Остальная часть протокольного блока данных, если она имеется, представляет собой документ, абстрактный синтаксис которого определяется в другом месте.)

В данном разделе также определяется абстрактный синтаксис типов данных, с помощью которого формируются параметры данных пользователя для примитивов элемента СПиВ (CCR), используемых службой ПОЗ (JTM).

В данном разделе указывается только абстрактный синтаксис и не указываются правила кодирования для формирования синтаксиса передачи.

В п.2.2 определяются типы данных, используемые при поименовании (они появляются повсюду в дальнейших определениях) и для читаемых сообщений.

В п.2.3 определяются типы данных, используемые для диагностических сообщений и для учетной информации.

В п.2.4 определяются типы данных, используемые для параметров данных пользователя примитивов элемента СПиВ (CCR).

В п.2.5 определяется тип данных, который называется "Элемент передачи". Услуга службы ПОЗ (JTM) обеспечивается с помощью формирования, передачи и обработки спецификаций работы. Спецификация работы базисного класса (понятие семантики) представляется во время передачи в качестве элемента "Элемент передачи" вместе с одним документом или без документа. В п.2.5 определяется полная структура данных элемента "Элемент передачи" для всех типов CHOICE (ВЫБОРОЧНЫЙ ТИП), которые используются в базисном классе, предоставляющем абстрактный синтаксис и ограничения, накладываемые на семантику во время передачи. Должен быть создан элемент такого средства, а само это средство, которое должно работать при приеме, описывается в разд.3.

В п.2.6 определяются типы данных "Документ отображения работы" и "Документ отображения уведомления". Эти типы данных формируются поставщиком услуг службы ПОЗ (JTM), как это описано в разд.3, и являются документами, которые определяются только службой ПОЗ (JTM) и используются в базисном классе.

В п.2.7 повторяется описание определений типов данных, представленных в пп.2.2-2.6, и эти определения предназначены для машинной обработки. Если в описаниях встречаются отличия, то более предпочтительным является описание в пп.2.2-2.6.

2.2. Имена и сообщения

2.2.1. Глобальные имена

ИСО 8831 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Имя службы ПОЗ (JTM) ::=

Символическое имя логического объекта прикладного уровня
Санкция идентификации пользователя ::=

Символическое имя логического объекта прикладного уровня
Символическое имя логического объекта прикладного уровня ::=

ИСО 8650 "Сервисный элемент управления ассоциацией - 1.
Символическое имя логического объекта прикладного уровня"

КОНЕЦ

Примечания:

1. Представленная выше ссылка в модуле использует определение синтаксиса символических имен логических объектов прикладного уровня, представленное в стандарте ИСО 8650. Тип данных и соответствующие значения данных включаются в определение абстрактного синтаксиса службы ПОЗ (JTM), т.е. нужно сказать, что значения этих типов данных передаются в контексте уровня представления, установленном для протокольных блоков данных службы ПОЗ (JTM).

2. Символические имена логических объектов прикладного уровня являются явными и обеспечиваются указательными функциями, которые представляют эти имена в качестве адресной информации.


Экземпляры таких типов данных представляют следующие назначения взаимосвязей всех открытых систем, использующих данный стандарт:

а) данный параметр "Имя службы ПОЗ (JTM)" должен использоваться для операции передачи службы ПОЗ (JTM), локальные указательные функции используются, чтобы сформировать адресную информацию для разрешенных передач службы ПОЗ (JTM), которые должны выполняться в отношении сервисного элемента прикладного уровня службы ПОЗ (JTM); этот сервисный элемент прикладного уровня службы ПОЗ (JTM) упоминается, чтобы имелось соответствие с данным именем: это соответствие не зависит от сервисного элемента прикладного уровня службы ПОЗ (JTM), с помощью которого выполняется передача;

б) эта адресная информация, обеспечиваемая при поступлении запроса, может быть достаточной, чтобы определить или проверить, что данный запрос был выполнен соответствующим сервисным элементом прикладного уровня службы ПОЗ (JTM);

в) экземпляр параметра "Санкция идентификации пользователя" соответствует одному исходному агентству из множества идентификаций пользователей среди взаимодействующих систем; центральная или распределенная санкция гарантирует, что такая явность поименования является управляемой;

г) не накладывается никаких требований на значения этих двух типов данных, которые должны отличаться; одно и то же значение может быть использовано и для параметра "Имя службы ПОЗ (JTM)", и для параметра "Санкция идентификации пользователя", если это удобно для администрации какой-либо организации.

2.2.2. Имена, локальные по отношению к сервисному элементу прикладного уровня службы ПОЗ (JTM)

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Имя агентства ::=

Графическая строка

КОНЕЦ

Каждое исполняющее агентство, принимающее агентство и исходное агентство службы ПОЗ (JTM) ассоциируется, по крайней мере, с одним элементом типа данных "Имя агентства". Элемент этого типа данных ассоциируется только с одним агентством, доступным с помощью определенного сервисного элемента прикладного уровня службы ПОЗ (JTM).

Сервисный элемент прикладного уровня службы ПОЗ (JTM) использует локальные указательные функции, чтобы у него была возможность ввести сервисные примитивы типа "J" - в поименованное агентство. Локальная указательная информация определяет, является ли это агентство исходным, принимающим или исполняющим.

2.2.3. Имена, локальные по отношению к элементу "Санкция идентификации пользователя"

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Идентификация пользователя ::=

Графическая строка

КОНЕЦ

Санкция активности, вызванной через службу ПОЗ (JTM), основывается на аутентификации идентификаций пользователей. Чтобы идентифицировать множество допустимых активностей, имя, указанное параметром "Идентификация пользователя", используется внутри имени, указанного параметром "Санкция идентификации пользователя".

Каждый сервисный элемент прикладного уровня службы ПОЗ (JTM) включается в конфигурацию, чтобы была возможность распознавать один или несколько элементов типа "Санкция идентификации пользователя" (обычно один элемент). Он содержит локальную указательную информацию, которая доступна ему при определении допустимых активностей для некоторых или всех параметров "Идентификация пользователя", введенных с помощью этих параметров "Санкция идентификации пользователя". Значение элемента "Санкция идентификации пользователя" может быть известно только в одной-единственной открытой системе. В этом случае все соответствующие указатели являются локальными по отношению к такой открытой системе. Если определенный элемент "Санкция идентификации пользователя" известен нескольким открытым системам, то в каждой открытой системе необходима другая указательная информация и должны использоваться протоколы для проверки паролей удаленной системы.

Примечание. Идентификации пользователей и соответствующие указатели для аутентификации и санкции обычно являются параллельными механизмами, обеспеченными в большинстве вычислительных систем. Дополнительными требованиями, которые относятся к сетевой обработке, являются определение местоположения явных имен для санкций идентификации пользователей и классификация при распределении указательной информации, если одна и та же идентификация пользователя должна использоваться в нескольких открытых системах.

2.2.4. Списки имен

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Список имен ::=

ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Графическая строка

КОНЕЦ

Тип данных "Список имен" используется для идентификации документов как передаваемых к исходным, принимающим и исполняющим агентствам службы ПОЗ (JTM), так и принимаемых от них.

2.2.5 Имена контекстов

Данный пункт определяет имена, которые должны использоваться для:

а) имен контекстов и прикладного уровня, которые используются в сервисных примитивах A-ASSOCIATE, для того чтобы установить использование ассоциации для таких процедур, которые указаны в данном стандарте;

б) имени абстрактного синтаксиса для всех типов данных, определенных в данном стандарте, описание которых собрано в п.2.7;

в) имени синтаксиса передачи для таких типов данных, которые получаются с помощью применения основных правил кодирования нотации АСН.1 (см. ГОСТ 34.974).

При указании этих имен используются следующие определения значений нотации АСН.1:

ИДЕНТИФИКАТОР ОБЪЕКТА службы ПОЗ (JTM)

ГОСТ Р 34.1984

Параметр "Описатель объекта" установлен в стандарте "Базисный класс службы ПОЗ (JTM) модели ВОС".

Примечание. Определение значения параметров "Описатель объекта" и "ИДЕНТИФИКАТОР ОБЪЕКТА" нотации АСН.1 разрешает, но это не обязательно, трансляцию значений параметра "Описатель объекта" и идентификаторов в значения типа "ИДЕНТИФИКАТОР ОБЪЕКТА", если стандарт, определяющий такие значения, транслируется на другой язык.

2.2.5.1. Контексты прикладного уровня

Реализующая система базисного класса распознает два типа параметров "Имя контекста прикладного уровня". Первый тип идентифицирует процедуры данного стандарта и имеет следующие значения параметров "ИДЕНТИФИКАТОР ОБЪЕКТА" и "Описатель объекта" нотации АСН.1:

{Контекст прикладного уровня службы ПОЗ (JTM) (1) Базисный (1)}

"Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС".

Второй тип идентифицирует полностью процедуры службы ПОЗ (JTM) и имеет следующие значения нотации АСН.1:

{Контекст прикладного уровня службы ПОЗ (JTM) (1) Полный (2)}

"Полный контекст прикладного уровня службы ПОЗ (JTM) модели ВОС".

2.2.5.2. Абстрактный синтаксис

Значениями данных уровня представления, принимаемых или передаваемых системами базисного класса (помимо тех, которые указаны сервисным элементом управления ассоциацией и сервисными элементами прикладного уровня элемента СПиВ (CCR) являются либо:

а) значения элемента "Элемент передачи" типов данных нотации АСН.1, определенного в п.2.5; или

б) значения типов данных нотации АСН.1:

C-BEGIN-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ;

C-READY-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ;

C-REFUSE-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ;

C-RESTART-RI-ДAHHЫE ПОЛЬЗОВАТЕЛЯ;

C-RESTART-RC-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ,

которые определены в п.2.4; или

в) значения данных уровня представления, указанные в определении типа документа.

Значения данных уровня представления типа, указанного в перечислении в), должны передаваться в контексте (контекстах) уровня представления, установленном из имени (имен) абстрактного синтаксиса, указанного в определении типа документа (см. приложение Б для типов документов, определенных в данном стандарте).

Значения данных уровня представления типов, указанных в перечислениях а) и б), должны передаваться в контексте уровня представления, установленном при использовании абстрактного синтаксиса, определяемого с помощью следующих значений параметров "ИДЕНТИФИКАТОР ОБЪЕКТА" и "Описатель объекта" нотации АСН.1:

{Абстрактный синтаксис службы ПОЗ (JTM) (2)};

"Абстрактный синтаксис службы ПОЗ(JTM) модели ВОС".

Примечание. Определения типов документов для документов типа "Отображение работы" и "Отображение уведомления" также используют это имя абстрактного синтаксиса.

2.2.5.3. Синтаксис передачи

При согласовании синтаксиса передачи для абстрактного синтаксиса типа "Абстрактный синтаксис службы ПОЗ (JTM) модели ВОС", указанного в п.2.2.5.2, следующие определения нотации АСН.1 должны использоваться для указания такого синтаксиса передачи, который переводится с помощью применения ГОСТ 34.974 (Основные правила кодирования нотации АСН.1) в типы данных, определенных в данном разделе:

{Синтаксис передачи службы ПОЗ (JTM) (3)};

"Синтаксис передачи службы ПОЗ (JTM) модели ВОС".

В данном стандарте не определены другие синтаксисы передачи. Другие синтаксисы передачи для параметра "Абстрактный синтаксис службы ПОЗ (JTM) модели ВОС" могут быть определены и поименованы другими организациями и могут использоваться при согласовании контекста уровня представления (см. п.1.3.10).

2.2.6. Читаемые сообщения

Сообщения такого типа используются для того, чтобы пользователь имел возможность прочитать диагностическую информацию.

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Сообщение ::=

ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Графическая строка

КОНЕЦ

Последовательность должна содержать один или несколько элементов, и каждый элемент "Графическая строка" должен содержать от 0 до 40 символов.

Имеется в виду, что каждый элемент "Графическая строка" в параметре "Сообщение" должен быть представлен для человека на отдельной строке. Общая длина параметра "Сообщение" не имеет ограничений.

Наборы графических символов, используемых в типе данных "Сообщение", должны содержать только такие символы, которые перечислены в одном из параметров "Указатель кода" параметра "Индикатор кода диагностического сообщения" элемента СПиВ (CCR) для элементарного действия, или символы, указанные ГОСТ 27463 (см. п.2.4).

Примечания:

1. Требование обеспечения ГОСТ 27463 является предметом изменения национальных стандартов, которые эквивалентны данному стандарту.

2. Если общая работа вызывает несколько элементарных действий, поставщик услуг оставляет параметр "Код диагностического сообщения" элемента СПиВ (CCR) для использования в последующих элементарных действиях.

2.3. Диагностические сообщения

2.3.1. Коды диагностических сообщений службы ПОЗ (JTM)

Служба ПОЗ (JTM) указывает тип данных для параметра "Код" в диагностическом сообщении элемента СПиВ (CCR). Такой спецификацией является:

ИСО 8831 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

КОНЕЦ

Параметр "Код пользователя службы ПОЗ (JTM)" будет иметь вид "ВЫБОРОЧНЫЙ ТИП "Отсутствует"" до тех пор, пока на данный стандарт имеются ссылки в других стандартах, которые определяют абстрактный синтаксис и, возможно, синтаксис передачи для вложенного контекста типа "Определяется пользователем".

Примечания:

1. В разд.3 описываются условия, при которых формируется каждый из этих кодов ошибки. Символы "оу" означают "Отказы Услуги", символы "оп" означают "Ошибки Пользователя", символы "дп" означают "Действия Пользователя", символы "пп" означают "Повторить Позже" и символ "п" означает "Предупреждающее сообщение".

2. При дальнейшей доработке данного стандарта, вероятно, расширится ряд кодов, которые может принимать реализующая система базисного класса. Следовательно, реализующие системы должны иметь возможность допускать дополнительные значения помеченного типа НУЛЬ. Если реализующая система преобразует код службы ПОЗ (JTM) для использования человеком, то код, интерпретация которого неизвестна, должен быть представлен в таком виде, чтобы допустить используемую метку, которая должна быть идентифицирована.


Данные такого типа являются вложенными в данные типа "Диагностическое сообщение элемента СПиВ (CCR)", определенные в п.2.2.

2.3.2. Диагностические сообщения элемента СПиВ (СCR)

Диагностические сообщения элемента СПиВ (CCR) содержатся в данных пользователя примитивов элемента СПиВ (CCR) (см. п.2.4), в диагностических сообщениях службы ПОЗ (JTM), в уведомлениях (см. п.2.5.7) и диагностических сообщениях, вложенных в элементы "Элемент передачи" (см. п.2.5.5).

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

- одно или несколько значений в МНОЖЕСТВЕ ИЗ -}}

КОНЕЦ

2.4. Данные пользователя в примитивах элемента СПиВ (CCR)

Эти типы данных должны иметь значения, которые используются службой ПОЗ (JTM) для полей данных пользователя, описанных в качестве типа "ВНЕШНИЙ" в стандарте ИСО 9805.

2.4.1. Данные пользователя в примитивах запроса и индикации

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

C-BEGIN-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ ::= МНОЖЕСТВО

{Уровень совершения операций [0] ЦЕЛОЧИСЛЕННЫЙ ТИП,

Индикатор кода диагностического сообщения [1] ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ

- ни одного, одно или несколько значений в элементе

"ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Указатель кода" -}

Указатель кода ::= ВЫБОРОЧНЫЙ ТИП

Реализующая система будет формировать "Сообщения" (см. п.2.2.6), используя только такие графические символы, которые указаны в любом каком-либо одном из указателей "Указатель кода", или используя только такие графические символы, которые представлены в ГОСТ 27463.

Значение "ВЫБОРОЧНЫЙ ТИП" параметра "Любые символы" позволяют использовать любые наборы символов. Значение "ЦЕЛОЧИСЛЕННЫЙ ТИП" в параметре "Наборы кодов" указывает элемент реестра с таким номером в реестре наборов символов ИСО и разрешает использование всех символов, зарегистрированных с таким номером элемента.

Уровень совершения операций определяется в стандарте ИСО 8831 и может принимать только значения ПРИНЯТИЕ АГЕНТСТВОМ и ПРИНЯТИЕ ПОСТАВЩИКОМ. В разд.3 описываются процедуры, относящиеся к уровню совершения операций.

2.4.2. Данные пользователя в примитивах запроса и индикации C-READY

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

C-READY-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ ::= МНОЖЕСТВО

Параметр "Учетная информация", если он присутствует при вводе примитива индикации C-READY в реализующую систему базисного класса, должен игнорироваться. Этот параметр не должен присутствовать, если реализующей системой базисного класса вводится примитив запроса C-READY.

Примечание. Для разрешения использования данного параметра и его обработки предполагается доработка данного стандарта в части обеспечения согласования его использования и формирования в соответствии со стандартом для реализации службы ПОЗ (JTM) расширенного класса.


Поле "Уровень совершения операций" может принимать все значения, включая "ЗАВЕРШЕНИЕ".

2.4.3. Данные пользователя в примитивах запроса и индикации C-REFUSE

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

C-REFUSE-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ ::= МНОЖЕСТВО

Текст, представленный в п.2.4.2, должен применяться в поле "Учетная информация".

2.4.4. Данные пользователя в примитивах запроса и индикации C-PREPARE

Службой ПОЗ (JTM) данный примитив не используется.

2.4.5. Данные пользователя в примитивах запроса и индикации C-RESTART

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

C-RESTART-RI-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ ::= НУЛЬ

КОНЕЦ

2.4.6. Данные пользователя в примитивах ответа и подтверждения C-RESTART

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

C-RESTART-RC-ДАННЫЕ ПОЛЬЗОВАТЕЛЯ ::=

Значение "ВЫБОРОЧНЫЙ ТИП" должно в зависимости от идентификатора нотации АСН.1 соответствовать значению параметра указателя возобновления выполнения элемента СПиВ (CCR).

Текст, представленный в п.2.4.2, должен применяться в поле "Учетная информация".

2.5. Элементы передачи

Определяется структура синтаксиса и указываются ограничения, накладываемые на семантику для элемента "Элемент передачи". Идентификация полей этого типа данных используется для идентификации соответствующих полей в спецификации работы.

При передаче, выполняемой службой ПОЗ (JTM), как это описано в разд.3, используется один-единственный примитив P-DATA (в пределах элементарного действия элемента СПиВ (CCR), содержащий в своем параметре "Данные пользователя" следующие значения данных уровня представления:

а) значение типа данных элемента "Элемент передачи";

за ним необязательно следуют

б) значения данных уровня представления, указанные в определении типа документа, для содержания семантик единственного документа.

Примечание. В базисном классе службы ПОЗ (JTM) каждая спецификация работы содержит, самое большее, один документ, поэтому вопросы, как отличить конец одного документа от начала следующего, не возникают.

2.5.1. Поля верхнего уровня

2.5.1.1. Определения синтаксиса

ГОСТ Р 34.1.984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Элемент передачи ::= [ПРИКЛАДНОЙ КЛАСС 0]

Следующие типы данных определены в дальнейших подпунктах:

Идентификация (см. п.2.5.4);

штамп времени (см. п.2.5.5);

проверочный элемент (см. п.2.5.2);

спецификация монитора (см. п.2.5.3);

элемент санкционирования (см. п.2.5.4);

элемент разрешения (см. п.2.5.4);

операции по перемещению документа (см. п.2.5.5);

операции по манипулированию работой (см. п.2.5.6);

операция по перемещению уведомления (см. п.2.5.7).

Спецификация работы содержит параметры:

<Время ожидания=I>

<Подсчитанный размер=1>

<Параметры активности агентства>

Эти значения не передаются между открытыми системами в элементе передачи, поэтому соответствующие поля не обеспечиваются.

Спецификация работы также содержит параметр

<Параметры элемента СПиВ (CCR)>,

учитывающий значение, используемое для параметра "Индикатор кода диагностического сообщения" элемента СПиВ (CCR).

И наконец, спецификация работы может (но необязательно) содержать документ, который передается в качестве дополнительного значения в примитиве P-DATA.

Когда при выполнении спецификации работы ожидается примитив J-END-SIGNAL, то самый последний параметр "Спецификация подзадания" имеет нулевое значение.

2.5.1.2. Ограничения, накладываемые на семантику

Следующие ограничения применяются во время передачи элемента "Элемент передачи":

а) значение параметра "Имя службы ПОЗ (JTM) системы предъявления задания модели ВОС" должно быть равно значению первого элемента "Имя службы ПОЗ (JTM)" в параметре "Проверочная трасса" (см. п.2.5.2);

б) значение параметра "Ограничивающее целое число" в параметре "Список имен подзаданий" должно быть больше единицы или равно единице;

в) значение параметров "Тип подзадания" и "Параметры действия службы ПОЗ (JTM)" должно быть одним из следующих пар: "Перемещение документа", "Операции по перемещению документа"; "Манипулирование работой", "Операции по манипулированию работой"; "Перемещение уведомления", "Операции по перемещению уведомления";

г) параметр "Тип подзадания" в спецификации, указанной параметром "Спецификация подзадания" и параметром "Проформа", не должен иметь значение "Перемещение уведомления" и не должен иметь значение "Манипулирование работой";

д) если значением параметра "Тип подзадания" в элементе "Элемент передачи" является "Перемещение уведомления", то параметр "Список проформ" должен иметь вид "{ }" и в примитиве P-DATA не должно быть в дальнейшем значений типа данных;

е) все элементы параметров "Санкционирование" и "Разрешения" должны отличаться от других значений;

ж) параметр "Список проформ" верхнего уровня должен представлять собой либо "{ }", либо последовательность, содержащую одну-единственную проформу, указанную параметром "Проформа";

з) если проформа, указанная параметром "Проформа", представлена в элементе "Элемент передачи", то в этой проформе не должно быть "вложенного" выборочного типа какого-либо указателя типа "Указатель документа" (см. п.2.5.5);

и) примитив P-DATA должен содержать за элементом "Элемент передачи", по крайней мере, одно значение (документ).

2.5.2. Проверочные элементы

2.5.2.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Проверочный элемент ::= ПОСЛЕДОВАТЕЛЬНОСТЬ

2.5.2.2. Ограничения, накладываемые на семантику

Во время выполнения передачи значение последнего элемента "Проверочный элемент" должен иметь параметр "Состояние" со значением "Неизвестно". Установка и использование других значений параметра "Проверочный элемент" указаны в разд.3.

2.5.3. Спецификация монитора

2.5.3.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Следующие типы данных определяются в дальнейших пунктах:

идентификация "пи" (см. п.2.5.5);

указатель "пи" документа (см. п.2.5.5).

Примечание. Символы "пи" означают "Принимающее и Исполняющее агентство".

2.5.3.2. Ограничения, накладываемые на семантику

Параметр "Селектор уведомления" должен представлять строку битов, длина которой выбирается отправителем. Какой-либо бит в этой строке битов не должен устанавливаться в 1, если он не является одним из битов, поименованных в определении нотации АСН.1.

Если значение параметра "Системное имя монитора" представляет реализующую систему базисного класса, то значение параметра "Команды для размещения" должно стать значением параметра "Данные для размещения".

Примечание. Значение "Сохранить НУЛЬ" присутствует только в элементах передачи базисного класса, которые представляются в реализующих системах расширенного типа.

2.5.4. Элементы санкционирования и разрешения

2.5.4.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

2.5.4.2. Ограничения, накладываемые на семантику

Проверяемый индекс должен быть ненулевым положительным целым числом и не должен содержать значение большее, чем количество полей "Проверочный элемент" в параметре "Проверочная трасса", представляя первое такое поле с номером "1".

2.5.5. Операции по перемещению документа

2.5.5.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

2.5.5.2. Ограничения, накладываемые на семантику

Количество обнаруженных значений "Вложенный ВЫБОРОЧНЫЙ ТИП" для параметра "Указатель документа" должно точно соответствовать количеству значений в примитиве P-DATA, следующих за элементом "Элемент передачи". Каждое такое значение представляет собой документ. (В базисном классе имеет место, самое большее, один документ).

Тип документа должен быть согласован со значением параметра "Тип документа", представленным в параметре "Перемещение документа", содержащем значение "Вложенный ВЫБОРОЧНЫЙ ТИП" в параметре "Указатель документа".

Параметр "Операции по перемещению документа" должен содержать только одно значение "Перемещение документа", а параметр "пи агентства" должен содержать только одно значение "Идентификация пи".

Если параметр "Указатель пи документа" находится в спецификации, указанной параметром "Спецификация монитора", то параметр "Параметр доступа к пи" должен иметь значение "Дополнительный". Если параметр "Указатель пи документа" имеет значение "Единый формат", то параметр "Параметр доступа к пи" должен иметь значение "Нормальный".

Значение "ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Указатель документа" в формате "Единый формат" должно содержать единственный элемент "Указатель документа". Если в спецификации подзадания внешнего уровня спецификации работы целевая система представляет собой сервисный элемент прикладного уровня службы ПОЗ (JTM), то результатом перемещения одного документа будет либо значение "Отказано" в параметре "Состояние", либо следующее сформированное значение:

где t - экземпляр множества значений элемента "Тип документа" для следующих типов:

{Простой текстовый документ службы ПОЗ (JTM) модели ВОС} или

{Простой печатный документ службы ПОЗ (JTM) модели ВОС}, или

{Документ отображения работы службы ПОЗ (JTM) модели ВОС};

n - экземпляр типа "Графическая строка", используемый принимающей открытой системой в качестве имени принимающего или исполняющего агентства;

d - любое значение типа "Список имен".

2.5.5.2.1. В проформе элемента передачи манипулирования работой

Параметр "Перемещение документа" в проформе, указанной параметром "Проформа", которая находится в элементе "Элемент передачи" с параметрами "Параметр действия службы ПОЗ (JTM)", которые имеют значение "Операция по манипулированию работой" и для которых целевой системой является этот сервисный элемент прикладного уровня службы ПОЗ (JTM), должен иметь значение:

где n - любое значение типа "Графическая строка";

d - любое значение типа "Список имен";

w - равно значению параметра "Имя службы ПОЗ (JTM)" целевой системы верхнего уровня в элементе "Элемент передачи";

s - тип "Графическая строка" со значением "ОТОБРАЖЕНИЕ".

2.5.5.2.2. В проформе элемента передачи перемещения документа

Параметр "Перемещение документа" в проформе, указанной параметром "Проформа", которая находится в элементе "Элемент передачи" с параметрами "Параметр действия службы ПОЗ (JTM)", которые имеют значения "Операции по перемещению документа", будет иметь любое значение.

2.5.6. Операции по манипулированию работой

2.5.6.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

2.5.6.2. Ограничения, накладываемые на семантику

Значениями параметра "Операция по манипулированию работой" должно быть одно из следующих:

где y - тип "Графическая строка" со значением "ОТОБРАЖЕНИЕ";

x - экземпляр параметра "Селектор" со значением {Формат селектора Первый заголовок имеется НУЛЬ, и предложение

где p - любой элемент типа "Имя службы ПОЗ (JTM)";

q - любой элемент типа "Графическая строка";

r - любой элемент типа "Тип подзадания".

2.5.7. Операция по перемещению уведомления

2.5.7.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Операция по перемещению уведомления ::=

2.5.7.2. Ограничения, накладываемые на семантику

Параметры "Указатель монитора" должны содержать единственное значение "нуль" целочисленного типа.

Параметр "Список имен подзаданий" должен удовлетворять ограничениям, описанным в п.2.5.1.2в).

Значения всех полей "Число порождений" в параметре "Событие ВЫБОРОЧНЫЙ ТИП" должны быть больше нуля или равны нулю.

2.6. Документы отображения работы и отображения уведомлений

2.6.1. Определения синтаксиса

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

2.6.2.Ограничения, накладываемые на семантику

Значение "Доступно" параметра "Состояние" не должно иметь места до тех пор, пока значение параметра "Станция назначения" не станет равным значению параметра "пи агентства".

2.7. Краткое описание типов данных

В данном пункте следующие типы данных объявляются как НЕОПРЕДЕЛЕННЫЙ ТИП (см. текст в предыдущих пунктах для понимания дальнейшего обсуждения):

Имя службы ПОЗ (JTM);

Санкция идентификации пользователя.

В этом кратком описании выделение новой строки не является существенным, а точка с запятой используется для указания конца определения типа данных. Порядок определений типов данных также не является существенным. Если возникают противоречия между описанием, данным в этом пункте, и описанием в предыдущих пунктах, то предпочтение отдается предыдущим пунктам.

ГОСТ Р 34.1984 - ОПРЕДЕЛЕНИЯ СЛУЖБЫ ПОЗ (JTM) ::=

НАЧАЛО

Имя службы ПОЗ (JTM) ::=

Символическое имя логического объекта прикладного уровня;

Санкция идентификации пользователя ::=

Символическое имя логического объекта прикладного уровня;

Символическое имя логического объекта прикладного уровня ::=

ИСО 8650 - Сервисный элемент управления ассоциацией-1.

Символическое имя прикладного уровня;

Имя агентства ::=

Графическая строка;

Идентификация пользователя ::=

Графическая строка;

Список имен ::=

ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Графическая строка;

Сообщение ::=

ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Графическая строка;

Код службы ПОЗ (JTM) ::= ПОСЛЕДОВАТЕЛЬНОСТЬ

{Код пользователя службы ПОЗ (JTM) ВЫБОРОЧНЫЙ ТИП

РАЗДЕЛ 3. ПРОЦЕДУРЫ СЛУЖБЫ ПОЗ (JTM)

3.1. Введение в процедуры

Процедуры службы ПОЗ (JTM) вызываются с помощью сервисных примитивов, перечисленных в первом подпункте п.1.5.6, а указания по введению этих сервисных примитивов представлены во втором подпункте п.1.5.6. Все сервисные примитивы принимаются и вводятся во время выполнения группы совершения операций элемента СПиВ (CCR). Сервисные примитивы уровня представления, введенные в другое время, вызывают появление ошибки протокола и должны обрабатываться в реализующей системе в зависимости от ее возможностей. Все сервисные примитивы уровня представления принимаются и вводятся в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС"; обработка примитивов, введенных в контекстах другого типа, не входит в компетенцию данного стандарта.

Введение примитива запроса J-INITIATE будет вызывать процедуры, описанные в п.3.2 и в тех пунктах, на которые имеются ссылки в нем.

Введение индикации сервисного элемента прикладного уровня сервисного элемента управления ассоциацией, примитива индикации C-BEGIN и примитива индикации P-DATA (в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" и типа "Контекст уровня представления службы ПОЗ (JTM)" вызывает выполнение процедур, описанных в п.3.3 и в тех пунктах, на которые имеются ссылки в нем.

Введение примитива запроса J-END-SIGNAL вызывает выполнение процедур, описанных в п.3.11 и в тех пунктах, на которые имеются ссылки в нем.

Введение примитива запроса J-MESSAGE вызывает выполнение процедур, описанных в п.3.15 и в тех пунктах, на которые имеются ссылки в нем.

Эти процедуры используют значения, возвращаемые с помощью функций системы административного управления, которые определены в приложении А. Требования к обеспечению значений этих функций описываются в разд.4. Каждая ссылка к функции системы административного управления представляет собой порядковый номер этой функции в приложении А, например символы MF4 указывают четвертую функцию в приложении А.

Во всех отношениях эта спецификация процедуры является частью спецификации работы и указывается при использовании имени полей в стандартном синтаксическом представлении спецификации работы - элементе передачи. Использование такой нотации не накладывает ограничений на локальный способ, с помощью которого спецификация работы (семантическая конструкция) сохраняется; это необходимо при невозможности ясно определить значения семантики без использования некоторой нотации синтаксиса.

3.1.1. Общие требования

Описание, представленное в пп.3.1.1.1 и 3.1.1.2, должно приниматься во всех отношениях с использованием операции реализующей системы.

3.1.1.1. Реализующая система должна убедиться, что сервисные примитивы вводятся только в том порядке, который определен в стандарте ИСО 8831, и что примитивы C-RESTART вводятся главным управляющим логическим объектом совершения операций после отказа прикладного уровня или после аварийного завершения контекста типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС".

Примечание. Особое внимание требуется в этой области, когда программирование или интерфейс языка команд обеспечивается для примитива J-INITIATE.

3.1.1.2. Процедуры, описанные в стандарте ИСО 9805, должны применяться к действиям сервисного элемента прикладного уровня службы ПОЗ (JTM), когда это действие вводит или принимает сервисные примитивы типа "J-" и когда это действие вводит или принимает сервисные примитивы типа "С-".

3.2. Выполнение примитивов запроса J-INITIATE

Описание, представленное в данном пункте, применяется при создании и последующей обработке спецификации работы в результате введения примитива запроса J-INITIATE. Если параметры примитива J-INITIATE имеют ряд значений, указанных в разд.4 стандарта ИСО 8831, то должно использоваться описание следующих пунктов. В противном случае реализующая система отвергнет совершение операций, указанных в примитиве J-INITIATE, с кодом диагностического сообщения службы ПОЗ (JTM), установленным в значение

"оу" - Не обеспечивается",

и читаемым текстом, получаемым с помощью локальной функции MF1 системы административного управления.

Этот ряд примитивов в группе J-INITIATE должен представлять собой такую последовательность, которая определена в п.3.1 стандарта ИСО 8831.

3.2.1. Создание спецификаций работы

Спецификация работы должна создаваться из параметров примитива J-INITIATE и с помощью локальных функций системы административного управления, как это указано ниже, а затем эта спецификация работы должна обрабатываться в соответствии с описанием, представленным в п.3.4. Примитив подтверждения J-INITIATE должен вводиться, как это указано в.п.3.2.6. Этот примитив завершает процедуры, описываемые в п.3.2.

Примечание. Данный стандарт не определяет способ, по которому данные обеспечиваются в параметрах примитива J-INITIATE, а также не определяет время привязывания данных к спецификации работы. Данные запрашиваются, когда спецификация работы пересылается. Данные могут быть игнорированы, блокированы или скопированы до этого момента, в зависимости от выбора реализующей системы.


Поля должны быть установлены следующим образом:

Система предъявления задания модели ВОС

Получить из локальной функции MF2 "Локальное имя" системы административного управления.

Идентификация инициирования

Получить из параметра "Идентификация инициирования" примитива J-INITIATE.

Время инициирования

Установить в значение текущего местного времени, если оно доступно данной реализующей системе. Если текущее местное время не доступно, то параметр "Штамп времени" должен быть установлен в значение "Не доступно НУЛЬ".

Имя задания модели ВОС

Получить из параметра <Имя задания модели ВОС> примитива J-INITIATE.

Локальный указатель задания модели ВОС

Формируется в качестве явной строки. Данное значение должно быть возвращено в примитиве подтверждения J-INITIATE (см. п.3.2.6). Это же самое значение строки не должно использоватьcя для элeмeнтов передачи, выполняемых различными примитивами J-INITIATE, введенными в этот сервисный элемент прикладного уровня службы ПОЗ (JTM).

Примечание. Соответствующее значение может представлять собой дату и время.


Список имен подзаданий

Установить в { }

Проверочная трасса

Установить в значение

{{Отправитель "а", Состояние Неизвестно НУЛЬ}}, где "а" представляет собой имя открытой системы, возвращенное из локальной функции MF2 "Локальное имя" системы административного управления.

Спецификация первичного монитора

Получить из локальной функции MF3 "Первичный монитор" системы административного управления.

Санкции

Cм.п..3.2.2.

Разрешения.

См. пп.3.2.2 и 3.2.3.

Спецификация подзадания

Целевая система

Получить из параметра <Целевая система> примитива J-INITIATE.

Тип

Получить из параметра <Тип подзадания> примитива J-INITIATE.

Действия

Получить из соответствующего значения "ВЫБОРОЧНЫЙ ТИП", относящегося к определенному примитиву J-INITIATE с полями, установленными, как это указано в п.3.2.4.

Список проформ

Получить из полей примитива J-INITIATE, как это указано в п.3.2.5.

Документы для передачи

Получить из параметра <Список документов> примитива J-INITIATE.

<Время ожидания>

Это поле должно содержать время создания спецификации работы в секундах.

<Подсчитанный размер>

Если параметр <Целевая система> указывает локальную систему, то это поле будет содержать подсчитанный размер элемента передачи плюс значение длины документа (если такой документ имеется) в килооктетах. В противном случае этот параметр должен быть установлен в нулевое значение. Подсчитанный размер будет основываться на синтаксисе, который определен в качестве обязательного для элемента передачи и типа документа.

<Параметры активности агентства>

Этот параметр должен быть пустым.

<Параметры элемента СПиВ (CCR)>

Значение этого параметра должно соответствовать значению параметра "Индикатор кода диагностического сообщения" элемента СПиВ (CCR) в данных пользователя примитива J-BEGIN во время выполнения группы совершения операций примитива J-INITIATE. Его использование описывается в п.3.5.4.

3.2.2. Санкционирование

3.2.2.1. Для каждого параметра <Элемент разрешения> в примитиве J-INITIATE в спецификацию работ должен включаться параметр "Элемент разрешения".

3.2.2.2. Для каждого параметра <Элемент санкционирования> в примитиве J-INITIATE в спецификацию работы должен включаться параметр "Элемент санкционирования" со значением "Доступно", соответствующим элементу типа

"Пароль Множество СТРОКА ОКТЕТОВ".

СТРОКА ОКТЕТОВ должна соответствовать значению <Секретные данные> параметра <Элемент санкционирования> примитива J-INITIATE.

3.2.2.3. Дополнительные элементы санкционирования, как это указано в пп.3.2.2.3.1-3.2.2.3.4, должны включаться в соответствии с доступными локальными функциями системы административного управления. Дополнения, представленные в пп.3.2.2.3.1-3.2.2.3.4, должны быть сделаны в том случае, если они не помещают результат в два идентичных элемента санкционирования. Эти действия завершают процедуры, представленные в п.3.2.2.

3.2.2.3.1. Если локальная функция MF4 системы административного управления может обеспечить аутентифицированную идентификацию, указанную параметром "Идентификация", связанную с инициирующим агентством, тогда "Элемент санкционирования" должен быть добавлен с включением параметров "Проверяемый индекс" 1 и "Идентификация".

Примечание. Более подробное описание по использованию проверяемого индекса представлено в п.3.3.8.4.1.

3.2.2.3.2. Если локальная функция MF5 системы административного управления (или удаленные протоколы) имеет возможность аутентифицировать параметр "Идентификация" со значением "Доступно" параметра "Пароль", то эта функция должна быть вызвана. Если параметр "Идентификация" не аутентифицируется, то обмен не должен выполняться. Если же этот параметр аутентифицируется, то элемент санкционирования должен добавляться к проверяемому индексу, значение которого равно количеству элементов в проверочной трассе.

Примечание. К процедурам этого подпункта также имеются ссылки из процедур, описанных в п.3.3.8.3.

3.2.2.3.3. Дополнительные элементы санкционирования, обеспечиваемые локальной функцией MF6 системы административного управления, должны быть добавлены, если необходимо убедиться, что уведомления могут быть доставлены в "Первичный монитор задания модели ВОС"; реализующая система должна:

а) или убедиться, что параметр <Первичный монитор>, возвращенный функцией MF3 системы административного управления, может быть установлен только в такие значения, которые являются допустимыми (для уведомляющей системы) для всех заданий модели ВОС;

б) или обеспечить механизмы функции MF6 системы административного управления для добавления достаточного количества элементов санкционирования, чтобы гарантировать доступ для доставки уведомления.

Примечание. Реализующие системы могут включать временные идентификации и секретные данные (возможности), используемые только для этой цели, или могут включать проверку достоверности с проверяемым индексом 1.

3.2.2.3.4. Если локальная функция MF7 системы административного управления доступна для определения того, что параметр "Идентификация пользователя" (введенный при некоторой санкции, указанной параметром "Санкция идентификации пользователя") включает право обрабатывать в качестве параметра "Идентификация пользователя", введенного другой санкцией, указанной параметром "Санкция идентификации пользователя", тогда любые аутентифицированные идентификации, указанные параметром "Идентификация", для первого элемента "Идентификация пользователя" будут результатом добавления новых элементов "Элемент санкционирования" с таким же проверяемым индексом.

Примечания:

1. Если эти функции доступны и если система административного управления удаленной системы формирует свои данные, чтобы "доверить" системе предъявления задания модели ВОС, то у пользователя будет возможность работать удаленно без дополнительного пароля.

2. На процедуры, описанные в этом пункте, имеются ссылки из процедур, описанных в п.3.3.8.3.

3.2.3. Разрешения

Если элементы санкционирования были добавлены способом, который описан в пп.3.2.2.3.1 или 3.2.2.3.4, то также должны быть добавлены соответствующие элементы разрешения.

Примечание. На процедуры, описанные в этом пункте, имеются также ссылки из п.3.3.8.3.

3.2.4. Параметры действия службы ПОЗ (JTM)

Значение типа данных параметра "Параметры действия службы ПОЗ (JTM)" является изоморфным значению параметра <Параметры действия службы ПОЗ (JTM)> в примитиве J-INITIATE и должно приниматься из соответствующих полей этого примитива. Параметр "Состояние" каждого указателя "Указатель одного документа" должен устанавливаться в значение "Попытки не было НУЛЬ".

3.2.5. Проформы

Значение типа данных параметра "Список проформ" является изоморфным значению параметра <Список проформ> в примитиве J-INITIATE и должно приниматься из соответствующих полей этого примитива.

3.2.6. Примитив подтверждения J-INITIATE

Параметр "Локальный указатель задания модели ВОС" должен быть возвращен в качестве значения параметра примитива подтверждения J-INITIATE.

Примечание. Введение этого примитива может иметь место, но необязательно, если обеспечивается примитив индикации J-REFUSE. Последующие требования не определяют, вводить ли этот примитив сразу либо после обработки, описанной в п.3.4.

3.3. Процедуры для приема спецификаций работы

Описание данного пункта применяется для приема спецификации работы в результате выполнения примитива индикации P-DATA в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" во время выполнения элементарного действия элемента СПиВ (CCR).

Примечания:

1. Чтобы допустить входящие попытки установления ассоциации прикладного уровня, запрашивается реализующая система, обеспечивающая исходное, принимающее и исполняющее агентство, как это указано в разд.5. Механизмы для установления необходимых контекстов уровня представления и прикладного уровня являются объектом локального планирования и определяются в разд.5.

2. Условия, описанные в разд.5, требуют, чтобы открытая система, желающая послать спецификацию работы, приняла на себя инициативу для установления ассоциации службы ПОЗ (JTM) и необходимых контекстов уровня представления, а принимающая система играла пассивную роль.

3.3.1. Принимающий пользователь в ассоциации прикладного уровня в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ИСО" должен ожидать примитив индикации C-BEGIN (или примитив C-RESTART), следующий после примитива индикации P-DATA (см. также примечание к п.3.3.7).

3.3.2. Не следует принимать примитив C-BEGIN (или примитив C-RESTART) в нежелательное для реализующей системы время или когда будет иметь место некоторое другое входное событие, после которого реализующая система должна будет ввести примитив A-ABORT с параметрами, как указано в разд.5.

3.3.3. Должна проверяться правильность синтаксиса и семантики параметра "Данные пользователя" примитива C-BEGIN (или примитива C-RESTART) (как указывается в разд.2). Если такая ошибка обнаруживается, то должен быть введен примитив ответа C-REFUSE с кодом диагностического сообщения службы ПОЗ (JTM)

"оу - ошибка протокола"

и с читаемым текстом, устанавливаемым локальной функцией MF1 системы административного управления; процедуры элемента СПиВ (CCR) управляют всем дальнейшим действием.

3.3.4. Когда появляется примитив индикации P-DATA, адресная информация вызывающего пользователя и процедуры нижнего уровня должны использоваться с локальной функцией MF8 системы административного управления, чтобы определить одно из следующих состояний:

а) невозможно определить имя службы ПОЗ (JTM) передающего пользователя (неизвестный);

б) имя службы ПОЗ (JTM) передающего пользователя может быть определено по предположению, что не было помех со связью и что подсети функционируют в соответствии с их установленными определениями (известный);

в) применялись механизмы позитивного кодирования или механизмы паролей, чтобы обеспечить аутентифицированное имя службы ПОЗ (JTM) для пользователя, посылающего этот примитив P-DATA (аутентифицированный).

Примечание. Указательные функции и процедуры установления соединения, используемые для установления классификации:

UNKNOWN (НЕИЗВЕСТНЫЙ),

KNOWN (ИЗВЕСТНЫЙ),

AUTHENTICATED (АУТЕНТИФИЦИРОВАННЫЙ),

не являются предметом данного стандарта. Если данный стандарт используется до введения международного стандарта в этой области, то механизмы, специфические для некоторых организаций, могут использоваться перед установлением контекста типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС".

3.3.5. Локальная функция MF9 системы административного управления должна определить, должны или не должны выполняться вызовы в каждой из этих категорий с указанными именами службы ПОЗ (JTM) (диагностическое сообщение "НЕ ПОВТОРЯТЬ"). Выполнение вызова может также зависеть от общего количества вызовов службы ПОЗ (JTM) при формировании или от общего количества входящих вызовов, или от общего количества входящих вызовов из идентифицированных открытых систем или может зависеть от всех трех этих типов, как определено локальной функцией MF19 системы административного управления. Если такие ограничения превышаются, то это вызывает отказ с выдачей диагностического сообщения "ПОВТОРИТЬ ПОЗЖЕ".

3.3.6. Если локальная функция MF9 системы административного управления определяет, что вызов никогда не будет выполняться, тогда должна быть вызвана следующая процедура обработки ошибок:

не должны вводиться в дальнейшем сервисные примитивы типа "P-" или типа "C-" до тех пор, пока не будет функционировать локальная система административного управления. Действия, следующие за этим, выбираются обеспечивающей системой, но должны быть указаны в спецификации продукта (см. п.4.4.7).

Если локальная функция MF19 определяет, что вызов не должен выполняться в настоящий момент, то должен быть введен примитив C-REFUSE, указывающий диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ". Время повторения попытки должно быть указано, если локальная функция MF19 системы административного управления готова выполнить такую попытку. Кодом диагностического сообщения должен быть

"пп - Предел числа параллельного обеспечения входной информации".

Примечание. Для реализующей системы более желательным является задержка передачи с ожиданием, когда выполнение станет возможным в пределах временного интервала, указанного таймером элементарного действия, чем выдать немедленный отказ с диагностическим сообщением "ПОВТОРИТЬ ПОЗЖЕ".

3.3.7. Если должна выполняться передача, то имеет место одна из следующих ситуаций:

а) прекращается контекст типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС"; реализующая система не должна выполнять дальнейших действий;

б) выполнение примитива индикации P-DATA прерывается примитивом индикации C-ROLLBACK (который выполняет действие чистки); в этом случае должны применяться процедуры возврата в первоначальное состояние элемента СПиВ (CCR) и должен вводиться примитив подтверждения C-ROLLBACK; процедуры, описанные в этом пункте (и процедуры полного контекста типа "Контекст прикладного уровня базисного класса службы ПОЗ "(JTM) модели ВОС"), затем завершаются;

в) завершается выполнение примитива индикации P-DATA; должны применяться остальные процедуры, описанные в этом пункте.

Примечание. Нужно отказаться от выполнения передачи в то время, когда это нежелательно принимающему пользователю; принимающий пользователь может в зависимости от выбора реализующей системы ввести примитив C-REFUSE с кодом диагностического сообщения "Тайм-аут" (если еще не был введен примитив C-READY) или может ввести примитив A-ABORT. Обработка идентификатора элементарного действия элемента СПиВ (CCR) и граничных данных продолжается в соответствии с правилами элемента СПиВ (CCR).

3.3.8. Первое значение данных уровня представления в примитиве P-DATA должно интерпретироваться в качестве элемента "Элемент передачи", использующего синтаксис передачи, устанавливаемый уровнем представления для контекста уровня представления службы ПОЗ (JTM). Последующие значения данных уровня представления, если они имеются, должны интерпретироваться в качестве документа. Затем они должны обрабатываться, как это указано в пп.3.3.8.1-3.3.8.6, завершая процедуры данного пункта.

Примечание. Для дальнейшей обработки процедуры, указанные в п.3.3.8.6, указывают на процедуры, описанные в п.3.4.

3.3.8.1. Должна быть проверена правильность синтаксиса и семантики элемента "Элемент передачи" (как указано в разд.2).

Если данная проверка определяет ошибку, то должен быть введен примитив ответа C-REFUSE с кодом диагностического сообщения службы ПОЗ (JTM)

"оу - Не обеспечено",

и с помощью локальной функции MF1 системы административного управления должен быть сформирован читаемый текст. Данная проверка также может вызвать отказ из-за того, что размер или сложность спецификации работы превышает общие возможности реализующей системы. В этом случае действия должны быть такими же, но с кодом диагностического сообщения службы ПОЗ (JTM)

"оу - Слишком большое значение".

Процедуры элемента СПиВ (CCR) управляют всем дальнейшим действием.

Если проверка синтаксиса и семантики прошла удачно, то применяются процедуры, описанные в пп.3.3.8.2-3.3.8.6.

3.3.8.2. Последний элемент проверочной трассы имеет значение "Состояние неизвестно" (для правильного элемента передачи). Если значением параметра "Имя службы ПОЗ (JTM)" посылающего пользователя, обеспечиваемого, как указано в п.3.3.4, является "Неизвестный", то этот элемент не должен изменяться. Если значением параметра "Имя службы ПОЗ (JTM)" является "Известный" или "Аутентифицированный", тогда значение параметра "Имя службы ПОЗ (JTM)" в последнем элементе "Проверочной трассы" должно равняться значению параметра "Имя службы ПОЗ (JTM)" посылающего пользователя. Если имеет место соответствие, то значение параметра "Состояние" элемента "Проверочной трассы" должно быть изменено на значение параметра "Имя службы ПОЗ (JTM)" посылающего пользователя. Если соответствия нет, то должна быть вызвана процедура обработки ошибки для формирования диагностического сообщения (НЕ ПОВТОРЯТЬ), как это описано в п.3.3.6. И наконец, новый элемент должен добавляться в конец проверочной трассы и устанавливаться в значение {а, Неизвестный}, где элемент "а" обеспечивается локальной функцией MF2 "Локальное имя" системы административного управления.

3.3.8.3. Должен проверяться каждый элемент санкционирования и должны выполняться процедуры, описанные в пп.3.2.2.3.2, 3.2.2.3.4 и 3.2.3, если они формируют элементы санкционирования или элементы разрешения, которые отличаются от уже существующих элементов.

Примечание. Выполнение проверок, описанных в п.3.3.8.1, осуществляется для того, чтобы убедиться, что проверяемый индекс не превышает длину первоначальной проверочной трассы.

3.3.8.4. Локальная функция MF11 системы административного управления определяет, требуется ли санкция только при вводе в этот адрес вызова для выполнения передач или доступа к определенным агентствам, или санкция требуется всегда. Если санкция требуется на протяжении выполнения всей активности службы ПОЗ (JTM) или для посылки уведомлений службы ПОЗ (JTM), тогда должны вызываться процедуры, описанные в пп.3.3.8.4.1 и 3.3.8.4.2.

3.3.8.4.1. Локальная функция MF12 системы административного управления определяет санкции идентификаций пользователей, которые могут предоставить санкционирование для этой активности. Элемент санкционирования для одной или нескольких из этих санкций с обеими из указанных следующих возможностей может или не может существовать:

а) доступность представляется проверяемым индексом 1 (например), так что все значения параметров "Имя службы ПОЗ (JTM)" в "Проверочной трассе", последующие за 1 или равные ей, представляют собой:

1) либо последний элемент;

2) либо элемент с состоянием "Неизвестный", "Известный" или "Аутентифицированный" и параметр "Имя службы ПОЗ (JTM)", для которого локальная функция MF13 системы административного управления определяет значение "Доверять", если состояние "Неизвестный", "Доверять", если состояние "Известный" или "Доверять", если состояние "Аутентифицированный" соответственно;

б) санкция идентификации пользователя определяет, что аутентифицированное имя пользователя является санкционированным для этой активности.

Если такой элемент найден, активность является санкционированной. Если он не найден, активность не является санкционированной.

Примечание. В базисном классе элементы санкционирования также используются для определения счета, на который нужно отнести расходы для этой активности, если реализован учет.

3.3.8.4.2. Если активность не является санкционированной, то должен вводиться примитив ответа C-REFUSE. Код диагностического сообщения службы ПОЗ (JTM) должен быть:

"оп - Несанкционированный доступ"
или

"оп - "Несанкционированное уведомление"
в соответствии с требованиями, возвращаемыми функцией MF11.

Читаемый текст устанавливается локальной функцией MF1 системы административного управления.

3.3.8.5. Если установлен какой-либо бит в параметре "Селектор уведомления" в спецификации, указанной параметром "Спецификация первичного монитора", и значение параметра "Имя службы ПОЗ (JTM)" в параметре "Системное имя монитора" отличается от значения параметра "Имя службы ПОЗ (JTM)" локальной функции MF2, то локальная указательная функция МF16 системы административного управления должна использоваться для определения достоверности адресации и другой информации, необходимой при установлении ассоциации в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС". Если просмотр справочника вызывает отказ, то должен вводиться примитив ответа C-REFUSE со значением параметра "Код диагностического сообщения службы ПОЗ (JTM)"

"оп - Неизвестная область монитора",

включая ошибочное значение параметра "Имя службы ПОЗ (JTM)" в читаемый текст.

3.3.8.6. Информация, содержащая спецификацию работы и документ (если он представлен) в элементе "Элемент передачи", в дальнейшем должна обрабатываться, как указано в п.3.4. Эта обработка завершает процедуры данного пункта.

3.4. Начальная обработка спецификации работы

На процедуры данного пункта имеются ссылки в пп.3.2, 3.3, 3.10.7, 3.12, 3.13.2, 3.14.2 и 3.15.4. Требование настоящего пункта применяется для обеспечения обработки спецификации работы до того, как логический объект службы ПОЗ (JTM) примет на себя ответственность за эту спецификацию работы.

Любая спецификация работы должна быть видимой для процедур, описанных в п.3.10.2.

Введение примитива запроса J-INITIATE (см. п.3.2), примитива индикации P-DATA в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" (см. п.3.3), наличие порождения (см. п.3.12), формирование уведомления (см. пп.3.13 и 3.14) или введение примитива запроса J-MESSAGE (см. п.3.15) вызывает появление новой спецификации работы. Новая спецификация работы должна обрабатываться, как указано в пп.3.4.1-3.4.7, завершая описание процедур этого пункта.

3.4.1. Реализующая система сначала должна выполнить все процедуры, описанные в пп.3.4.6 и 3.4.7, следуя процедурам, представленным в стандарте ИСО 9805, для логического объекта, подчиненного главному управляющему логическому объекту элемента СПиВ (CCR). Если во время обработки требуется вводить дальнейшие сервисные примитивы типа "J-" или типа "Р-", то они должны выполняться как часть этого же элементарного действия.

3.4.2. При обработке спецификации работы, указанной в пп.3.4.6 и 3.4.7, могут иметь место следующие случаи:

а) все ответвления элементарного действия выполняют попытку совершения операций (возможно с выдачей предупреждающего диагностического сообщения);

б) одно или несколько из этих ответвлений элементарного действия отвергают совершение операций с выдачей диагностического сообщения "Не повторять";

в) одно или несколько из этих ответвлений элементарного действия не могут сделать попытку за время или не могут отвергнуть совершение операций (с выдачей диагностического сообщения "Повторить позже"), соответственно за время , или не могут указать в диагностическом сообщении "Повторить позже", что обработка невозможна до истечения времени ; время определяется локальной функцией MF14 системы административного управления и может зависеть от значения таймера элементарного действия, устанавливаемого управляющим логическим объектом элемента СПиВ (CCR).

3.4.3. В случае, описанном в п.3.4.2а), управляющему логическому объекту должно быть предложено совершить операцию, а процедуры, описанные в стандарте ИСО 9805 (процедуры элемента СПиВ (CCR), определяют все дальнейшие действия.

3.4.4. В случае, описанном в п.3.4.2б), диагностическое сообщение "Не повторять" сервисного примитива типа "С-" должно передаваться управляющему логическому объекту.

3.4.5. В случае, описанном в п.3.4.2в), должен рассматриваться минимальный требуемый уровень совершения операций. Если этот уровень равен 1, то спецификация работы должна задерживаться в качестве сохраненных данных и совершить операцию с уровнем, равным 1, должно быть предложено управляющему логическому объекту. Процедуры, описанные в п.3.5, должны применяться к спецификации работы в соответствии с описанием, представленным в п.3.5.3. Если минимальный запрошенный уровень совершения операций, превышает 1, то управляющему логическому объекту должно быть передано диагностическое сообщение "Повторить позже". Если диагностическое сообщение "Повторить позже" было принято от управляемых логических объектов, то оно должно включаться в то диагностическое сообщение, которое передается управляющему логическому объекту. Если дальнейшая обработка не может быть выполнена из-за ограничений, накладываемых на число параллельно выполняемых действий, допускаемых локальной функцией MF20 системы административного управления, то должен использоваться код диагностического сообщения службы ПОЗ (JTM)

"пп - Предел числа параллельного обеспечения агентств". Если такое ограничение накладывается функцией MF21, то кодом диагностического сообщения службы ПОЗ (JTM) должен быть

"пп - Предел числа параллельного обеспечения нескольких передач".

Если не применяется ни один из перечисленных случаев, то должен использоваться код диагностического сообщения

"пп - Внутренняя занятость".

Читаемый текст должен обеспечиваться функцией MF1.

Примечание. Значения таймера в диагностическом сообщении обычно извлекаются из любых значений таймера, доступных при ответах от управляемых логических объектов.

3.4.6. Если спецификация работы имеет параметр "Тип подзадания" со значением "Перемещение документа" (в своей самой последней спецификации, указанной параметром "Спецификация подзадания"), то процедуры, описанные в п.3.6, должны выполняться для этой спецификации "Спецификация подзадания", следуя процедурам, описанным в п.3.4.7.

Примечание. Для спецификации работы базисного класса, получаемой из элемента передачи, процедуры, описанные в п.3.6, имеют нулевые значения. Однако они могут быть необходимы для других применений, описанных в этом пункте.

3.4.7. Если значение параметра "Целевая система" представляет собой локальное имя службы ПОЗ (JTM), указанное локальной функцией MF2 системы административного управления, то должны вызываться процедуры, описанные в п.3.7. В противном случае процедуры должны включаться, как указано ниже:

тип подзадания "Перемещение документа" (см. п.3.8),

тип подзадания "Перемещение уведомления" (см. п.3.9),

тип подзадания "Манипулирование работой" (см. п.3.10).

3.5. Отложенная обработка спецификации работы

К процедурам данного пункта имеются ссылки в п.3.4.5, и описание данного пункта применяется только для тех спецификаций работы, которые были сохранены поставщиком услуг службы ПОЗ (JTM), как указано в п.3.4.5, после совершения операции с уровнем "Принятие поставщиком".

3.5.1. Если спецификация работы остается после принятия поставщиком, она должна быть видимой для действий, указанных в п.3.10.

3.5.2. Дальнейшая обработка может быть невозможна по одной из трех причин:

а) выполнение в агентстве или при попытке передачи невозможно из-за того, что другие активности имеют более предпочтительный приоритет, а степень параллельного выполнения активностей, допускаемая локальными функциями MF20 или MF21 системы административного управления, препятствует выполнению (ОЖИДАНИЕ-ПЛАНИРОВАНИЕ);

б) выполнение еще невозможно, потому что от агентства или от открытой системы принимаются ответы с диагностическим сообщением "ПОВТОРИТЬ ПОЗЖЕ" (ОЖИДАНИЕ-ПРОБЛЕМА УДАЛЕННОГО ЛОГИЧЕСКОГО АГЕНТСТВА).

Примечание. Реализующая система, отказывающаяся обработать спецификацию работы, потому что принимаются повторяемые ответы с диагностическим сообщением "ПОВТОРИТЬ ПОЗЖЕ", в зависимости от реализующей системы, может выполнять процедуры, описанные в п.3.5.10;

в) ожидается примитив группы совершения операций J-TASKEND из принимающего или исполняющего агентства после совершения операций с уровнем ПРИНЯТИЕ АГЕНТСТВОМ (ПРИНЯТО АГЕНТСТВОМ).

Примечание. Ожидать спецификацию работы могут несколько ресурсов. Один ресурс или несколько ресурсов могут ожидать несколько спецификаций работы. Способ очередности и просмотра очереди для ресурсов выбирается реализующей системой и не ограничивается данным стандартом. Обычно способ очередизации должен предусмотреть приоритет обработки спецификаций работы по перемещению уведомлений и по манипулированию работой.

3.5.3. Если обработка спецификации работы требует ресурсов, которые являются доступными на всем протяжении периода времени , то должна быть выполнена попытка обработки спецификации работы во время этого периода . Значение должно указываться в спецификации продукта, но не ограничивается данным стандартом. Спецификация работы должна обрабатываться с использованием процедур, описанных в пп.3.4.6 и 3.4.7, с помощью сервисного элемента прикладного уровня службы ПОЗ (JTM) в качестве главного управляющего логического объекта совершения операций элемента СПиВ (CCR).

Примечание. Предполагается, что значение будет изменяться в продолжение существования спецификации работы.

3.5.4. При выполнении спецификации работы реализующая система в качестве главного управляющего логического объекта совершения операций элемента СПиВ (CCR) должна сформировать уникальный идентификатор элементарного действия, запросить уровень совершения операций 1, а индикатор кода диагностического сообщения элемента СПиВ (CCR) должен выбрать из поля <Параметры элемента СПиВ (CCR)> спецификации работы. Если предложение совершить операцию принимается от всех управляемых логических объектов, то должны применяться процедуры, описанные в п.3.5.7. Если принимается индикация диагностического сообщения "Повторить позже", то должны применяться процедуры, описанные в пп.3.5.2 и 3.5.3.

Примечание. Реализующая система сама выбирает, сохранять ли определенные ресурсы, когда другие ресурсы недоступны, или выполнить возврат в первоначальное состояние, относительно доступных ресурсов, и позже попытаться выполнить полную обработку сначала.

3.5.5. Если приняты одно или несколько диагностических сообщений "Нe повторять", а спецификация работы имеет тип подзадания "Перемещение уведомления", тогда должен быть выполнен возврат в первоначальное состояние. Дальнейшая обработка не определяется данным стандартом.

Примечание. Рекомендуется, чтобы оператор системы административного управления был информирован об отказе от выполнения подзаданий по перемещению уведомлений.

3.5.6. Если приняты одно или несколько диагностических сообщений "Не повторять", а значением параметра "Тип подзадания" не является "Перемещение уведомления" и параметр" "Селектор уведомлений" имеет установленный бит "Аварийное завершение", тогда спецификация работы по перемещению уведомления должна формироваться, как указано в п.3.13, и обрабатываться (с уровнем совершения операций 1), как указано в п.3.4 и в данном пункте. Спецификация работы по перемещению уведомления должна быть сохранена и может обрабатываться как часть текущего элементарного действия. Основное элементарное действие должно возвратиться в первоначальное состояние, а спецификация работы, предназначенная для обработки, должна быть сброшена. Сохранение (и необязательная обработка) спецификации работы по перемещению уведомления (если она имеется) должно быть выполнено, если основное элементарное действие возвращается в первоначальное состояние.

3.5.7. Предложение о совершении операции должно представить порядок выполнения. Все сообщения типа "Предупреждающее диагностическое сообщение" элемента СПиВ (CCR) должны сбрасываться. Спецификация работы должна быть удалена после введeния поpядкa cовepшeния операций и до удаления данных элементарного действия элемента СПиВ (CCR), если принимается подтверждение о совершении операций.

3.5.8. При восстановлении после сбоя прикладного уровня или связи должны использоваться процедуры рестарта элемента СПиВ (CCR), как описано в стандарте ИСО 9804.

3.5.9. Выполнение одной спецификации работы не должно прекращаться из-за невозможности выполнить другие спецификации работы, если только эти спецификации работы не требуют доступа к общему агентству или передачи в общую область.

3.5.10. Оператор системы административного управления должен быть информирован о повторных ответах с диагностическим сообщением "Повторить позже" и о возможном запросе, чтобы определить, продолжить ли обработку с этого подпункта или перейти к применению процедур, описанных в пп.3.5.2 и 3.5.3. Самое последнее диагностическое сообщение "Повторить позже" должно быть преобразовано в диагностическое сообщение "Не повторять" с помощью устранения какого-либо таймера повторений и с помощью добавления элемента с параметром "Формирователь", установленным функцией MF2, с кодом диагностического сообщения "оу - Повторные попытки" и с параметром "Текст", сформированным с помощью функции MF1. Применяются процедуры, описанные в пп.3.5.5 и 3.5.6.

3.6. Решение ссылок

Описание данного пункта должно применяться только к спецификации верхнего уровня, указанной параметром "Спецификация подзадания" в такой спецификации работы, в которой параметр "Тип подзадания" имеет значение "Перемещение документа". К процедурам данного пункта имеются ссылки из процедур, описанных в п.3.4.6. Если процедуры, описанные в п.3.4.6, использовались процедурами, описанными в п.3.1.2, то спецификация работы может иметь идентификаторы активности для исполняющих агентств, имеющих отношение к этой спецификации работы.

Примечание. В базисном классе процедуры, описанные в этом пункте, используются только для того, чтобы поставщик услуг службы ПОЗ (JTM) имел доступ к документу типа "Отображение работы" или чтобы исполняющее агентство имело доступ (при допустимом параметре "Идентификатор активности") к одному-единственному выводному документу.

3.6.1. Процедуры, описанные в п.3.6.2, должны выполняться для каждого параметра "Указатель документа единого формата", который имеет значение "ВЫБОРОЧНЫЙ ТИП" параметра "Указатель одного документа" со значением параметра "Открытая система выполнения действия", установленным в значение локального параметра "Имя службы ПОЗ (JTM)", возвращенным локальной функцией MF2 системы административного управления, и с параметром "Состояние", установленным в значение "Попытки не было".

3.6.2. В базисном классе имеются два возможных значения параметра "Указатель одного документа" со значением "Попытки не было" параметра "Состояние", и оба указывают открытую систему в качестве "Открытой системы выполнения действия". Этими значениями являются:

где a - локальное "Имя службы ПОЗ (JTM)", указанное в локальной функции MF2 системы административного управления;

b - "графическая строка";

s - "графическая строка";

c - "ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Графические строки".

Первое значение параметра "Указатель одного документа", данное выше, должно обрабатываться процедурами, описанными в п.3.6.3, а второе значение этого параметра должно обрабатываться процедурами, описанными в пп.3.6.4 и 3.6.5.

3.6.3. Поставщик услуг службы ПОЗ (JTM) имеет доступный (по отношению к частной спецификации работы) документ с именем документа "y", как указано в п.3.10.8. Если это имя не совпадает со значением "s", должны выполняться процедуры, описанные в п.3.6.3.1, в противном случае этот документ должен отмечаться для удаления при совершении операции и должны выполняться процедуры, описанные в п.3.6.3.2.

3.6.3.1. Параметр "Указатель одного документа" должен иметь параметр "Состояние", измененный на значение "Отказано". Значение параметра "Штамп времени" должно быть установлено на текущее время, если оно доступно, или же должно устанавливаться значение

"ВЫБОРОЧНЫЙ ТИП Не доступно НУЛЬ".

Диагностическое сообщение "Не повторять" элемента СПиВ (CCR) должно составляться с параметром "Формирователь", значение которого берется из параметра "Имя службы ПОЗ (JTM)", возвращенного функцией MF2, с параметром "Код", установленным в значение

"оп - Нет документа",

и с параметром "Причина", установленным функцией MF1 в текст, который должен содержать описанное выше значение "s". Совершение операции должно быть предложено управляющему логическому объекту. В таком случае завершаются процедуры этого пункта.

3.6.3.2. Если документ получен, то этот документ перед обработкой параметра "Указатель документа" должен быть добавлен в спецификацию работы к параметру "Документы для передачи" после -го документа, где "" представляет собой число "вложенных" указателей в элементе передачи. Значение параметра "Указатель документа" должно быть изменено на значение

ВЫБОРОЧНЫЙ ТИП Вложенный НУЛЬ,

и совершение операции должно быть предложено управляющему логическому объекту. В таком случае завершаются процедуры этого пункта.

3.6.4. Для второго значения, представленного в п.3.6.2, имя "b" должно проверяться локальной функцией MF15 системы административного управления, содержащей список исполняющих агентств в этой открытой системе. Если такое имя не найдено, должна выполняться процедура, описанная в п.3.6.3.1, но с параметром "Код", установленным в значение кода диагностического сообщения "оп - неизвестное агентство" и с читаемым текстом, содержащим значение "b". Если это имя найдено, то в агентство должен быть инициирован примитив группы совершения операций J-GIVE как часть элементарного действия, вызывающего эту обработку. Параметры устанавливаются, как указано в пп.3.6.4.1-3.6.4.6. Обработка примитива ответа J-GIVE описана в п.3.6.5.

3.6.4.1. Локальная функция MF15 системы административного управления определяет, требует ли это агентство элемент санкционирования и, если это так, то какую санкцию идентификации пользователя оно распознает. Если элемент санкционирования не требуется, то параметр <Санкция пользователя> должен быть установлен в значение "НЕИЗВЕСТНЫЙ". Если элемент санкционирования требуется, тогда параметр <Санкция пользователя> доложен быть установлен, в порядке предпочтения, в значение

<Идентификация>="Идентификация"

из аутентифицированного элемента санкционирования или в значение

<Элемент санкционирования>="Элемент санкционирования", если аутентифицированное значение не может быть найдено, или в значение

НЕИЗВЕСТНЫЙ,

если здесь нет элемента для требуемой санкции идентификации пользователя.

3.6.4.2. Параметр <Счет пользователя> должен быть установлен в значение "НЕИЗВЕСТНЫЙ".

3.6.4.3. Параметр <Дополнительное санкционирование> должен иметь нулевое значение.

3.6.4.4. Параметр "Параметр агентства" должен быть установлен в нулевое значение.

3.6.4.5. Параметр "Указатель источника документа" должен быть установлен в значение "ПЕРЕМЕЩЕНИЕ" со списком строк "с", описанных в п.3.6.2 в качестве параметра "Список имен".

3.6.4.6. Параметр "Тип документа" должен быть установлен в значение "Перемещение документа" элемента "Тип документа", содержащего указатель документа.

3.6.4.7. Параметр <Группа документа> должен быть установлен в значение <Группа завершения активности>. Эти процедуры используются только как часть порождения завершения задачи (см. п.3.11), и идентификатор активности агентства является доступным и должен использоваться для параметра <Группа завершения активности> примитива J-GIVE.

Этот пункт завершает определение параметров примитива индикации J-GIVE.

3.6.5. Примитив ответа J-GIVE содержит документ, или здесь может быть примитив C-REFUSE, указывающий диагностическое сообщение "НЕ ПОВТОРЯТЬ", или примитив C-REFUSE, указывающий диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ". В первом случае процедура, описанная в п.3.6.3,2, должна выполняться для завершения процедур этого пункта. Любое предупреждающее диагностическое сообщение элемента СПиВ (CCR) должно быть возвращено главному управляющему логическому объекту (если нет ошибки более высокой сложности). Во втором случае диагностическое сообщение, которое формировалось агентством, должно содержать значение параметра "Имя службы ПОЗ (JTM)", назначенное этой открытой системе (или открытой системе, назначаемой нестандартными протоколами), значение параметра "КОД"

"оп - Нет документа в агентстве"

и параметр "Причина", полученные функцией MF1. Должны быть выполнены процедуры, описанные в п.3.6.3.1, но с параметром "Не повторять <Диагностическое сообщение элемента СПиВ (CCR)>", установленным в значение диагностического сообщения, возвращаемого этим агентством. В третьем случае должно быть сформировано подобное диагностическое сообщение, но со значением параметра "Код"

"пп - Доступ к документу агентства"

и необязательно со значением параметра "Таймер повторения". В пп.3.4 и 3.5 определяются процедуры, указанные в п.3.7.

3.7. Процедуры для передачи спецификации работы

Требования данного пункта применяются к любой спецификации работы, которая должна посылаться, используя синтаксис элемента "Элемент передачи", в другую открытую систему. К процедурам данного пункта имеются ссылки из процедур, описанных в п.3.4.7.

3.7.1. Если локальная функция MF16 системы административного управления указывает, что санкционирование требуется для активности передачи, тогда реализующая система должна определить требуемую санкцию идентификации пользователя и отыскать элемент санкционирования, содержащий аутентифицированную идентификацию пользователя для этой санкции. Если элемент санкционирования не найден или если идентификация пользователя не была представлена необходимым санкционированием, действие должно быть таким, как если бы произошел отказ при попытке передачи с кодом диагностического сообщения службы ПОЗ (JTM), установленным в значение

"оп - Нет санкции для передачи"

и читаемым текстом, устанавливаемым локальной функцией MF1 системы административного управления. В таком случае диагностическое сообщение должно быть возвращено управляющему логическому объекту, завершая процедуры данного пункта.

3.7.2. Локальная указательная функция MF16 системы административного управления должна использоваться для определения адресации и другой информации, необходимой при установлении соединения в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" с системой, указанной параметром "Целевая система". Если при просмотре справочника происходит сбой, то действие должно быть таким, как если бы был получен отказ при попытке передачи с кодом диагностического сообщения службы ПОЗ (JTM), установленным в значение

"оп - Неизвестная область"

и с включением ошибочного параметра "Имя службы ПОЗ (JTM)" в читаемый текст (функция MF1). Диагностическое сообщение должно быть возвращено управляющему логическому объекту, в таком случае завершая процедуры данного пункта.

3.7.3. Если имеется достаточное санкционирование и если просмотр справочника выполнен успешно, то локальная функция MF21 системы административного управления должна использоваться для следующих целей:

а) обеспечить новую (или использовать повторно) ассоциацию прикладного уровня для передачи;

б) обеспечить индикацию отказа с диагностическим сообщением "Повторить позже";

в) обеспечить индикацию отказа с диагностическим сообщением "Не повторять".

Процедуры, используемые для установления новой ассоциации, определяются в разд.5.

3.7.4. Если функция MF21 указывает отказ с диагностическим сообщением "Не повторять", действие должно быть таким же, как если бы был отказ на попытку передачи с кодом диагностического сообщения службы ПОЗ (JTM), установленным в значение

"оу - Отказ передачи",

и читаемым текстом, устанавливаемым локальной функцией MF1 системы административного управления. Диагностическое сообщение вместе с каким-либо диагностическим сообщением, возвращенным функцией MF21 (см. п.5.1.3), должно быть возвращено управляющему логическому объекту, завершая процедуры данного пункта.

Если функция MF21 указывает отказ с диагностическим сообщением "Повторить позже", то реализующая система должна:

а) ожидать до тех пор, пока передача будет возможна, отмечая какое-либо значение таймера элементарного действия;

б) или обойти эту ситуацию, как если бы был получен примитив индикации C-REFUSE (с диагностическим сообщением "Повторить позже"), и продолжать выполнение, как указано в пп.3.4 и 3.5. Код диагностического сообщения службы ПОЗ (JTM) должен иметь значение

"пп - Попытка передачи".

3.7.5. Если функция MF21 обеспечивает ассоциацию, тогда реализующая система должна ввести примитив C-BEGIN на установление ассоциации прикладного уровня в качестве ответвления элементарного действия, а затем должна ввести примитив P-DATA, содержащий следующие значения:

а) "Элемент передачи", поля которого установлены в значение соответствующих полей спецификации работы;

б) значение, равное документу в спецификации работы (если он имеется).

Параметры передачи описываются в разд.5.

3.7.6. Не должен использоваться примитив C-PREPARE, границы элементарного действия должны быть определены при завершении выполнения одного примитива P-DATA.

3.7.7. После этого используются примитивы индикации C-READY или C-REFUSE как результат выполнения этого элементарного действия, и эти примитивы обрабатываются, как указано в пп.3.4 и 3.5.

3.7.8. После завершения элементарного действия ассоциация прикладного уровня становится доступной для других передач выходных данных службы ПОЗ (JTM) (см. функцию MF21) или можно отказаться от этой ассоциации, используя примитив A-RELEASE с параметрами, указанными в п.5.2. Это завершает процедуры данного пункта.

3.8. Процедуры перемещения документа

Процедуры данного пункта вызываются с помощью процедур, описанных в п.3.4.7. Требования настоящего пункта применяются к элементам передачи с самым последним значением "Перемещение документа" параметра "Тип подзадания" и системой, указанной параметром "Целевая система", соответствующей локальной функции MF2 открытой системы.

3.8.1. Процедуры пп.3.8.2-3.8.7 должны применяться по очереди для одного значения "Перемещение документа" в самой последней из операций "Операция по перемещению документа" ПОСЛЕДОВАТЕЛЬНОСТЬ. Затем для завершения процедур данного пункта должны применяться процедуры, описанные в п.3.8.8.

3.8.2. Должна применяться проверка значения "Перемещение документа", чтобы каждый параметр "Указатель документа" имел значение ВЫБОРОЧНЫЙ ТИП "Вложенный" или имел параметр "Состояние" со значением "Отказано". Если при проверке происходит сбой, диагностическое сообщение элемента СПиВ (CCR) "He повторять" должно быть сформировано для каждого такого сбоя с кодом диагностического сообщения службы ПОЗ (JTM) "оп - Неудовлетворительный указатель документа" и читаемым текстом, которые обеспечиваются локальной функцией MF1 системы административного управления. Текст должен содержать имя документа из указателя. При этом ответвлении элементарного действия происходит сбой с возвращением диагностического сообщения управляющему логическому объекту. В таком случае так завершаются процедуры этого пункта.

3.8.3. Значение параметра "Имя агентства" в параметре "Идентификация пи" должно проверяться функцией MF15 системы административного управления, содержащей список локальных принимающих и исполняющих агентств. Если имя агентства не найдено, тогда должны быть введены диагностическое сообщение "Не повторять" элемента СПиВ (CCR) с кодом диагностического сообщения службы ПОЗ (JTM) "оп - Неизвестное агентство" и читаемый текст функции MF1, содержащий имя агентства. Это диагностическое сообщение возвращается управляющему логическому агентству, завершая, в таком случае, процедуры этого пункта.

3.8.4. Если проверка выполняется успешно, то должен быть инициирован примитив индикации J-DISPOSE по отношению к одной идентификации, указанной параметром "Идентификация пи", в списке "пи агентства" ПОСЛЕДОВАТЕЛЬНОСТЬ как часть элементарного действия, вызывающего эту обработку. Параметры должны быть установлены, как указано в пп.3.8.4.1-3.8.4.7. Примитив ответа J-DISPOSE должен обрабатываться, как это указано в п.3.8.5.

3.8.4.1. Идентификатор активности поставщика должен формироваться отдельно от любой текущей активности, и он должен отличаться для каждого примитива J-DISPOSE, который еще продолжает свое выполнение.

3.8.4.2. Процедуры, описанные в пп.3.6.4.1-3.6.4.3, должны вызываться для формирования параметров санкционирования и параметров учета.

3.8.4.3. Параметр <Параметр агентства> должен быть установлен в нулевое значение.

3.8.4.4. Параметр <Указатель пи документа> должен принимать значение, имеющееся в параметре "Блок документа единого формата" со значением "НОРМАЛЬНЫЙ" параметра <Параметр доступа к пи>.

3.8.4.5. Параметр <Тип документа> должен принимать значение "Перемещение документа" ПОСЛЕДОВАТЕЛЬНОСТЬ, имеющееся в параметре "Тип".

3.8.4.6. Если агентство не может предоставить доступ по имени документа в параметре <Указатель пи документа>, оно должно сформировать локальное имя, которое отличается от имени любого другого локального документа и, если этому агентству предложено совершить операцию, то оно должно возвратить предупреждающее диагностическое сообщение элемента СПиВ (CCR) c кодом диагностического сообщения службы ПОЗ (JTM) "п - Изменено имя документа" и читаемый текст функции MF1, который содержит и старое, и новое имя.

Примечание. Предупреждающее диагностическое сообщение сбрасывается, если главным управляющим логическим объектом является сервисный элемент прикладного уровня службы ПОЗ (JTM) базисного класса.

3.8.4.7. Документ, указанный параметром <Документ размещения>, должен быть таким, который является "вложенным" в спецификацию работы, или должен представлять собой параметр <Ошибки>, если значением параметра "Состояние" является "Отказано". Документ, представленный в качестве параметра <Ошибки>, должен содержать один элемент <Диагностическая информация> с параметром <Детали формирователя>, значение которого взято из параметра "Идентификация исходного агентства" и из элемента "Указатель источника документа" параметра "Указатель документа", параметр <Штамп времени> и параметр <Диагностическое сообщение элемента СПиВ (CCR)>, принятый при значении "Отказано" параметра "Состояние". Агентство должно преобразовать все типы документов и параметр "Ошибки" в соответствующий локальный синтаксис. В базисном классе не требуется, чтобы первоначальная информация в документе была полностью восстановлена с помощью примитива J-GIVE.

Примечание. Например, отображение наборов символов не может быть полностью обратимым, документы в двоичном коде могут быть заполнены множеством из восьми битов и т.д.


На этом завершается описание спецификации параметров примитива J-DISPOSE.

3.8.5. При выполнении примитива группы совершения операций J-DISPOSE формируются:

а) примитив запроса J-REFUSE; в этом случае должны применяться процедуры, описанные в п.3.8.6;

б) примитив запроса J-READY, предлагающий совершить операцию с уровнем ЗАВЕРШЕНИЯ; в этом случае должны применяться процедуры, описанные в п.3.8.7;

в) пpимитив запроса J-READY, предлагающий совершить операцию с уровнем ПРИНЯТИЕ АГЕНТСТВОМ; в этом случае должны применяться процедуры, описанные в п.3.8.8.

3.8.6. Если примитив запроса J-REFUSE вводится агентством, то диагностическое сообщение элемента СПиВ (CCR) должно быть передано управляющему логическому объекту, завершая процедуры этого пункта. Диагностическое сообщение элемента СПиВ (CCR) из агентства должно быть сформировано так, чтобы оно содержало значение параметра "Имя службы ПОЗ (JTM)", назначенное этой открытой системе (или открытой системе, доступной через нестандартные протоколы), "Код" "оп - Ошибка при размещении" для диагностического сообщения "НЕ ПОВТОРЯТЬ" элемента СПиВ (CCR) или "Код" "пп - Размещение документа" для диагностического сообщения "ПОВТОРИТЬ ПОЗЖЕ" элемента СПиВ (CCR) и читабельный текст, полученный с помощью функции MF1.

3.8.7. Если агентством предлагается совершить операцию с уровнем ЗАВЕРШЕНИЯ, то операция завершения задачи, порождающая процедуры, описанные в п.3.12, должна вызываться как часть элементарного действия с уровнем совершения операций ПРИНЯТИЕ ПОСТАВЩИКОМ, передавая идентификатор активности агентства, который был возвращен в эти процедуры в примитиве ответа J-DISPOSE. В этом случае управляющему логическому объекту этой активности не будет предлагаться совершить операцию до того, пока не завершатся порождающие процедуры, описанные в п.3.12.

Если параметр "Селектор уведомлений" в спецификации работы имеет установленный бит "Нормальное завершение", то процедуры, описанные в п.3.14, должны вызываться для обработки этой спецификации работы, как часть этого элементарного действия с требуемым уровнем совершения операций, равным тому, который имеет главное элементарное действие. В этом случае совершение операции не должно предлагаться управляющему логическому объекту этой активности до тех пор, пока процедуры, описанные в п.3.14, не предложат совершить операцию. Если эти процедуры будут отклонены, должны применяться процедуры, описанные в п.3.8.6.

В таком случае завершаются процедуры этого пункта.

3.8.8. Если агентство предлагает только уровень совершения операций ПРИНЯТИЕ АГЕНТСТВОМ (уровень совершения операций 2), тогда должна быть создана новая спецификация работы и сохранена как часть элементарного действия, как это указано в п.3.8.9. Совершение операции должно быть предложено управляющему логическому объекту, завершая процедуры этого пункта. Спецификация работы обрабатывается в дальнейшем как часть процедур примитива J-END-SIGNAL, определенных в п.3.11.

3.8.9. Новая спецификация работы является копией старой со следующими изменениями:

а) поле <Время ожидания> инициируется заново, чтобы в нем содержалось текущее время;

б) самая последняя спецификация работы, указанная параметром "Спецификация подзадания", уничтожается, и любые документы, представленные ею, не копируются;

в) добавляются параметры <Идентификатор активности агентства> и <Идентификатор активности поставщика>, взятые из примитивов индикации и ответа J-DISPOSE;

г) параметр <Подсчитанный размер> устанавливается в значение, соответствующее новой спецификации работы и ее документам.

Новая спецификация работы должна быть видимой для процедур, описанных в п.3.10.2.

3.9. Процедуры перемещения уведомлений

Процедуры данного пункта вызываются процедурами, описанными в п.3.4.7. Описание данного пункта применяется для передачи элементов с параметром "Тип подзадания", имеющим значение "Перемещение уведомления" и с параметром "Целевая система", имеющим значение, равное имени локальной открытой системы.

3.9.1. Если имя локальной открытой системы (функция MF2) не равно значению, указанному параметром "Имя службы ПОЗ (JTM)" в параметре "Монитор", диагностическое сообщение "Не повторять" элемента СПиВ (CCR) должно быть сформировано с кодом диагностического сообщения службы ПОЗ (JTM) "оу - Неправильный маршрут уведомления" с читаемым текстом (функция MF1), включающим в себя значение параметра "Имя службы ПОЗ (JTM)", взятое из параметра "Системное имя монитора" в спецификации, указанной параметром "Спецификация первичного монитора". Диагностическое сообщение должно быть возвращено управляющему логическому объекту, завершая в таком случае процедуры этого пункта.

3.9.2. Значение параметра "Имя агентства" в идентификации, указанной параметром "Идентификация пи", должно проверяться локальной функцией (MF15) системы административного управления, содержащей список локальных принимающих агентств. Если имя агентства не найдено, то диагностическое сообщение "Не повторять" элемента СПиВ (CCR) должно быть сформировано с кодом диагностического сообщения службы ПОЗ (JTM) "оу - Неправильное имя монитора" и читаемым текстом (функция MF1), включающим неправильное имя. Диагностическое сообщение должно быть возвращено управляющему логическому объекту, завершая в таком случае процедуры этого пункта.

Если имя агентства найдено, то к агентству должен быть инициирован примитив группы совершения операций J-DISPOSE как часть элементарного действия, вызывающего эту обработку. Параметры примитива индикации J-DISPOSE должны устанавливаться, как это указано в пп.3.9.2.1-3.9.2.6.

3.9.2.1. Параметр <Идентификатор активности поставщика> должен быть сформирован так, чтобы он отличался от идентификатора любой текущей активности.

3.9.2.2. Процедуры, описанные в пп.3.6.4.1-3.6.4.3, должны вызываться для формирования параметров санкции и учета.

3.9.2.3. Параметр <Параметр агентства> должен быть установлен в нулевое значение.

3.9.2.4. Значение параметра <Указатель пи документа> должно приниматься из параметра "Указатель пи документа", имеющегося в параметре "Команды размещения" со значением "ДОПОЛНИТЕЛЬНЫЙ" в параметре "Параметр доступа к пи".

3.9.2.5. Параметр <Данные> должен иметь значение <Отображение уведомления службы ПОЗ (JTM)>, содержащее в спецификации работы все элементы "Одно уведомление". Каждый элемент "Одно уведомление" должен стать значением параметра <Уведомление>, значение параметра <Система монитора задания модели ВОС> должно устанавливаться с помощью функции MF2, а параметр <Штамп времени> должен содержать время введения примитива J-DISPOSE.

3.9.2.6.Параметр <Ошибки> должен представлять собой пустой список.

Это завершает спецификацию параметров примитива индикации J-DISPOSE.

3.9.3. При выполнении примитива группы совершения операции J-DISPOSE формируется или

а) примитив запроса J-REFUSE; в этом случае должны применяться процедуры, описанные в п.3.9.4, или

б) примитив запроса J-READY, предлагающий совершить операцию с уровнем ЗАВЕРШЕНИЕ, в этом случае должны применяться процедуры, описанные в п.3.9.5, или

в) примитив запроса J-READY, предлагающий совершить операцию с уровнем ПРИНЯТИЕ АГЕНТСТВОМ; в этом случае должны применяться процедуры, описанные в п.3.9.6.

3.9.4. Если примитив запроса J-REFUSE вводится для примитива группы совершения операций J-DISPOSE, тогда диагностическое сообщение должно быть передано управляющему логическому объекту, завершая процедуры этого пункта.

3.9.5. Если предлагается совершить операцию с уровнем ЗАВЕРШЕНИЕ, то это предложение нужно возвратить управляющему логическому объекту, завершая процедуры этого пункта.

3.9.6. Если агентство предлагает совершить операцию только с уровнем ПРИНЯТИЕ АГЕНТСТВОМ, то должны применяться процедуры, описанные в пп.3.8.8 и 3.8.9.

3.9.7. Агентство должно формировать параметр <Отображение уведомления службы ПОЗ (JTM)> в читаемый текст. Формат не стандартизован. Любое диагностическое сообщение "Не повторять", введенное агентством, должно иметь "Код"

"оп - Ошибка при размещении".

Любое диагностическое сообщение "Повторить позже", введенное агентством, должно иметь "Код"

"пп - Размещение документа".

3.10. Процедуры манипулирования работой

Процедуры этого пункта вызываются процедурами, описанными в п.3.4.7.

3.10.1. Каждая спецификация работы, которая является видимой для этих процедур (как определено в пп.3.4, 3.5, 3.8 и 3.9), имеет одну из трех категорий, определяемых процедурами пп.3.10.2-3.10.4. Такими категориями являются:

а) модифицируемая;

б) отображаемая;

в) недоступная.

3.10.2. Спецификация работы является модифицируемой, если в настоящий момент она не включена ни в какую группу совершения операций, для которой совершение операции было предложено этим логическим объектом службы ПОЗ (JTM) и если какое-либо из этих условий сохраняется.

(Примечание. "Элементы разрешения" берутся из той спецификации работы, которая является кандидатом для модификации; "Элементы санкционирования" берутся из той спецификации работы, которая содержит параметр "Операция работы"):

а) она не содержит тип "Перемещение уведомления", но содержит, по крайней мере, один элемент "Элемент разрешения", параметр "Идентификация" которого соответствует параметру "Идентификация" в элементе "Элемент санкционирования" с доступом для параметра "Проверяемый индекс", если значение параметра "Проверяемый индекс" удовлетворяет условиям п.3.3.8.4.1a;

б) она содержит в своем параметре "Проверочная трасса" или в любом из своих параметров "Целевая система" значение параметра "Имя службы ПОЗ (JTM)", соответствующее значению "Открытая система <Идентификация>" в элементе "Элемент санкционирования", доступный, как указано в п.3.10.2а);

в) она содержит, по крайней мере, один элемент "Элемент разрешения" с параметром "Идентификация пользователя", в котором значение параметра "Санкция идентификации пользователя" соответствует значению параметра "Идентификация санкции" в элементе "Элемент санкционирования", доступный, как указано в п.3.10.2а).

Примечание. Спецификация работы включается в группу совершения операций, если:

а) она обрабатывается, как указано в пп.3.4 и 3.5, или

б) она уничтожается при манипулировании.

3.10.3. Спецификация работы является отображаемой, если:

а) она является модифицируемой или

б) при запросе на ее модификацию происходит отказ из-за того, что она в настоящий момент включена в группу совершения операций, которой было предложено совершить операцию, или

в) локальная функция MF17 системы административного управления определяет, что все видимые спецификации работы должны быть отображаемыми.

3.10.4. В иных случаях спецификация работы является недоступной.

Примечание. Классификация является зависимой от времени, так как элементарные действия непрерывно начинают и завершают выполнение. Реализующие системы могут выбирать, ожидать ли завершение мешающего элементарного действия (подчиняется таймеру элементарного действия при манипулировании). В открытой системе нет требований для определения состояния всех спецификаций работы, которые должны проверяться в одно время. Может случиться, что спецификация работы изменяется другими активностями во время манипулирования таким образом, что она выбирается дважды. Реализующие системы не обязательно должны препятствовать этому.

3.10.5. Спецификация работы выбирается с помощью селектора базисного класса, описание которого имеется в п.2.5.6.2, если только:

а) значение ее параметра "Система предъявления задания модели ВОС" равно "р";

б) значение ее параметра "Имя задания модели ВОС" равно "q";

в) значение ее параметра "Тип подзадания" равно "r".

3.10.6. По значению параметра "Операция по манипулированию работой" {Выбор х, останов НУЛЬ} должны вызываться процедуры, описанные в пп.3.10.6.1-3.10.6.3, которые должны выполняться (если и только если совершается манипулирование) по каждой спецификации работы, которая выбирается и модифицируется.

Примечание. Для того чтобы удовлетворить этому требованию, логический объект службы ПОЗ (JTM) не может предложить совершение операций для обработки любой спецификации работы, выполнение которой было приостановлено с помощью манипулирования и для которой было предложено совершить операцию.

Если параметр "Селектор уведомлений" в спецификации работы, выполняющей манипулирование, имеет установленный бит "Нормальное завершение", то для этой спецификации работы должны вызываться процедуры, описанные в п.3.14, как часть этого элементарного действия с требуемым уровнем совершения операций, равным уровню основного элементарного действия. В таком случае управляющему логическому объекту этой активности не должно предлагаться совершать операцию до тех пор, пока это совершение операции не предложат процедуры, описанные в п.3.14. Этим процедурам следовало бы выполнить отказ, тогда этот отказ должен быть возвращен управляющему логическому объекту.

3.10.6.1. Любые группы совершения операций, инициируемые процедурами, описанными в пп.3.6.4 (примитив J-GIVE), 3.7.5 (Передача), 3.8.4 (примитив J-DISPOSE) и 3.9.2 (примитив J-DISPOSE), должны быть возвращены в первоначальное состояние.

3.10.6.2. Любые группы совершения операций, инициирующие процедуры, описанные в пп.3.4 (примитив J-INITIATE), 3.3 (Передача), 3.11 (порождение) и 3.15 (примитив J-MESSAGE) для этой спецификации работы, должны быть отвергнуты с диагностическим сообщением "Повторить позже", которое возвращается управляющему логическому объекту. Это диагностическое сообщение должно содержать параметр "Код" "пп - Выполняется манипулирование".

Примечание. Рекомендуется, чтобы время повторения попытки указывалось в пределах около 5 мин.

3.10.6.3. Для любых принимающих и исполняющих агентств, которые имеются, данный уровень совершения операций ПРИНЯТИЕ должен вводиться с группой примитивов J-STOP, как часть элементарного действия манипулирования.

В таком случае так завершаются процедуры этого пункта.

3.10.7. По значению параметра "Операция по манипулированию работой" {Выбор х, уничтожить НУЛЬ} должны вызываться процедуры, описанные в пп.3.10.7.1-3.10.7.6, которые должны выполняться (если и только если совершается манипулирование) по каждой спецификации работы, которая выбирается и модифицируется.

Примечание. Для того чтобы удовлетворить этому требованию, логический объект службы ПОЗ (JTM) не может предложить совершение операций для обработки любой спецификации работы, которая была уничтожена с помощью манипулирования и для которой было предложено совершить операцию.

Если параметр "Селектор уведомлений" в спецификации работы, выполняющей манипулирование, имеет установленный бит "Нормальное завершение", то должны вызываться процедуры, описанные п.3.14, для этой спецификации работы, как часть этого элементарного действия с требуемым уровнем совершения операций, равным уровню основного элементарного действия. В таком случае управляющему логическому объекту этой активности не должно предлагаться совершить операцию до тех пор, пока это совершение операции не предложат процедуры, описанные в п.3.14. Этим процедурам следовало бы выполнить отказ, тогда этот отказ должен быть возвращен управляющему логическому объекту.

3.10.7.1. Любые группы совершения операций, инициируемые процедурами, описанными в пп.3.6.4 (примитив J-GIVE), 3.7.5 (Передача), 3.8.4 (примитив J-DISPOSE) и 3.9.2 (примитив J-DISPOSE), должны быть возвращены в первоначальное состояние.

3.10.7.2. Любые группы совершения операций, инициирующие процедуры, описанные в пп.3.4 (примитив J-INITIATE), 3.3 (передача), 3.11 (порождение) и 3.15 (примитив J-MESSAGE) для этой спецификации работы, должны быть отвергнуты с диагностическим сообщением "Не повторять", содержащим код диагностического сообщения службы ПОЗ (JTM) "дп - Уничтожено при манипулировании" и читаемый текст, сформированный функцией MF1.

3.10.7.3. Для любых принимающих и исполняющих агентств, которые имеются, данный уровень совершения операций ПРИНЯТИЕ АГЕНТСТВОМ должен вводиться с группой примитивов J-KILL как часть элементарного действия манипулирования. Значение параметра <Идентификатор активности агентства> для примитива J-KILL выбирается из спецификации работы.

Примечание. Элементарное действие, вызванное введением примитива J-КILL, не может быть отвергнуто.

3.10.7.4. Спецификация работы, над которой должно быть выполнено манипулирование, должна быть сброшена, когда завершится манипулирование.

3.10.7.5. Если уведомления типа ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ, которые были выбраны в спецификации работы, будут сброшены, то должна быть создана новая спецификация работы с типом подзадания "Уведомление" (как это указывается в п.3.10.7.6) и должна быть выполнена, как это указано в п.3.4 (с уровнем совершения операции 1). Эти действия должны выполняться как часть элементарного действия, выполняющего манипулирование, и должны завершаться, если и только если завершится манипулирование.

Примечание. Сбой при выполнении ответвления элементарного действия, доставляющего уведомление, не результируется в сбой этой общей операции манипулирования.

3.10.7.6. Новая спецификация работы должна иметь следующее значение. Поля, скопированные из первоначальной спецификации работы (над которой будет выполняться манипулирование), помечаются словом COPIED (СКОПИРОВАНО). Если эти поля являются частью спецификации, указанной параметром "Спецификация подзадания", то должны использоваться самые последние значения этих полей.

где t - значение параметра "Монитор" из спецификации, указанной параметром "Спецификация первичного монитора";

а - локальное имя службы ПОЗ (JTM), обеспечиваемое локальной функцией MF2 системы административного управления;

время - нулевое значение или время создания новой спецификации работы;

d - нулевое целочисленное значение до тех пор, пока не будет завершено порождение проформы из спецификации работы, когда кации работы*;
________________
* Текст соответствует оригиналу. - Примечание "КОДЕКС".

текст - читаемый текст, сформированный функцией MF1.

Примечание. Реализующая система сама выбирает, вводить в качестве элемента "время" значение времени или нулевое значение.


В таком случае так завершаются процедуры этого пункта.

3.10.8. По значению параметра "Операция манипулирования работой"

должен быть сформирован документ, называемый "у" (с помощью процедур, описанных в пп.3.10.8.1-3.10.8.3), который относится к спецификации работы и который собирается с помощью процедур, описанных в п.3.6.3. Документ собирается, как это указано в п.3.10.8.4.

Если параметр "Селектор уведомлений" в спецификации работы, выполняющей манипулирование, имеет установленный бит "Нормальное завершение", то должны вызываться процедуры, описанные в п.3.14, для этой спецификации работы, как часть этого элементарного действия с требуемым уровнем совершения операций, равным уровню основного элементарного действия. В таком случае управляющему логическому объекту этой активности не должно предлагаться совершить операцию до тех пор, пока это совершение операции не предложат процедуры, описанные в п.3.14. Этим процедурам следовало бы выполнить отказ, тогда этот отказ должен быть возвращен управляющему логическому объекту.

3.10.8.1. Документ должен иметь тип "Документ отображения работы" с единственным значением "ПОСЛЕДОВАТЕЛЬНОСТЬ", содержащим следующие поля:

"Система отображения"

Локальное имя службы ПОЗ (JTM), формируемое функцией MF2;

"Время"

Нулевое значение или время создания документа отображения;

"Отображение"

ПОСЛЕДОВАТЕЛЬНОСТЬ "Короткое отображение", одно значение типа ПОСЛЕДОВАТЕЛЬНОСТЬ для каждой спецификации работы, которая выбирается и отображается.

Примечание. Реализующая система сама выбирает, устанавливать ли в качестве параметра "Время" значение времени или нулевое значение.

3.10.8.2. Параметр "Отображение короткое" должен устанавливаться следующим образом:

"Детали"

СКОПИРОВАНО из соответствующих полей отображаемой спецификации работы.

"Состояние"

Должно быть одно значение состояния станции назначения для каждой из идентифицируемых ситуаций, описанных в пп.3.10.8.2.1-3.10.8.2.3.

"Время"

Должно быть нулевое значение или время, указывающее, когда было введено состояние, о котором было уведомлено, как указано в пп. 3.10.8.2.1-3.10.8.2.3.

3.10.8.2.1. Если выполняется (или находится в состоянии ожидания рестарта) группа совершения операций, инициированная процедурами, описанными в пп.3.6.4 (примитив J-GIVE), 3.7.4 (передача), 3.8.4 (примитив J-DISPOSE) и 3.9.2 (примитив J-DISPOSE), то параметр "Состояние" должен быть установлен в значение "Выполняется", а параметр "Станция назначения" должен иметь значение вызываемого агентства или значение принимающей открытой системы для группы совершения операций, инициируемой процедурами, описанными в п.3.7.4 (передача). Параметр "Время" должен быть установлен в нулевое значение или в значение времени, указывающее, когда для элементарного действия был введен примитив C-BEGIN или примитив J-BEGIN.

3.10.8.2.2. Если принимающее или исполняющее агентство имеет заданный уровень совершения операций ПРИНЯТИЕ и еще не введен примитив J-END-SIGNAL, то параметр "Состояние" должен устанавливаться в значение "Доступно", а параметр "Станция назначения" должен иметь значение принимающего или исполняющего агентства ("пи агентство"). Параметр "Время" должен быть установлен в нулевое значение или в значение, времени, указывающее, когда был введен примитив J-READY агентством, задающим уровень совершения операции ПРИНЯТИЕ.

3.10.8.2.3. Если может быть определено (функции MF20 и MF21), что обработка задерживается из-за недостатка возможности доступа к принимающему, исходному агентству или к получателю информации (с помощью примитивов J-DISPOSE, J-GIVE или P-DATA), параметр "Состояние" должен быть установлен в значение "Ожидание", а параметр "Станция назначения" должен быть установлен в значение требуемого ресурса. Здесь может быть несколько таких элементов. Параметр "Время" должен быть установлен в нулевое значение или в значение времени, указывающее, когда была первая попытка обращения к данному ресурсу (с помощью функции MF20 или MF21).

3.10.8.3. Поле "Сообщение" в параметре "Состояние" должно содержать текст нестандартизованного формата для значения состояния "Выполняется" и "Ожидание", которому следовало бы содержать читаемую информацию, сформированную с помощью функции MF1. Для значения "Доступно" поле "Сообщение" должно содержать текст, полученный при введении в агентство примитива J-STATUS, и текст, ожидающий в примитиве ответа J-STATUS. Этот примитив должен вводиться как часть элементарного действия манипулирования.

Примечание. Рекомендуется, чтобы текст содержал достаточную информацию для указания, когда желательна дальнейшая обработка, и следовало бы указать, должна ли происходить задержка попытки передачи из-за недостатка локальных ресурсов или из-за повторяемых отказов с диагностическим сообщением "ПОВТОРИТЬ ПОЗЖЕ". Если отказ с диагностическим сообщением ПОВТОРИТЬ ПОЗЖЕ" был принят на более раннюю попытку выполнения обработки спецификации работы, которая должна быть отображена, то значение параметра "Повторить позже" <Диагностическое сообщение элемента СПиВ (CCR)> из-за такого отказа должно быть включено в параметр "Состояние" со значением "Ожидание".

3.10.8.3.1. Примитив J-STATUS должен вводиться с параметром <Идентификатор активности агентства>, значение которого берется из спецификации работы, предназначенной для манипулирования, и с индикатором кода диагностического сообщения спецификации работы, выполняющей манипулирование. Параметр "Сообщение" в примитиве ответа J-STATUS должен соответствовать наборам символов, идентифицируемых этим параметром.

3.10.8.3.2. Поле "Сообщение", возвращаемое функцией MF1, должно соответствовать наборам символов, идентифицируемых индикатором кода диагностического сообщения.

3.10.8.4. Порождение (см. п.3.12) должно инициироваться во время завершения документа, как часть первоначального элементарного действия с первоначальным уровнем совершения операций. Совершение операций не должно предлагаться на манипулирование до тех пор, пока не завершатся процедуры, описанные в п.3.12.

Примечание. Эти требования означают, что если примитив запроса J-INITIATE-WORK-MAN указывает уровень совершения операций ПРИНЯТИЕ АГЕНТСТВОМ, то агентство, получающее отображение (обычно такая же схема, как и схема, по которой выполняется примитив J-INITIATE), предлагает совершить операцию, чтобы принять документ до получения предложения о совершении операции для примитива J-INITIATE. Если был указан уровень совершения операций ПРИНЯТИЕ ПОСТАВЩИКОМ, то запрос на манипулирование может быть сохранен и выполнен позже.

3.10.8.5. Процедуры этого пункта завершаются предложением управляющему логическому объекту совершить операцию или завершаются отказом, если процедуры, описанные в п.3.12, сформировали диагностическое сообщение.

3.11. Действие, выполняемое по примитиву запроса J-END-SIGNAL

Описание этого пункта применяется при получении примитива запроса J-END-SIGNAL из агентства, которое задало уровень совершения операций ПРИНЯТИЕ АГЕНТСТВОМ. К процедурам этого пункта имеются ссылки из процедур, описанных пп.3.1, 3.8.8 и 3.9.6. Реализующая система должна убедиться, что параметр адреса главного управляющего логического объекта и идентификатор элементарного действия являются явными, и что агентство указывает уровень совершения операций 1. Индикатор кода диагностического сообщения должен быть таким же, как в соответствующем примитиве J-DISPOSE. Реализующая система также должна убедиться, что примитив C-RESTART вводится после отказа прикладного уровня.

Примечание. Требуется особое внимание в этой области, если программа пользователя используется в качестве исполняющего агентства.

3.11.1. Значение идентификации спецификации работы, при обработке которой формируется соответствующий примитив J-DISPOSE, должно браться из идентификатора активности поставщика, обеспечиваемого в примитиве запроса J-END-SIGNAL.

3.11.2. Процедуры, описанные в п.3.12, должны вызываться как часть элементарного действия примитива J-END-SIGNAL.

3.11.3. Агентство должно отметить документ в качестве удаляемого, когда будет предложено совершить операцию для примитива J-GlVE, по которому собирался этот документ. Любые документы, которые не отмечаются, когда предлагается совершить операцию по примитиву J-END-SIGNAL, должны быть размещены в соответствии с локальной функцией MF18 системы административного управления.

3.11.4. Если процедуры, описанные в п.3.12, выполняют диагностическое сообщение "Не повторять", то порожденная спецификация работы должна быть сохранена логическим объектом службы ПОЗ (JTM) (приведение в первоначальное состояние существующих действий), и примитив ответа J-READY должен обеспечиваться по примитиву J-END-SIGNAL. Сохраненная (но без ошибок) спецификация работы должна затем обрабатываться в соответствии с процедурами, описанными в п.3.5, в результате чего должно быть выдано уведомление и выполнен сброс.

Примечание. Самым распространенным случаем такого действия является неправильное значение параметра "Целевая система" в проформе. Действие по выводу информации, как указано в п.3.11.3, определяется с помощью функции MF18.

3.11.5. Если примитив J-REFUSE вводится в агентство как результат выполнения процедур, описанных в п.3.10.7.2, тогда агентство должно разместить все доступные документы в соответствии с функцией MF18.

3.11.6. Агентство не должно отказываться совершить операцию по примитиву J-END-SIGNAL, если ему это предлагается.

3.11.7. Если параметр "Селектор уведомлений" в спецификации работы, указанной идентификатором активности поставщика, имеет установленный бит "Нормальное завершение", тогда должны вызываться процедуры, описанные в п.3.14 для этой спецификации работы с уровнем совершения операций 1, как часть этого элементарного действия. Если процедуры, описанные в п.3.14, формируют диагностическое сообщение "Не повторять", то новая спецификация работы уведомления должна сбрасываться, а основное элементарное действие должно продолжать совершение операции.

3.11.8. Когда завершится выполнение примитива J-END-SIGNAL, спецификация работы должна быть сброшена, а параметры <Идентификатор активности поставщика> в ней будут использоваться повторно.

3.12. Процедуры порождения

Описание данного пункта применяется для формирования новых спецификаций работы из проформ верхнего уровня в спецификации работы. Процедуры этого пункта вызываются процедурами, описанными в пп.3.11.2, 3.10.8.4 и 3.8.7. Процедуры имеют доступ к спецификации работы с идентификатором активности агентства для любого исполняющего агентства, в котором активность выполняется с помощью процедур, описанных в п.3.8.

3.12.1. Процедуры, описанные в пп.3.12.2 и 3.12.3, должны вызываться для той проформы в списке проформ, которая завершает процедуры этого пункта.

3.12.2. Спецификация работы должна формироваться, как показано ниже (слово СКОПИРОВАНО указывает на самое последнее значение полей в первоначальном элементе передачи):

3.12.3. Процедуры, описанные в п.3.4, должны применяться к новой спецификации работы. Параметр <Идентификатор активности агентства> для исполняющего агентства доступен этим процедурам для сбора документов из этого агентства.

Примечание. Для индивидуальной реализующей системы важно либо направить отказ немедленно с помощью элемента передачи, который был сформирован при порождении, тогда

а) результатом является диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ", либо

б) обеспечивает принятие поставщиком новой спецификации работы (если это допустимо) после разрешения ссылок к исполняющим агентствам.


Это различие является внешне видимым с помощью процедур манипулирования работой; первоначально спецификация работы остается видимой в случае перечисления а), а новая спецификация работы - в случае перечисления б). Оно также воздействует и на простоту реализующей системы и на обеспечиваемую услугу. Выбор п.3.12.3 б) обычно более предпочтителен, но если продвижение вперед элемента передачи невозможно, он требует использовать указатели к собранному в спул материалу в исполняющих агентствах или требует "двойной спулинг".

3.13. Формирование уведомления АВАРИЙНОЕ ЗАВЕРШЕНИЕ

К процедурам данного пункта имеются ссылки из процедур, описанных в п.3.5.6.

3.13.1. Спецификация работы уведомления должна формироваться и обрабатываться как отдельное элементарное действие для передачи уведомления об аварийном завершении, как это указано в пп.3.13.2 и 3.13.3.

3.13.2. Новая спецификация работы с типом подзадания "Перемещение уведомления" должна создаваться (как указано в п.3.13.3) и обрабатываться, как это указано в п.3.4 (с уровнем совершения операций 1).

Новая спецификация работы должна сохраняться как часть первоначального элементарного действия и обрабатываться в отдельном элементарном действии. Так завершаются процедуры этого пункта.

3.13.3. Новая спецификация работы должна иметь следующее значение. Поля, скопированные из первоначальной спецификации работы, отмечаются словом СКОПИРОВАНО. Если эти поля являются частью спецификации, указанной параметром "Спецификация подзадания", то должно использоваться самое последнее значение.

где t - значение параметра "Монитор" из спецификации, указанной параметром "Спецификация первичного монитора";

а - локальное имя службы ПОЗ (JTM), обеспечиваемое локальной функцией MF2 системы административного управления;

время - нулевое значение или время создания новой спецификации работы;

текст - читаемый текст, сформированный функцией MF1.

Примечание. Реализующая система сама выбирает, вводить в качестве элемента "время" значение времени или нулевое значение.

3.13.3.1. Значение "d" должно приниматься из параметра "Не повторять <Диагностическое сообщение элемента СПиВ (CCR)>". Если диагностическое сообщение получается в результате выполнения локального доступа к исходному агентству (см. п.3.6.5), значение "Детали исходного агентства" ВЫБОРОЧНЫЙ ТИП должно использоваться со значениями параметров "Агентство" и "Имя документа", скопированных из первоначальной спецификации работы. Если диагностическое сообщение получается в результате выполнения локального доступа к принимающему агентству, значение "Детали пи" ВЫБОРОЧНЫЙ ТИП должно использоваться с таким же значением параметра "Имя документа", как и в примитиве J-DISPOSE. Если диагностическое сообщение получается в результате попытки передачи, то значение "Детали принимающего пользователя" ВЫБОРОЧНЫЙ ТИП должно использоваться, и значение параметра "Имя службы ПОЗ (JTM)" должно устанавливаться в такое имя, с которым выполнялась попытка передачи.

3.13.3.2. Если диагностическое сообщение было сформировано без какой-либо прямой ассоциации с предпринимаемой попыткой доступа к исходному или принимающему агентству (см. п.3.6.3) или попыткой передачи, то должно использоваться значение "Поставщик" ВЫБОРОЧНЫЙ ТИП.

3.13.3.3. Значение параметра "Штамп времени" в элементе "d" должно представлять собой время, указывающее, когда элемент "d" был сформирован.

3.1.3.4. Значения параметров <Время ожидания> и <Подсчитанный размер> должны устанавливаться, как это описано в 3.2.1. Параметр <Параметры элемента СПиВ (CCR)> должен быть отмечен словом СКОПИРОВАНО. Здесь не должно быть документов. Это завершает спецификацию работы уведомления.

3.14. Формирование уведомления НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ

К процедурам данного пункта имеются ссылки из процедур, описанных в п.3.8.7 (процедуры перемещения документа), пп.3.10.6-3.10.8 (процедуры манипулирования работой) и п.3.11.7 (примитивы запроса J-END-SIGNAL).

3.14.1. Спецификация работы уведомления должна формироваться и обрабатываться как часть основного элементарного действия для доставки (совершение операций должно быть упорядочено) уведомления о нормальном завершении, как указано в пп.3.14.2 и 3.14.3.

3.14.2. Новая спецификация работы с типом подзадания "Перемещение уведомления" должна создаваться (как указано в п.3.14.3) и обрабатываться, как это указано в п.3.4.

3.14.3. Новая спецификация работы должна иметь следующее значение. Поля, скопированные из первоначальной спецификации работы, отмечаются словом СКОПИРОВАНО. Если эти поля являются частью спецификации, указанной параметром "Спецификация подзадания", то должно использоваться самое последнее значение.

где t - значение параметра "Монитор" из спецификации, указанной параметром "Спецификация первичного монитора";

а - локальное имя службы ПОЗ (JTM), обеспечиваемое локальной функцией MF2 системы административного управления;

время - нулевое значение или время создания новой спецификации работы;

d - нулевое целочисленное значение до тех пор, пока не будет завершено порождение проформы из спецификации работы, когда проформа не станет спецификацией работы;

текст - читаемый текст, сформированный функцией MF1.

Примечание. Реализующая система сама выбирает, вводить в качестве элемента "время" значение времени или нулевое значение.


В таком случае так завершаются процедуры этого пункта.

3.15. Действие по примитивам запроса J-MESSAGE

Описание данного пункта применяется при приеме примитива запросa J-MESSAGE либо из агентства, обрабатывающего примитив индикации J-DISPOSE, либо из агентства, которое задало уровень совершения операций ПРИНЯТИЕ АГЕНТСТВОМ на такую индикацию, но еще не ввело примитив запроса J-END-SIGNAL. Реализующая система должна убедиться, что элементарное действие по примитиву J-MESSAGE является ответвлением элементарного действия по примитиву J-DISPOSE в первом случае. Во втором случае она должна убедиться, что параметр адреса главного управляющего логического объекта и идентификатор элементарного действия являются явными. Индикатор кода диагностического сообщения должен быть таким же, как в соответствующем примитиве J-DISPOSE. В третьем случае после ПРИНЯТИЯ АГЕНТСТВОМ реализующая система также должна убедиться, что примитив C-RESTART вводится после отказа прикладного уровня.

3.15.1. Значение идентификации спецификации работы, при обработке которой формируется соответствующий примитив J-DISPOSE, должно браться из идентификатора активности поставщика, обеспечиваемого в примитиве запроса J-MESSAGE.

3.15.2. Если параметр "Селектор уведомлений" в спецификации работы не имеет установленный бит "Сообщение пользователя", то совершение операции предлагается управляющему логическому объекту. Если бит "Сообщение пользователя" установлен, то должны применяться процедуры, описанные в пп.3.15.3-3.15.5.

3.15.3. Спецификация работы уведомления должна формироваться и обрабатываться как часть элементарного действия примитива J-MESSAGE для доставки (совершение операций должно быть упорядочено) уведомления "Сообщение пользователя", как указано в пп.3.15.4 и 3.15.5.

3.15.4. Новая спецификация работы с типом подзадания "Перемещение уведомления" должна создаваться (как указано в п.3.15.5) и обрабатываться, как это указано в п.3.4.

3.15.5. Новая спецификация работы должна иметь следующее значение. Поля, скопированные из первоначальной спецификации работы, отмечаются словом СКОПИРОВАНО. Если эти поля являются частью спецификации, указанной параметром "Спецификация подзадания", то должно использоваться самое последнее значение.

где t - значение параметра "Монитор" из спецификации, указанной параметром. "Спецификация первичного монитора";

а - локальное имя службы ПОЗ (JTM), обеспечиваемое локальной функцией MF2 системы административного управления;

время - нулевое значение или время создания новой спецификации работы;

текст - значение параметра <Сообщение> в примитиве запроса J-MESSAGE.

Примечание. Реализующая система сама выбирает, вводить в качестве элемента "время" значение времени или нулевое значение.


В таком случае так завершаются процедуры этого пункта.

РАЗДЕЛ 4. ФУНКЦИОНИРОВАНИЕ СЛУЖБЫ ПОЗ (JTM)

В разд.3 данного стандарта определяется требуемое динамическое согласование реализующей системы. Данный раздел описывает дальнейшие требования службы ПОЗ (JTM). Эти требования состоят из:

а) требований статической согласованности;

б) требований, относящихся к использованию определенных терминов для описания функционирования реализующей системы;

в) требований, относящихся к информационным данным системы административного управления, представленных в приложении А;

г) требований к документации.

Эти требования описываются в следующих пунктах.

4.1. Требования статической согласованности

4.1.1. Реализующая система должна удовлетворять требованиям согласованности стандарта ИСО 9805 (протокол элемента СПиВ (CCR) и должна обслуживать спецификации работы в качестве сохраняемых данных, как это указано в данном стандарте.

4.1.2. Реализующая система должна обеспечивать установление контекста прикладного уровня (см. п.2.2.5.1) или для контекста типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", или для передач выходных данных, или для передач входных данных, или для тех и других. Она должна обеспечивать все средства установления этого контекста прикладного уровня, используя механизмы ГОСТ 34.981, как это указано в разд.5 данного стандарта.

4.1.3. Реализующая система должна обеспечивать установление контекста уровня представления (см. п.2.2.5.2) для синтаксиса типа "Абстрактный синтаксис службы ПОЗ (JTM) модели ВОС" (контекст уровня представления службы ПОЗ (JTM)) и должна иметь возможность предлагать и допускать синтаксис типа "Синтаксис передачи службы ПОЗ (JTM) модели ВОС" (см. п.2.2.5.3).

Примечание. Предложение или допустимость других синтаксисов передачи, зарегистрированных в реестре для использования с абстрактным синтаксисом типа "Абстрактный синтаксис службы ПОЗ (JTM) модели ВОС", не отвергается, но и не требуется.


Реализующая система должна обеспечивать все средства установления такого контекста, используя механизмы ГОСТ 34.971, как это указывается в разд.5 данного стандарта.

4.1.4. Реализующая система должна обеспечивать средства, чтобы настраивать конфигурацию адресной информации, которая должна использоваться удаленными системами, чтобы устанавливать ассоциации прикладного уровня для использования в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" (функция MF22).

4.1.5. Реализующая система должна обеспечивать средства, чтобы настраивать конфигурацию адресной информации, которая содержится в адресных полях вызывающего пользователя для ассоциаций прикладного уровня и устанавливается для использования логическим объектом службы ПОЗ (JTM) (функция MF23).

4.1.6. Реализующая система должна убедиться, что:

а) все установленные ассоциации прикладного уровня, использующие адресную информацию (указано в п.4.1.4), способны установить (каналы связи подвержены перегрузке) контекст типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", как это указано в разд.5, а затем работать, как это указано в разд.3;

б) все ассоциации прикладного уровня, установленные с адресной информацией вызывающего пользователя, указанной в п.4.1.5, и работающие в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС", являются результатом выполнения процедур, описанных в разд.3;

в) механизмы для изменения информационных данных локальной системы административного управления, используемых для поименования, адресации и аутентификации (функции MF2, MF4, MF5, MF6, MF7, MF8, MF9, MF11, MF12, MF13, MF15, MF16, MF17), защищены от несанкционированного использования.

4.1.7. Реализующая система должна обеспечивать, по крайней мере, одно агентство службы ПОЗ (JTM).

4.1.8. Реализующая система должна обеспечивать и уровень совершения операций "ПРИНЯТО ПОСТАВЩИКОМ", и уровень совершения операций "ПРИНЯТО АГЕНТСТВОМ" при доступе к локальным агентствам.

4.1.9. Реализующая система должна обеспечивать формирование всех возможных значений данных типа "Графическая строка" в любом поле, использующем этот тип данных.

Примечание. Это должно обеспечиваться при переводе в шестнадцатеричную нотацию для символьных репертуаров, которые непосредственно не обеспечиваются этой реализующей системой.

4.1.10. Реализующая система должна обеспечивать отображение всех возможных значений данных типа "Графическая строка" во время отображения полей, использующих этот тип данных.

Примечание. Это должно обеспечиваться при переводе в шестнадцатеричную нотацию для символьных репертуаров, которые непосредственно не обеспечиваются этой реализующей системой.

4.1.11. Реализующая система должна обеспечивать формирование и отображение всех возможных значений данных типа "СТРОКА ОКТЕТОВ" для полей, использующих этот тип данных.

4.1.12. Реализующая система должна обеспечивать формирование текста диагностического сообщения и текста о состоянии, используя только международную версию указателя ГОСТ 27463. Дополнительно она может обеспечивать формирование такого текста, используя другие наборы символов.

Примечание. Национальные стандарты, которые в ином случае эквивалентны данному стандарту, могут изменить это требование.

4.1.13. В следующих подпунктах описывается определение обеспечения, требуемое для типов данных нотации АСН.1. В этих пунктах слово "обеспечить" должно интерпретироваться следующим образом:

а) для любого параметра, который принимается из сервисного примитива или с помощью локальной функции системы административного управления, реализующая система должна обеспечивать средства формирования всех возможных значений вплоть до ограничений, устанавливаемых ниже;

б) для любого параметра, значения которого используются для обеспечения услуги или формирования информации для пользователя, необходимо, чтобы все его значения вплоть до ограничений, устанавливаемых ниже, допускались и обрабатывались, как это указано в пп.3.1-3.15 (процедуры службы ПОЗ (JTM));

в) реализующая система не должна требовать представления параметров, превышающих ограничения, установленные ниже, для того чтобы обеспечить услугу службы ПОЗ (JTM) базисного класса;

г) реализующая система, которая автоматически формирует значения параметров, не должна формировать значения, превышающие ограничения, устанавливаемые ниже.

4.1.13.1. Реализующие системы данного стандарта должны обеспечивать все данные типа "Графическая строка", содержащие до 40 символов, кроме тех, которые были установлены иным способом.

4.1.13.2. Реализующие системы данного стандарта должны обеспечивать все значения данных типа "ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ" и "МНОЖЕСТВО ИЗ", которые включают менее 10 элементов, кроме тех, которые были установлены иным способом.

Примечание. Разрешается обеспечение для других значений, допускаемых нотацией АСН.1, но это обеспечение не имеет требования согласованности.

4.1.13.3. Реализующая система должна обеспечивать значение данных типа "ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ Короткое отображение" в документе типа "Документ отображения работы", содержащем до 256 элементов.

4.2. Функциональные классы

Функции реализующей системы службы ПОЗ (JTM) относятся к агентствам, которые она обеспечивает. Реализующая система службы ПОЗ (JTM) может обеспечивать только одно агентство, несколько агентств одного типа или несколько агентств разных типов.

Если сервисные примитивы службы ПОЗ (JTM) вводятся с помощью ссылки из какого-либо другого стандарта, то тот стандарт должен указывать природу агентств службы ПОЗ (JTM) и использование данного пункта. Если для обеспечения услуги используется только данный стандарт (на уровне пользователя), то применяется данный пункт.

Реализующая система службы ПОЗ (JTM) должна использовать приведенные в таблице термины для описания функционирования, определяемого в соответствующем пункте.

4.2.1. Обеспечение для предъявления задания модели ВОС службы ПОЗ (JTM) базисного класса

4.2.1.1. Реализующая система обеспечивает механизмы для возможности формирования группы примитивов J-INITIATE.

4.2.1.2. Эти механизмы разрешают использовать полный ряд значений базисного класса, которые должны использоваться для параметров примитива J-INITIATE и сервисных примитивов типа "J-", относящихся к элементу СПиВ (CCR).

4.2.1.3. Реализующая система гарантирует, что правильная последовательность примитивов и режим рестарта не зависят от пользователя, кроме случая, описанного в п.4.4.12.

4.2.1.4. Если реализующая система также требует обеспечения службы ПОЗ (JTM) для локального файлохранилища, то она способна принимать данные для документов, указанных в примитиве J-INITIATE, из файлохранилища.

4.2.1.5. Реализующая система обеспечивает передачу документов типа "ИСО Простой текстовый документ модели ВОС" (см. приложение Б) и предоставляет пользователю возможность формировать все значения таких документов для включения в примитив J-INITIATE.

4.2.1.6. Реализующая система обеспечивает все уровни совершения операций базисного класса службы ПОЗ (JTM) (в качестве главного управляющего логического объекта элемента СПиВ (CCR)).

Примечание. Эта реализующая система, которая должна быть способна только вызывать выполнение вывода, обеспечиваемого монитором, устанавливается в некоторую другую открытую систему с соответствующими элементами санкционирования (см. описание функций MF3 и MF6).

4.2.2.Обеспечение для монитора службы ПОЗ (JTM) базисного класса

4.2.2.1. Реализующая система содержит принимающее агентство, для которого уведомления службы ПОЗ (JTM) могут быть переданы в примитиве J-DISPOSE.

4.2.2.2 Уведомления преобразовываются в формат, понятный для наблюдателя, и принимаются наблюдателем. И код диагностического сообщения службы ПОЗ (JTM), и читаемый текст выполняются доступными.

Примечания:

1. Информация может быть помещена в файлохранилище, в электронный почтовый ящик, послана на терминал или распечатана.

2. Реализующая система должна быть способна только к приему входных вызовов.

3. Способ, при котором информация делается понятной и доступной, устанавливается в документации (см. п.4.4.10).

4.2.3. Обеспечение для манипулирования службы ПОЗ (JTM) базисного класса

4.2.3.1. Реализующая система удовлетворяет требованиям пп.4.2.1.1-4.2.1.6 для примитива J-INITIATE-WORK-MAN.

Примечание. Обеспечение для примитива J-INITIATE-WORK не требуется, а примечание в п.4.2.1.6 в этом случае не применимо.

4.2.3.2. Реализующая система обеспечивает передачу документов типа "Документ отображения работы службы ПОЗ (JTM) модели ВОС" (см. приложение Б).

4.2.3.3. Реализующая система содержит принимающее агентство, в которое документ типа "Документ отображения работы службы ПОЗ (JTM) модели ВОС" может быть передан в примитиве J-DISPOSE.

4.2.3.4. Документ преобразуется в формат, понятный для наблюдателя, и является доступным для наблюдения (см. п.4.2.2.2.).

4.2.3.5. Если пользователь запрашивает совершить операцию с уровнем "ЗАВЕРШЕНИЕ", то действие, описанное в п.4.2.3.4, имеет место перед предложением совершить операцию для отображения работы.

Примечание. Это обеспечение предполагается для подключения взаимодействующего пользователя, чтобы инициировать манипулирование и, в зависимости от доступности взаимосвязи и других ресурсов, получить непосредственное отображение службы ПОЗ (JTM) до совершения операции.

4.2.4. Обеспечение службы ПОЗ (JTM) базисного класса для локального файлохранилища

4.2.4.1. Реализующая система обеспечивает передачу документов типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" (см. приложение Б).

4.2.4.2. Реализующая система обеспечивает механизмы для подготовки и отображения всех значений документов с семантиками типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" при обеспечении их передачи.

4.2.4.3. Реализующая система содержит принимающее агентство, в которое документы типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" могут быть переданы в примитиве J-DISPOSE.

4.2.4.4. Документы преобразуются в формат локальной системы и помещаются в локальное файлохранилище, используя параметр "Указатель пи документа" при формировании имени файла.

4.2.4.5. Имя агентства "FILE" используется для основного локального файлохранилища, обеспечиваемого этой реализующей системой.

4.2.4.6. Любой существующий файл с таким же именем в качестве значения параметра "Указатель пи документа" перезаписывается в зависимости от адекватного санкционирования. Если такой файл не существует, то создается новый файл.

4.2.4.7. Описание п.4.2.1.4 применяется, если также требуется обеспечение для предъявления задания модели ВОС службы ПОЗ (JTM) базисного класса.

4.2.5. Обеспечение службы ПОЗ (JTM) базисного класса для механизма вывода

4.2.5.1. Реализующая система обеспечивает передачу документов типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" (см. приложение Б).

4.2.5.2. Реализующая система содержит принимающее агентство, в которое документы типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" могут быть переданы в примитиве J-DISPOSE.

4.2.5.3. Документы отображаются согласно семантикам документов, указываемых для этого типа документа. Индикаторы управления отображением документа типа "ИСО Простой документ для печати службы ПОЗ (JTM)" обеспечиваются и правильно интерпретируются относительно этого средства (см. также п.4.4.9).

4.2.5.4. Документ не должен отображаться до тех пор, пока будет предложен уровень совершения операции "ПРИНЯТИЕ АГЕНТСТВОМ", но он должен быть записан в качестве сохраненных данных. Задается только уровень совершения операции "ЗАВЕРШЕНИЕ" (или примитив J-END-SIGNAL), если документ был полностью отображен.

4.2.5.5. Имя агентства "PRINTER" используется для основного механизма вывода, обеспечиваемого реализующей системой.

4.2.5.6. Параметр "Указатель пи документа" используется при формировании заголовка для документа. Если элемент санкционирования является допустимым, то значение параметра "Идентификация" в этом элементе также используется при формировании заголовка.

4.2.5.7. Если обеспечивается уровень совершения операции "ПРИНЯТИЕ АГЕНТСТВОМ", то обеспечиваются примитивы J-STATUS, J-STOP и J-KILL.

4.2.6. Обеспечение службы ПОЗ (JTM) базисного класса для обработки задания

4.2.6.1. Реализующая система обеспечивает передачу документов типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" (см. приложение Б).

4.2.6.2. Реализующая система содержит исполняющее агентство, для которого документ типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" может быть передан в примитиве J-DISPOSE.

4.2.6.3. Документ содержит зависимое от реализующей системы описание требуемой обработки задания.

4.2.6.4. В заголовке документа может потребоваться дополнительная управляющая информация (например, параметры планирования). Дополнительное санкционирование также может требоваться в заголовке документа.

4.2.6.5. Реализующая система обеспечивает для документов, сформированных в результате обработки задания таким образом, чтобы эти документы были сцеплены в один документ и чтобы сделать доступными с предсказуемым именем в качестве документа типа "ИСО Простой документ для печати службы ПОЗ (JTM)".

Примечание. Имя документа может зависеть от содержания начального документа или может быть фиксированным.

4.2.6.6. Имя агентства "JOBMILL" используется для основного средства обработки задания, обеспечиваемого этой реализующей системой.

4.2.6.7. Обеспечиваются примитивы J-STATUS, J-STOP и J-KILL.

4.2.6.8. Агентство игнорирует значение параметра "Указатель пи документа" в примитиве J-DISPOSE.

4.2.6.9. Если реализующая система требует обеспечение службы ПОЗ (JTM) базисного класса для локального файлохранилища, то она обеспечивает доступ к такому файлохранилищу как к части исполняющего агентства.

4.2.7. Обеспечение службы ПОЗ (JTM) базисного класса на языке xyz

4.2.7.1. В этом пункте термин "Язык xyz" означает любой язык программирования, указанный пользователем реализующей системы.

4.2.7.2. Реализующая система обеспечивает средства для любой программы, написанной на языке xyz, чтобы выполнить действия, которые позволяют ей вводить и принимать сервисные примитивы службы ПОЗ (JTM) с полным рядом значений параметров базисного класса службы ПОЗ (JTM) и элемента СПиВ (CCR). Программа способна действовать (одновременно) в качестве одного или нескольких типов агентств службы ПОЗ (JTM).

4.2.7.3. Имена агентств, которые представляет программа, не могут быть использованы другими программами; программа не может использовать имена агентств, назначенные другим программам.

4.2.7.4 Правильный режим реализующей системы службы ПОЗ (JTM) не зависит от правильного режима программы.

4.2.7.5. Реализующая система обеспечивает передачу, по крайней мере, документов типа "ИСО Простой текстовый документ службы ПОЗ (JTM)" и типа "ИСО Простой документ для печати службы ПОЗ (JTM)" (см. приложение Б) и включает программу на языке xyz для чтения или для формирования полного ряда таких документов.

Примечание. Точный формат языка, связанного с сервисными примитивами службы ПОЗ (JTM), может быть объектом для будущего стандарта, но не имеет ограничений, накладываемых на него данным стандартом.

4.2.8. Полное обеспечение службы ПОЗ (JTM) базисного класса

Реализующая система содержит все функциональные возможности, определенные в пп.4.2.1-4.2.6, и определяет, какие языки, если они имеются, обеспечивают службу ПОЗ (JTM); как это описано в п.4.2.7.

Примечание. Если реализующая система обеспечивает несколько механизмов печати, файлохранилищ, средств разделения работы или языков, то обеспечение службы ПОЗ (JTM), по крайней мере одного из них, представляет собой только выполнение требований, указанных в данном стандарте. Если реализующая система будет получена из другой части, то обеспечиваются детали каждого механизма, которые должны устанавливаться.

4.3. Функциональные требования системы административного управления

4.3.1. Какая-либо локальная функция системы административного управления, на которую не имеется ссылок в следующих пунктах, может возвратить фиксированные значения, выбранные реализующей системой. Она может представлять нулевое функционирование.

4.3.2. Если в следующих пунктах требуются значения функций, которые должны иметь перестраиваемую конфигурацию, то средства конфигурации не указываются в данном стандарте и не имеют ряда значений, которые должны обеспечиваться.

4.3.3. Значения функций MF2 (локальное имя), MF3 (первичный монитор), MF17 (визуальность), MF22 и MF23 (адресация) должны иметь перестраиваемую конфигурацию.

4.3.4. Если функция MF8 (опознавание адреса вызывающего пользователя) обеспечивается со значениями, отличными от значения "НЕИЗВЕСТНЫЙ", то значение строки параметра "Имя службы ПОЗ (JTM)" должно иметь перестраиваемую конфигурацию.

4.3.5. Если обеспечиваются функции MF9 (список обработки вызовов), MF11 (требуемое санкционирование), MF13 (доверенная реализующая система) или MF16 (санкционирование для передачи), то значение параметра "Имя службы ПОЗ (JTM)", который эти функции использует, должно иметь перестраиваемую конфигурацию.

4.3.6. Любые значения параметра "Санкция идентификации пользователя", используемые в функциях MF12 (распознаваемые санкции идентификации пользователя), MF15 (санкционирование агентства) или MF16 (санкционирование для передачи), должны иметь перестраиваемую конфигурацию.

4.3.7. Значения адресов удаленных объектов, используемые в функции MF16 (санкционирование для передачи), должны иметь перестраиваемую конфигурацию.

4.3.8. Функции MF22 и MF23, на которые имеются ссылки в пп.4.1.4, 4.1.5 и 4.1.6, должны иметь значения, которые имеют перестраиваемую конфигурацию.

4.4. Документация

Реализующая система должна или удовлетворять требованиям документации настоящего стандарта, который затем определяет использование этого пункта, или должна удовлетворять всем следующим подпунктам.

4.4.1. В документации должно быть определено, какие из определенных в п.4.2 терминов применяются, и должны быть определены механизмы или средства, с которыми связаны соответствующие агентства.

4.4.2. Для каждого механизма или средства, которые связаны с агентством службы ПОЗ (JTM), должны быть определены события и состояния, вызывающие группы примитивов службы ПОЗ (JTM), которые должны вводиться, или влияющие на значения параметров. Должны быть определены события и состояния, получающиеся в результате введения группы примитивов службы ПОЗ (JTM) или под влиянием значений параметров.

4.4.3. Для каждого языка программирования, который обеспечивает службу ПОЗ (JTM) (см. п.4.2.7), должен быть определен интерфейс для введения и приема сервисных примитивов службы ПОЗ (JTM).

4.4.4. Должны быть определены значения, возвращаемые всеми локальными функциями системы административного управления. Если эти значения могут полностью или частично изменяться локальной системой административного управления, то должны быть определены средства такой конфигурации.

4.4.5. Если описание, приведенное в п.3.8.4.6 (отображение в локальные имена), применяется для агентства, то должна быть определена возможность отображения.

4.4.6. Должны быть определены очередность и способ обслуживания очереди для входящих вызовов, которые находятся в ожидании, и для обрабатывающихся спецификаций работы, ожидающиеся для агентств или для выходных вызовов. Должен быть определен алгоритм для выполнения дальнейших попыток после диагностического сообщения "ПОВТОРИТЬ ПОЗЖЕ" (см. п.3.5.3). Должна быть определена устойчивость реализующей системы, см. п.3.5.2б).

4.4.7. Должно быть определено действие, предпринимаемое (если это необходимо) при приеме несанкционированных вызовов (см. п.3.3.3).

4.4.8. Должно быть определено содержимое документов, которые должны быть предъявлены в исполняющее агентство.

4.4.9. Для любого механизма, действующего в качестве принимающего агентства, должен быть определен способ, по которому локально сохраняются или распечатываются документы типа "ИСО Простой документ для печати службы ПОЗ (JTM)" и типа "ИСО Простой текстовый документ службы ПОЗ (JTM)". Это описание должно включать детали обработки слишком длинных строк и символьных репертуаров, которые непосредственно не обеспечиваются.

4.4.10. Для любого механизма, действующего в качестве принимающего агентства, должен быть определен способ формирования и размещения уведомлений (см п.4.2.2.2.).

4.4.11. Для любого механизма или интерфейса, обеспечивающего примитив J-INITIATE, должно быть определено время связи данных, указываемое примитивом J-INITIATE.

4.4.12. В документации должны быть определены локальные процедуры восстановления при ошибках, которые должны выполняться после сбоя прикладного уровня.

4.4.13. В документации должны быть ссылки на данный стандарт и на некоторые поправки и дополнения, которым это описание соответствует, определяя согласованную реализующую систему.

4.4.14. В документации должны быть определены типы документов, обеспечиваемые для передачи службы ПОЗ (JTM), способ, по которому документы этих типов сохраняются или распечатываются с помощью какого-либо механизма, действующего в качестве принимающего агентства, а также способ, по которому они подготовляются для какого-либо механизма, действующего в качестве исходного агентства. Должны быть определены какие-либо ограничения, которые препятствуют отображению или подготовке полного ряда документов этих типов.

4.4.15. В документации должен быть определен ряд национальных языков и наборы символов, с помощью которых реализующая система может формировать диагностические сообщения и сообщения о состоянии в ответ на полученный индикатор кода диагностического сообщения элемента СПиВ (CCR).

РАЗДЕЛ 5. ПЕРЕДАЧИ СЛУЖБЫ ПОЗ (JTM)

5.1. Управление ассоциацией прикладного уровня

В этом пункте описывается использование примитивов, связанных с управлением ассоциацией прикладного уровня. Для примитивов запроса и ответа параметры должны быть такими, как это указано в п.5.2. Для примитивов индикации и подтверждения должна выполняться проверка того, что данные параметры имеют значения, разрешаемые условиями, представленными в п.5.2.

5.1.1. Обозначение

Процедуры указываются значениями, представленными в таблице состояний, которая определяет взаимодействия процедур управления ассоциацией прикладного уровня службы ПОЗ (JTM), процедуры для получения и передачи спецификации работы (см. пп.3.3 и 3.7) и услугу управления ассоциацией, определенную в ГОСТ 34.981.

5.1.1.1. Используемые таблицы

5.1.1.1.1. В п.5.1 определяется единственный набор процедур управления ассоциацией с помощью значений таблицы состояний. Таблица состояний показывает взаимосвязь между состоянием процедур, входящими событиями, которые могут иметь место в данном состоянии, действиями, которые должны быть предприняты, и, наконец, окончательным состоянием этих процедур.

5.1.1.1.2. В этом пункте содержатся следующие таблицы:

а) в табл.1 определяются сокращенные имена и имена (описания) каждого входящего события;

б) в табл.2 определяются сокращенные имена каждого состояния;

в) в табл.3 определяются утверждения;

г) в табл.4 определяются сокращенные имена и имена (описания) каждого выходящего события;

д) табл.5 представляет собой таблицу состояний и использует сокращения, представленные в таблицах 1-4.

5.1.1.2. Соглашения, используемые в табл.5

5.1.1.2.1. Точка пересечения входящего события (ряд) и состояния (колонка) представляет собой клетку.

5.1.1.2.2. В табл.5 пустая клетка представляет комбинацию входящего события и состояния, которые вместе не являются частью нормальной операции этого протокола (см. п.5.1.1.3.2).

5.1.1.2.3. Заполненная клетка представляет входящее событие и состояние, которые вместе являются частью нормальной операции этого протокола. Такая клетка содержит список одного или нескольких действий. Список действий может быть либо обязательным, либо условным. Если клетка содержит обязательный список действий, он представляет собой список действий только в этой клетке.

5.1.1.2.4. Обязательный список действий содержит:

a) входящее событие;

б) результирующее состояние.

5.1.1.2.5. Условный список действий содержит:

а) выражение утверждения, содержащее утверждения и операторы булевского типа;

б) обязательный список действий. (Этот обязательный список действий используется, если только выражение утверждения является истинным).

5.1.1.3. Действия, которые должны быть предприняты

5.1.1.3.1. Табл.5 определяет действие, которое должно быть предпринято в терминах выходящего события и состояния, полученных в результате выполнения процедур.

5.1.1.3.2. Пустые клетки указывают неправильную точку пересечения входящего события и состояния. Если такая точка пересечения имеет место, то предпринимается одно из следующих действий:

а) если входящее событие происходит от пользователя услуги, то любое предпринимаемое действие является делом локальной системы, но не должно быть внешне видимым и не должно воздействовать на состояние ассоциации прикладного уровня. (Это эквивалентно утверждению, что концептуальный уровень таких событий не имеет места);

б) если входящее событие является событием услуги уровня представления, то ассоциация прикладного уровня должна быть завершена со сбоем и все последующие действия должны следовать правилам элемента СПиВ (CCR).

5.1.1.3.3. Если точка пересечения состояния и входящего события не является пустой клеткой, то предпринимается одно из следующих действий:

а) если клетка содержит единственный обязательный список действий, то должны предприниматься указанные действия;

б) если клетка содержит один или несколько условных списков действий, то для первого выражения утверждения, которое является истинным, должны предприниматься указанные действия, а оставшиеся списки действий должны игнорироваться; если истинных выражений утверждения нет, то должны выполняться действия, которые определены в п.5.1.1.3.2.

5.1.2. Процедуры

5.1.2.1. В табл.1 перечисляются события, входящие в процедуры управления ассоциацией прикладного уровня службы ПОЗ (JTM) либо из процедур, описанных в п.3.7, либо из функций системы административного управления, либо из сервисного элемента управления ассоциацией.

5.1.2.2. В табл.2 перечисляются возможные состояния управляющих процедур прикладного уровня службы ПОЗ (JTM).

5.1.2.3. В табл.3 перечисляются утверждения.

5.1.2.4. В табл.4 перечисляются события, выходящие из процедур управления ассоциацией прикладного уровня службы ПОЗ (JTM) либо в процедуры, описанные в п.3.3, либо в процедуры, описанные в п.3.7, либо в функции системы административного управления, либо в сервисный элемент управления ассоциацией.

5.1.2.5. Таблица состояний процедур управления ассоциацией прикладного уровня службы ПОЗ (JTM) задается табл.5. В представленных ниже табл.1-8 имеются следующие сокращения:

уст - установление;

осв - освобождение;

инд - индикация;

подтв - подтверждение;

запр - запрос;

отв - ответ.

Таблица 1

Входящие события

Таблица 2

Состояния процедур

Таблица 3

Утверждения

Таблица 4

Выходящие события

Таблица 5

Таблица состояний (событий)

5.1.3. Коды возврата "ASSOподтв-"

Если ассоциация устанавливается для того, чтобы выполнять процедуры для передачи спецификаций работы (см.п.3.7), (с помощью функции MF16), и имеет место какой-либо отказ, то информация об ошибке предоставляется при событии "ASSOподтв-" (см. п.5.1.2.4) в форме кодов возврата. Они оказывают влияние на режим основных процедур службы ПОЗ (JTM), описанных в п.3.7.

5.1.3.1. Если установление ассоциации отвергается с помощью примитива подтверждения A-ASSOCIATE (Результат="Отвергнуто…") и результатом является сообщение "Отвергнуто ответственным логическим объектом (постоянная ошибка)" или "Отвергнуто поставщиком услуг уровня представления (постоянная ошибка)", диагностическое сообщение "НЕ ПОВТОРЯТЬ" должно быть возвращено с кодом диагностического сообщения службы ПОЗ (JTM) "оу - ошибка передачи", и функцией MF1 предоставляется читаемый текст. Во всех других случаях использования примитива подтверждения A-ASSOCIATE (Результат="Отказано…") должно возвращаться диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ".

5.1.3.2. Если установление ассоциации завершается успешно получением примитива подтверждения A-ASSOCIATE (Результат="Доступно"), но проверка полученных параметров завершается со сбоем, должен быть введен примитив A-ABORT, и код возврата должен быть таким, как указано ниже, принимая следующие значения в порядке приоритета:

а) если имя контекста прикладного уровня является неправильным, тогда возвратить диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ";

б) если результат определения контекста уровня представления является неправильным, тогда возвратить диагностическое сообщение службы ПОЗ (JTM) "оу - Контекст не доступен", и функцией MF2 будет предоставлен читаемый текст;

в) (во всех других случаях) возвратить диагностическое сообщение "Не повторять" с кодом диагностического сообщения службы ПОЗ (JTM) "оу - Ошибка передачи" и читаемый текст, предоставляемый функцией MF1.

5.1.3.3. Если ожидание примитива подтверждения A-ASSOCIATE завершается со сбоем с помощью или примитива индикации A-ABORT, или примитива индикации А-P-ABORT, должно быть возвращено диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ".

5.1.3.4. Если имеет место событие "ВРЕМЯ"" (см. табл.1), кодом возврата должно быть диагностическое сообщение "ПОВТОРИТЬ ПОЗЖЕ".

5.2. Параметры в сервисных примитивах управления ассоциацией

5.2.1. Параметры в сервисных примитивах A-ASSOCIATE

5.2.1.1. В табл.6 перечислены:

а) значения параметров в примитиве A-ASSOCIATE, которые должны устанавливаться инициатором службы ПОЗ (JTM);

б) проверки, которые должны выполняться для параметров в примитиве индикации A-ASSOCIATE ответственным логическим объектом службы ПОЗ (JTM);

в) значение "Результат" сервисного элемента управления ассоциацией, которое должно быть возвращено, если проверка завершилась со сбоем.

5.2.1.2. Все проверки должны выполняться. Если имеют место несколько причин для отвержения, то приоритетным сообщением для включения в примитив ответа должно быть:

а) отвергнуто ответственным логическим объектом (Контекст прикладного уровня не обеспечивается) (высший приоритет);

б) отвергнуто ответственным логическим объектом. (Символическое имя элемента прикладного уровня не распознается);

в) отвергнуто ответственным логическим объектом (постоянная ошибка);

г) отвергнуто ответственным логическим объектом (кратковременная ошибка) (низший приоритет).

Примечание. Реализующая система службы ПОЗ (JTM) не должна использовать ответ с сообщением "Отвергнуто ответственным логическим объектом (причина не указана)".

Таблица 6

Значения параметров в примитиве запроса (индикации) A-ASSOCIATE

5.2.1.3. B табл.7 перечислены:

а) значения параметров в примитиве A-ASSOCIATE, которые должны устанавливаться ответственным логическим объектом службы ПОЗ (JTM);

б) проверки, которые должны выполняться инициатором службы ПОЗ (JTM) в примитиве подтверждения A-ASSOCIATE (с результатом="Доступно").

Примечание. В п.5.1.3.2 определяется введение примитива запроса A-ABORT, если эти проверки завершаются cо сбоем.

Таблица 7

Значения параметров в примитиве ответа (подтверждения) A-ASSOCIATE

5.2.2. Параметры в сервисных примитивах A-RELEASE

В табл.8 перечислены значения параметров, применяемых в примитиве запроса A-RELEASE, которые должны устанавливаться инициатором службы ПОЗ (JTM).

Ответственный логический объект службы ПОЗ (JTM) должен допускать все значения.

Таблица 8

Параметры примитива запроса/индикации A-RELEASE

В табл.9 перечислены значения параметров, применяемых в примитиве ответа A-RELEASE, которые должны устанавливаться ответственным логическим объектом службы ПОЗ (JTM). Инициатор службы ПОЗ (JTM) должен допускать все значения.

Таблица 9

Параметры примитива ответа/подтверждения A-RELEASE

5.3. Параметры сервисных примитивов типа "Р-"

Сервисным примитивом типа "P-", непосредственно вводимым службой ПОЗ (JTM), является примитив P-DATA со значениями данных в контексте уровня представления службы ПОЗ (JTM) или в контексте (контекстах) уровня представления, указанных с помощью определения типа документа.

Примечание. Другие сервисные примитивы типа "P-" вводятся косвенно через использование сервисных примитивов элемента СПиВ (CCR) или во время установления соответствующей ассоциации прикладного уровня.

5.3.1. Параметр примитива P-DATА

Параметр "Данные пользователя" примитива запроса P-DATA должен содержать, по крайней мере, одно значение данных уровня представления. Первое значение должно представлять "Элемент передачи", а остальные (если они представлены) должны быть значениями полного документа, формирующего часть спецификации работы, которая должна передаваться, как это указывается в определении типа документа.

Примечание. В базисном классе службы ПОЗ (JTM) может быть передан один документ, поэтому введение ограничения на документы не применяется. Более того, все значения данных, требуемые для передачи документа, содержатся в одном примитиве P-DATA.

5.3.2. Прерывание примитива P-DATA

Введение примитива запроса P-DATA, за которым следует примитив запроса C-ROLLBACK или C-RESTART, может (архитектурно) вызвать потерю соответствующего примитива индикации P-DATA. В терминах реализующей системы передачи данных, относящихся к примитиву запроса и индикации P-DATA, может занять очень много времени; во время такой передачи в любой момент времени поток данных может быть прерван с помощью введения примитива запроса C-ROLLBACK или C-RESTART (или примитива A-P-ABORT). Такое прерывание архитектурно выглядит как потеря примитива индикации P-DATA.

5.4. Параметры сервисных примитивов типа "C-"

5.4.1. Примитивы запроса и индикации C-BEGIN и J-BEGIN

5.4.1.1. Имя главного управляющего логического объекта

B качестве имени главного управляющего логического объекта должно приниматься значение параметра "Имя службы ПОЗ (JTM)", распределенное логическому объекту прикладного уровня, который содержит сервисный элемент прикладного уровня службы ПОЗ (JTM), если этот сервисный элемент прикладного уровня службы ПОЗ (JTM) или одно из его агентств является главным управляющим логическим объектом совершения операций; в другом случае это имя должно иметь значение, предоставляемое управляющим логическим объектом, как это указано в стандарте ИСО 9804 (услуга элемента СПиВ (CCR)).

5.4.1.2. Суффикс элементарного действия

Суффикс должен явно идентифицировать элементарное действие внутри всех элементарных действий, для которых используется одно и то же значение имени главного управляющего логического объекта, если этот сервисный элемент прикладного уровня службы ПОЗ (JTM) или одно из его агентств является главным управляющим логическим объектом совершения операций; в другом случае это имя должно иметь значение, предоставляемое управляющим логическим объектом, как это указано в стандарте ИСО 9804 (услуга элемента СПиВ (CCR)).

5.4.1.3. Имя управляющего логического объекта

В качестве имени управляющего логического объекта должно приниматься значение локального параметра "Имя службы ПОЗ (JTM)", используемое при установлении ассоциации прикладного уровня (функция MF2).

5.4.1.4. Суффикс ответвления

Суффикс ответвления должен явно идентифицировать это ответвление элементарного действия внутри всех ответвлений с одним и тем же значением имени главного управляющего логического объекта, суффикса элементарного действия и имени управляющего логического объекта.

5.4.1.5. Таймер элементарного действия

Все значения таймера элементарного действия должны обеспечиваться для примитива J-INITIATE. Во всех других случаях значение (или пропуск значения) определяется локальной функцией МF24 системы административного управления.

5.4.1.6. Данные пользователя - уровень совершения операций

Уровень совершения операций должен быть установлен в 1 (ПРИНЯТИЕ ПОСТАВЩИКОМ) для всех элементарных действий, для которых сервисный элемент прикладного уровня службы ПОЗ (JTM), или какое-либо из агентств этого элементарного действия, является главным управляющим логическим объектом, кроме такого элементарного действия примитива J-INITIATE, которое может указывать значение 1 (ПРИНЯТИЕ ПОСТАВЩИКОМ) или значение 2 (ПРИНЯТИЕ АГЕНТСТВОМ).

Если сервисный элемент прикладного уровня службы ПОЗ (JTM) является управляемым логическим объектом, то уровень совершения операции должен устанавливаться в такое значение, которое указывается управляющим логическим объектом.

Если в примитиве индикации C-BEGIN, полученном через соединение из другого сервисного элемента прикладного уровня службы ПОЗ (JTM), запрашивается уровень совершения операций, больший 2, то этот запрос должен отвергаться, как это указывается в п.3.3.8.1б).

5.4.1.7. Данные пользователя - индикатор кода диагностического сообщения

Этот параметр должен устанавливаться в такое значение, как это указано в описании данного стандарта.

5.4.2. Примитивы запроса и индикации C-READY и J-READY

5.4.2.1. Данные пользователя - уровень совершения операций

Уровень совершения операций 3 (ЗАВЕРШЕНИЕ) должен задаваться, если активность завершается и все ресурсы освобождаются.

Уровень совершения операций 2 (ПРИНЯТИЕ АГЕНТСТВОМ) должен задаваться, если агентство сохранило материал, сигнализируя позже о завершении с помощью примитива J-END-SIGNAL.

Уровень совершения операций 1 (ПРИНЯТИЕ ПОСТАВЩИКОМ) должен задаваться, если спецификация работы не была обработана с уровнем "ПРИНЯТИЕ АГЕНТСТВОМ".

Значение уровня совершения операций в примитиве запроса C-READY должно равняться или превышать то значение, которое задавалось в примитиве индикации C-BEGIN.

5.4.2.2. Данные пользователя - предупреждающие диагностические сообщения

Значение параметра "Предупреждающие диагностические сообщения" должно приниматься таким, как это указано в описании данного стандарта.

5.4.2.3. Данные пользователя - учетная информация

Учетная информация должна отсутствовать в примитивах запроса и должна игнорироваться при получении примитива индикации.

5.4.3. Примитивы запроса и индикации C-REFUSE и J-REFUSE

5.4.3.1. Данные пользователя - диагностическое сообщение

Параметры "Код" и "Причина" должны устанавливаться, как это указывается в описании данного стандарта. Параметр "формирователь" должен устанавливаться в одно из значений параметра "Имя службы ПОЗ (JTM)", назначенное логическому объекту прикладного уровня, который содержит сервисный элемент прикладного уровня службы ПОЗ (JTM). Если сервисный элемент прикладного уровня службы ПОЗ (JTM) представляет собой логический объект, подчиненный главному управляющему логическому объекту, то диагностические сообщения, обеспечиваемые управляемым логическим объектом, должны передаваться управляющему логическому объекту без изменения.

5.4.3.2. Данные пользователя - учетная информация

Учетная информация должна отсутствовать в примитивах запроса и должна игнорироваться при получении примитива индикации.

5.4.4. Примитивы C-RESTART и J-RESTART

Эти примитивы должны использоваться, как это указано в стандарте ИСО 9804 (услуга элемента СПиВ (CCR)), дополнительные требования не указываются в данном стандарте.

Значение параметра │Таймер повторения" должно устанавливаться локальной функцией MF25 системы административного управления.

Данные пользователя для значения "Отказать" ВЫБОРОЧНЫЙ ТИП должны повторять ту информацию, которая содержалась в данных пользователя более раннего примитива C-REFUSE.

ПРИЛОЖЕНИЕ А (обязательное). ФУНКЦИИ СИСТЕМЫ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ

ПРИЛОЖЕНИЕ А
Обязательное

В этом приложении определяются значения, возвращаемые локальными функциями системы административного управления, на которые имеются ссылки из процедур, описанных в разд.3 данного стандарта.

Требования относительно этих функций указываются в разд.4.

Чтобы обеспечить значения этих функций, запрашивается реализующая система с помощью процедур, описанных в разд.3 данного стандарта. Эти значения могут быть выбраны реализующей системой и "вложены" в эту реализующую систему. Альтернативно, реализующая система может выбрать способ, с помощью которого обеспечивается ряд возможных значений и механизм изменения этих значений. В разд.4 описаны требования к документации, поставляемой с реализующей системой, чтобы можно было определить свой выбор, и требования, по которым определенные указанные функции должны иметь перестраиваемую конфигурацию (см. п.4.3).

Функция MF1. Читаемый текст.

Эта функция должна возвращать читаемый текст (на каком-либо языке), который сопровождает код диагностического сообщения службы ПОЗ (JTM). Функция может предоставлять более подробную информацию, чем содержит в себе код диагностического сообщения службы ПОЗ (JTM), или может предоставлять одну часть текста для каждого сообщения. Коды диагностического сообщения службы ПОЗ (JTM) перечислены в разд.1 с их абстрактным синтаксисом. В некоторых случаях спецификация, описанная в разд.3, требует, чтобы реализующая система включала текст из спецификации работы в читаемое диагностическое сообщение. Это читаемое диагностическое сообщение содержит минимальный требуемый текст.

Требуется, чтобы реализующая система (см. п.4.1.12) обеспечивала диагностические сообщения, представленные в ГОСТ 27463. Кроме того, она может обеспечивать диагностические сообщения других наборов символов, используя индикатор кода диагностического элемента СПиВ (CCR), чтобы выбрать текст диагностического сообщения.

Функция MF2. Локальное имя.

Эта функция должна возвращать значение параметра "Имя службы ПОЗ (JTM)", назначенное с помощью санкции поименования этому логическому объекту прикладного уровня (как это определено в п.2.2 разд.2).

Функция MF3. Первичный монитор.

Эта функция должна возвращать спецификацию, указываемую параметром "Спецификация монитора" базисного класса (как это определено в разд.2), которая является пригодной, чтобы принимать уведомления для заданий модели ВОС, предъявляемых сервисному элементу прикладного уровня службы ПОЗ (JTM). Значение этой спецификации может зависеть от источника примитива J-INITIATE (см. также описание функции MF6).

Примечание. Например, эта функция может быть установлена для пользователей электронной почты.


Функция MF4. Аутентифицированная идентификация.

Эта функция должна возвращать аутентифицированное значение параметра "Идентификация", представляющее инициирующее агентство, или должна возвращать значение "Не доступно".

Примечание. Это значение может иметь параметр "Идентификация пользователя" или это значение может указывать, что агентство функционирует от имени открытой системы или может указывать санкцию, т.е. указывать, что примитив J-INITIATE введен оператором.


Функция MF5. Аутентификация.

Эта функция используется для аутентификации параметра "Идентификация" со значением "Доступ" параметра "Пароль". Она должна возвращать значение "Аутентифицированный" или "Неаутентифицированный".

Функция MF6. Дополнительная санкция.

Эта функция должна возвращать значение 0, 1 и более для дальнейшего санкционирования, которое необходимо, чтобы гарантировать, что уведомления будут доставлены первичному монитору.

Функция MF7. Отражаемое санкционирование.

Эта функция может не возвращать или может возвращать одно или несколько дополнительно аутентифицированных значений параметра "Идентификация", если известно, что они связаны с тем же оператором или санкцией, как существующая допустимая аутентификация.

Функция MF8. Опознавание адреса вызывающего пользователя.

Эта функция использует адресную информацию вызывающего пользователя, предоставляемую протоколами нижнего уровня, и какие-либо процедуры аутентификации, доступные на нижнем уровне, чтобы определить достоверность значения параметра "Имя службы ПОЗ (JTM)" вызывающего пользователя. Функция должна возвращать значение "НЕИЗВЕСТНЫЙ", "ИЗВЕСТНЫЙ" или "АУТЕНТИФИЦИРОВАННЫЙ", как это указано в п.3.3.1. Она всегда может возвратить значение "НЕИЗВЕСТНЫЙ".

Функция MF9. Список обработки вызова.

Эта функция определяет, допускать ли и обрабатывать ли передачи службы ПОЗ (JTM) из логического объекта, указанного параметром "Имя службы ПОЗ (JTM) со значением "НЕИЗВЕСТНЫЙ", "ИЗВЕСТНЫЙ" или "АУТЕНТИФИЦИРОВАННЫЙ". Минимальное обеспечение должно допускать все вызовы. Функция должна возвращать значение "Функционирует" или "Не функционирует".

Функция MF10. Время ожидания.

Эта функция должна возвращать: значение времени ожидания в продолжение передачи (когда передача не выполняется), значение времени ожидания для завершения установления ассоциации и значение времени ожидания для завершения освобождения ассоциации. Это время может быть неограниченным и может управляться оператором.

Функция MF11. Необходимое санкционирование.

Эта функция определяет, для уведомляющей системы для особых получаемых элементов передачи требуется ли распознаваемый элемент санкционирования или разрешать любую дальнейшую обработку. В общих случаях всегда должно требоваться санкционирование, либо санкционирование должно требоваться только для удаленной уведомляющей системы (и доступ к некоторым принимающим агентствам). Функция должна возвращать значение "Санкционирование требуется для всех активностей", "Санкционирование требуется для уведомляющей системы" или "Санкционирование не требуется".

Примечание. Соответствующие значения функций MF11, МF15 и MF16 можно указать так, что эта функция будет необязательной для реализующей системы, чтобы обрабатывать элементы санкционирования службы ПОЗ (JTM). Использование таких значений реализующая система выбирает сама.


Функция MF12. Распознаваемые санкции идентификации пользователя.

Эта функция должна возвращать имена санкций идентификации пользователя, которые распознаются в этой открытой системе, т.е. эта функция способна предоставлять данные санкционирования для активности.

Функция MF13. Доверенная реализующая система.

Эта функция должна возвращать список имен, указываемых параметром "Имя службы ПОЗ (JTM)" ("Известный", "Неизвестный" или "Аутентифицированный"), которым нужно доверять, чтобы правильно установить значение параметра "Доступ" в элементе санкционирования.

Примечания:

1. Если возможна помеха связи, то аутентификация отправителя должна быть комбинированной с кодом обнаружения вмешательства или с кодированием, если этот механизм должен быть защищен.

2. В случае значения "Неизвестный" функция служит только для блокирования реализующей системы, которая не имеет "маскарад" в значении, которое она помещает в проверочную трассу (функция MF2).

3. Рекомендуется, чтобы механизмы конфигурации включали также такие предложения, как "ВСЕ" и "ВСЕ, ИСКЛЮЧАЯ…".


Функция MF14. Время задержки.

Эта функция должна возвращать значение времени, за которое реализующая система должна попытаться обработать спецификацию работы с уровнем совершения операции "ЗАВЕРШЕНИЕ", перед тем как отказаться от попытки и принять самый низкий уровень совершения операций. Обычно решение будет основываться на ответах от управляемых логических объектов элемента СПиВ (CCR) и на значениях таймера, возвращаемых в этих ответах и предоставляемых управляющим логическим объектом.

Функция MF15. Имена агентств.

Эта функция должна возвращать список имен агентств, их типов и какую-либо информацию, необходимую для доступа к этим агентствам, которая известна этой реализующей системе. Настоятельно рекомендуется, чтобы несмотря на то, что актуальные агентства, обеспечиваемые реализующей системой, могут быть фиксированными, значения имен, которые должны быть заданы этим агентствам, должны иметь перестраиваемую конфигурацию. Эта функция также должна возвращать признак, сообщающий, требуется ли санкционирование для доступа к этому агентству и, если требуется, какую санкцию, указанную параметром "Санкция идентификации пользователя", это агентство распознает.

Примечания:

1. В то время, пока доступ к файлам является управляемым, доступ к печатающим устройствам может быть неуправляемым. Для специальных устройств или, если это устройство является удаленным, этому устройству может быть установлено уникальное значение параметра "Санкция идентификации пользователя". В более общем виде для полной открытой системы должна быть одна санкция.

2. Соответствующие значения функций MF11, MF15 и MF16 можно указать так, что эта функция будет необязательной для реализующей системы, чтобы обрабатывать элементы санкционирования службы ПОЗ (JTM). Использование таких значений реализующая система выбирает сама.

Функция MF16. Санкционирование для посылки и просмотра справочника.

Эта функция должна возвращать признак, сообщающий, требует или нет определенная спецификация работы санкционирование для передачи выходных данных. Это может зависеть от целевой системы или от типа подзадания, или от того и другого вместе. Функция системы административного управления также должна возвращать значения параметра "Санкция идентификации пользователя", которые распознаются для данной активности (см. примечание к описанию функции MF15), и какую-либо адресную информацию, необходимую для установления ассоциации прикладного уровня в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС". Если данная функция применяется, то она также может определить такие возможности, как типы протоколов транспортного уровня, которые предлагаются или допускаются, и синтаксисы передачи, которые предлагаются или допускаются.

Примечание. Соответствующие значения функций MF11, MF15 и MF16 можно указать так, что эта функция будет необязательной для реализующей системы, чтобы обрабатывать элементы санкционирования службы ПОЗ (JTM). Использование таких значений реализующая система выбирает сама.


Функция MF17. Видимость.

Эта функция определяет, должны ли спецификации работы быть или не должны быть "видимыми" для отображения их состояния пользователям, которым не принадлежат эти спецификации работы. Требуется, чтобы эта функция имела перестраиваемую конфигурацию. Она должна возвращать значение "Отображаемая" или "Неотображаемая".

Функция MF18. Размещение несобранных документов.

Эта функция либо указывает, что документы в исполняющем агентстве, которые не собраны в примитиве J-END-SIGNAL, должны быть удалены, либо еще определяет способ, с помощью которого эти документы должны быть размещены локально. Этот способ может включать в себя сохранение, локальный вывод на печать или копирование в некоторое постоянное файлохранилище. Функция может иметь различные значения для каждого обеспечиваемого агентства.

Функция MF19. Параллельность выполнения передач входной информации службы ПОЗ (JTM).

Эта функция определяет, может ли передача входной информации службы ПОЗ (JTM) выполняться в данный момент времени. Она должна возвращать значение "Выполнение" или "Повторить позже", а также может возвратить значение параметра "Время повторения" для примитива ответа C-REFUSE. Эта функция может использоваться для ограничения общего числа передач службы ПОЗ (JTM) или общего числа передач входной информации от одного сервисного элемента прикладного уровня службы ПОЗ (JTM) или от группы сервисных элементов прикладного уровня службы ПОЗ (JTM). Эта функция также может динамически изменяться для обеспечения локального управления оператора.

Примечание. Настоятельно рекомендуется, чтобы параллельность выполнения, допустимая на нижних уровнях для передач службы ПОЗ (JTM), превышала значение параллельности в данной функции так, чтобы ответы с диагностическим сообщением "ПОВТОРИТЬ ПОЗЖЕ" можно было формировать на уровне элемента СПиВ (CCR).


Функция MF20. Параллельность при доступе к агентству.

Эта функция определяет максимальную параллельность для групп совершения операций, вводимых в агентства службы ПОЗ (JTM). Она должна возвращать значение "Выполнение" или "Ожидание".

Функция MF21. Передача выходной информации службы ПОЗ (JTM) при получении ассоциации.

Эта функция определяет, может ли выполняться передача выходной информации к соответствующему сервисному элементу прикладного уровня службы ПОЗ (JTM) в данный момент времени. Онa должна возвращать значение "Выполнение" или "Ожидание", или "Ошибка". Если функция возвращает значение "Выполнение", тогда она должна допустить ассоциацию прикладного уровня в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС". Процедуры для установления новой ассоциации прикладного уровня указываются в разд.5. Также применяются комментарии в описании функции MF19. Эта функция реализует локальные решения планирования при использовании ассоциаций прикладного уровня. Если эта функция определяет, что выполнение в данное время возможно, то локальные процедуры получают ассоциацию прикладного уровня в контексте типа "Контекст прикладного уровня базисного класса службы ПОЗ (JTM) модели ВОС" при завершении согласования контекста уровня представления, контексты, определенные для службы ПОЗ (JTM), для элемента СПиВ (CCR) и для документов любых типов в спецификации работы.

Примечание. Это может быть достигнуто с помощью повторного использования существующих взаимосвязей или с помощью новой связи, относящейся к локальному решению планирования. Инициативу при установлении контекстов берет на себя передающий пользователь. Предполагаемый принимающий пользователь играет пассивную, но взаимосвязанную роль, как это указано в разд.5.


Функция MF22. Локальная адресная информация (входная).

Эта функция должна возвращать адресную информацию, которая должна использоваться удаленными системами и которая вводится ими в вызываемые адресные поля для вызовов к этому сервисному элементу прикладного уровня службы ПОЗ (JTM) (см. пп.4.1.4 и 4.1.6).

Функция MF23. Локальная адресная информация (выходная).

Эта функция должна возвращать адресную информацию, которая должна использоваться логическими объектами более низкого уровня для введения значений в вызывающие адресные поля для вызовов из этого сервисного элемента прикладного уровня службы ПОЗ (JTM) (см. пп.4.1.5 и 4.1.6). Значения, возвращаемые этой функцией, могут, но не обязательно, быть такими же, как значения, возвращаемые функцией MF22. Эта функция также используется для определения адреса отвечающего логического объекта или адреса повторного вызова.

Функция MF24. Таймер элементарного действия.

Эта функция должна возвращать значение таймера элементарного действия для активностей службы ПОЗ (JTM). Значение "Не обеспечивается" означает минимальное функционирование. Эта функция может использовать значение, предоставляемое управляющим логическим объектом (если он имеется).

Функция MF25. Таймер рестарта.

Эта функция должна возвращать значение таймера рестарта для активностей службы ПОЗ (JTM). Значение "Не обеспечивается" означает минимальное функционирование.

Функция MF26. Допустимость входных ассоциаций.

С помощью символического имени логического объекта прикладного уровня вызывающего пользователя, адреса логического объекта уровня представления вызывающего пользователя и соглашений локальной перегруженности эта функция определяет, обрабатывать ли примитив индикации A-ASSOCIATE или отвернуть его немедленно. Она также определяет, имеется ли отказ с кодом, указывающим значение "Постоянная ошибка" или "Кратковременная ошибка".

ПРИЛОЖЕНИЕ Б (обязательное). ТИПЫ ДОКУМЕНТОВ

ПРИЛОЖЕНИЕ Б
Обязательное

Б.1. ТИП ПРОСТОГО ТЕКСТОВОГО ДОКУМЕНТА

1. Номер элемента

ПОЗ (JTM)-1.

2. Идентификатор

{ГОСТ Р 34.1984 Документ (4) Текстовый (1)}.

3. Значение описателя

"Простой текстовый документ службы ПОЗ (JTM) модели ВОС".

4. Синтаксис параметров

Параметры не должны использоваться.

5. Область и поле применения

Этот тип документа определяется при использовании передач службы ПДУФ (FTAM). Он может формировать часть блока данных доступа к файлу службы ПДУФ (FTAM), но не применяется в качестве имени содержания сообщения файла.

6. Ссылка

ГОСТ Р 34.1980.3 "Информационная технология. Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла".

7. Определения

7.1. Строка знаков (Character string): Упорядоченные серии, которые либо не имеют, либо имеют один или несколько знаков из некоторого указанного репертуара знаков.

7.2. Графический знак (Graphics character): Знак из некоторого множества символов, зарегистрированного для использования как множество G0, G1, G2 или G3 в международном реестре модели ИСО набора знаков или области знаков.

8. Сокращения

ПДУФ - передача, доступ и управление файлом.

(FTAM - file transfer, access and management).

9. Семантика документа

Документ состоит из неограниченной последовательности, которая либо не имеет, либо имеет одну или несколько строк знаков. Каждая строка знаков не ограничена по длине и либо не содержит, либо содержит один или несколько графических знаков.

10. Структура абстрактного синтаксиса

Документ такого типа состоит из неопределенного числа типов данных нотаций АСН.1, каждый типа

"Графическая строка".

Каждая строка типа "Графическая строка" должна содержать точно одну из строк знаков в документе по порядку.

11. Определение передачи

11.1. Определение типа данных

Тип данных ::= Графическая строка

11.2. Имена абстрактного синтаксиса

Имя абстрактного синтаксиса::=

ГОСТ Р 34.1984.

Абстрактный синтаксис документа (5) Текстовый (1)}.

Значением параметра "Описатель объекта" должно быть "Абстрактный синтаксис простого текстового документа службы ПОЗ (JTM) модели ВОС".

11.3. 3начения данных уровня представления

Каждое значение данных уровня представления должно состоять из одного или нескольких экземпляров "Тип данных", взятых по порядку. Они должны передаваться в контексте уровня представления, установленном для синтаксиса, указанного значением параметра "Имя абстрактного синтаксиса". Если контрольная точка не используется, то полный документ должен передаваться как единственное значение данных уровня представления.

11.4. Последовательность значений данных уровня представления

Значения данных уровня представления должны передаваться в том порядке, в котором они формировались, как это указано выше в п.11.3.

12. Синтаксис передачи

12.1. Имена синтаксиса передачи

Имя синтаксиса передачи::=

ГОСТ Р 34.1984.

Синтаксис передачи документа (6) Текстовый (1)}.

Значением параметра "Описатель объекта" должен быть

"Базисный синтаксис передачи простого текстового документа службы ПОЗ (JTM)".

12.2. Требования синтаксиса передачи

12.2.1. Имя, указанное параметром "Имя синтаксиса передачи", должно использоваться для такого синтаксиса передачи, который был получен с помощью применения базисных правил кодирования нотации АСН.1 ГОСТ 34.974 к каждому значению, указанному параметром "Значение данных", в значении данных уровня представления, и с помощью сцепления полученных в результате октетов.

12.2.2. Должен обеспечиваться синтаксис передачи, указанный параметром "Имя синтаксиса передачи". Другие синтаксисы передачи могут быть дополнительно обеспечены, но любое дополнительное обеспечение должно быть предложено в предложении согласования реализации протокола.

13. Сервисный элемент прикладного уровня - описательная спецификация

13.1. ГОСТ Р 34.1984.

13.1.1. Служба ПОЗ (JTM) - сцепление

Сцепление документов такого типа возможно с документами подобного типа, и в результате формируется документ такого же типа, состоящий из объединенной последовательности знаковых строк.

Примечание. Границы между исходными последовательностями являются невидимыми.

13.1.2 Служба ПОЗ (JTM) - описательное согласование

Соответствующая реализующая система должна обеспечивать все значения этого типа документа, подчиненные возможным пределам реализации, основанной на общем количестве знаков в документе. Предел реализации должен разрешать использование документов, содержащих до 64000 знаков. Этот предел должен быть описан в предложении согласования реализации протокола.

Б.2. ТИП ПРОСТОГО ДОКУМЕНТА ДЛЯ ПЕЧАТИ

1. Номер элемента

ПОЗ (JTM)-2

2. Идентификатор

{ГОСТ Р 34.1984 Документ (4), Для печати (2)}.

3. Значение описателя

"Простой документ для печати службы ПОЗ (JTM) модели ВОС".

4. Синтаксис параметров

Параметры не должны использоваться.

5. Область и поле применения

Этот тип документа определяется при использовании передач службы ПДУФ (FTAM). Он может формировать часть блока данных доступа к файлу службы ПДУФ (FTAM), но не применяется в качестве имени содержания сообщения файла.

6. Ссылка

ГОСТ Р 34.1980.3 "Информационная технология. Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла".

7. Определения

7.1. Строка знаков (Character string): Упорядоченные серии, которые либо не имеют, либо имеют один или несколько знаков из некоторого указанного репертуара знаков.

7.2. Графический знак (Graphics character): Знак из некоторого репертуара знаков, зарегистрированного для использования как множество G0, G1, G2 или G3 в международном реестре модели ИСО набора знаков или области знаков.

8. Сокращения

ПДУФ - Передача, доступ и управление файлом.

9. Семантика документа

Документ состоит из неограниченной последовательности, которая либо не имеет, либо имеет одну или несколько строк знаков. Каждая строка знаков не ограничена по длине и содержит любые графические знаки. Каждая строка знаков предназначается для отображения в отображаемой среде. Она связана с индикатором управления отображением, который управляет позиционированием текста в этой среде. Это средство может, но не обязательно, включать опознавательные границы, которые могут размещаться для указания позиции строки текста.

Эти строки отображаются в том порядке, в котором они появляются в последовательности, перемещаясь сверху вниз этой среды и слева направо в этой строке. Не стандартизуется обработка таких строк, которые для этого средства являются слишком длинными или которые содержат неотображаемые знаки.

Каждый индикатор управления отображением используется для управления вертикальной позицией строки текста, содержащей индикатор управления отображением, после предшествующей строки следующим образом:

Первый индикатор управления отображением в последовательности обрабатывается, принимая во внимание, что предшествующая строка в позиции находилась выше опознавательной границы среды, а затем применяются вышеописанные правила.

10.Структура абстрактного синтаксиса

Документ такого типа состоит из неопределенного числа типов данных нотаций АСН.1, каждый типа

"Строка",

Каждое значение параметра "Строка" должно содержать точно одну из строк знаков в документе вместе со своим соответствующим индикатором отображения по порядку.

11. Определение передачи

11.1. Определение типа данных

Тип данных ::= Строка

11.2. Имена абстрактного синтаксиса

Имя абстрактного синтаксиса ::=

ГОСТ Р 34.1984.

Абстрактный синтаксис документа (5). Для печати (2)}.

Значением параметра "Описатель объекта" должен быть

"Абстрактный синтаксис простого документа для печати службы ПОЗ (JTM) модели ВОС".

11.3. Значения данных уровня представления

Каждое значение данных уровня представления должно состоять из одного или нескольких экземпляров "Тип данных", взятых по порядку. Они должны передаваться в контексте уровня представления, установленном для синтаксиса, указанного значением параметра "Имя абстрактного синтаксиса". Если контрольная точка не используется, то полный документ должен передаваться как единственное значение данных уровня представления.

11.4. Последовательность значений данных уровня представления

Значения данных уровня представления должны передаваться в том порядке, в котором они формировались, как это указано в п.11.3.

12. Синтаксис передачи

12.1. Имена синтаксиса передачи

Имя синтаксиса передачи ::=

{ГОСТ Р 34.1984.

Синтаксис передачи документа (6). Для печати (2)}.

Значением параметра "Описатель объекта" должен быть

"Базисный синтаксис передачи простого документа для печати службы ПОЗ (JTM)".

12.2. Требования синтаксиса передачи

12.2.1. Имя, указанное параметром "Имя синтаксиса передачи", должно использоваться для такого синтаксиса передачи, который был получен с помощью применения базисных правил кодирования нотации АСН.1 ГОСТ 34.974 к каждому значению, указанному параметром "Значение данных", в значении данных уровня представления, и с помощью сцепления полученных в результате октетов.

12.2.2. Должен обеспечиваться синтаксис передачи, указанный параметром "Имя синтаксиса передачи". Другие синтаксисы передачи могут быть дополнительно обеспечены, но любое дополнительное обеспечение должно быть предложено в предложении согласования реализации протокола.

13. Сервисный элемент прикладного уровня - описательная спецификация

13.1. ГОСТ P 34.1984.

13.1.1. Служба ПОЗ (JTM) - сцепление

Документ такого типа может сцепляться с документами подобного типа для формирования другого документа такого же типа. Новый документ должен состоять из последовательности "Строк" в следующем виде:

а) последовательность "Строк" из первого документа;

б) одна или несколько "Строк", сформированных из первой "Строки" второго документа, как это указано ниже; затем

в) остальные "Строки" из второго документа.

"Строки" в перечислении б) будут зависеть от значения индикатора "Управление отображением" в первой строке второго документа согласно следующему списку:

13.1.2. Служба ПОЗ (JTM) - описательное согласование

Соответствующая реализующая система должна обеспечивать все значения этого типа документа, подчиненные возможным пределам реализации, основанной на общем количестве знаков в документе. Предел реализации должен разрешать использование документов, содержащих до 64000 знаков. Этот предел должен быть описан в предложении согласования реализации протокола.

Б.3. ТИП ПРОСТОГО ДВОИЧНОГО ДОКУМЕНТА

1. Номер элемента

ПОЗ (JTM)-3.

2. Идентификатор

{ГОСТ Р 34.1984 Документ (4) Двоичный (3)}.

3. Значение описателя

"Простой двоичный документ службы ПОЗ (JTM) модели ВОС".

4. Синтаксис параметров

Параметры не должны использоваться.

5. Область и поле применения

Этот тип документа определяется при использовании передач службы ПДУФ (FTAM). Он может формировать часть блока данных доступа к файлу службы ПДУФ (FTAM), но не применяется в качестве имени содержания сообщения файла.

6. Ссылка

ГОСТ Р 34.1980.3 "Информационная технология. Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла".

7. Определения

Дополнительные определения не используются для другого типа документа.

8. Сокращения

ПДУФ - Передача, доступ и управление файлом.

9. Семантика документа

Документ состоит из одной-единственной неограниченной строки, либо не содержащей, либо содержащей один или несколько битов.

10. Структура абстрактного синтаксиса

Документ такого типа состоит из неопределенного числа типов данных новаций АСН.1, каждый типа

СТРОКА БИТОВ

Строка битов в документе должна разделяться на типы данных "СТРОКА БИТОВ" по способу, который определяется передающим пользователем, но порядок, в котором они появляются в документе, должен быть сохранен. Если контрольные точки не используются, то целый документ должен выполняться как единственный тип данных "СТРОКА БИТОВ".

11. Определение передачи

11.1. Определение типа данных

Тип данных ::= СТРОКА БИТОВ

11.2. Имена абстрактного синтаксиса

Имя абстрактного синтаксиса ::=

{ГОСТ Р 34.1984.

Абстрактный синтаксис документа (5). Двоичный (3)}.

Значением параметра "Описатель объекта" должен быть

"Абстрактный синтаксис простого двоичного документа службы ПОЗ (JTM) модели ВОС".

11.3. Значения данных уровня представления

Каждое значение данных уровня представления должно состоять из одного или нескольких экземпляров "Тип данных", взятых по порядку. Они должны передаваться в контексте уровня представления, установленном для синтаксиса, указанного значением параметра "Имя абстрактного синтаксиса". Если контрольная точка не используется, то полный документ должен передаваться как единственное значение данных уровня представления.

11.4. Последовательность значений данных уровня представления

Значения данных уровня представления должны передаваться в том порядке, в котором они формировались, как это указано в п.11.3.

12. Синтаксис передачи

12.1. Имена синтаксиса передачи

Имя синтаксиса передачи::=

{ГОСТ P 34.1984.

Синтаксис передачи документа (6). Двоичный (3)}.

Значения параметра "Описатель объекта" должен быть

"Базисный синтаксис передачи простого двоичного документа службы ПОЗ (JTM)".

12.2. Требования синтаксиса передачи

12.2.1. Имя, указанное параметром "Имя синтаксиса передачи", должно использоваться для такого синтаксиса передачи, который был получен с помощью применения базисных правил кодирования нотации АСН.1 ГОСТ 34.974 к каждому значению, указанному параметром "Значение данных", в значении данных уровня представления, и с помощью сцепления полученных в результате октетов.

12.2.2. Должен обеспечиваться синтаксис передачи, указанный параметром "Имя синтаксиса передачи". Другие синтаксисы передачи могут быть дополнительно обеспечены, но любое дополнительное обеспечение должно быть предложено в предложении согласования реализации протокола.

13. Сервисный элемент прикладного уровня - описательная спецификация

13.1. ГОСТ Р 34.1984.

13.1.1. Служба ПОЗ (JTM) - сцепление

Сцепление документов такого типа возможно с документами подобного типа, и в результате формируется документ такого же типа, состоящий из объединенной последовательности битов.

Примечание. Границы между исходными последовательностями являются невидимыми.

13.1.2. Служба ПОЗ (JTM) - описательное согласование

Соответствующая реализующая система должна обеспечивать все значения этого типа документа, подчиненные возможным пределам реализации, основанной на общем количестве знаков в документе. Предел реализации должен разрешать использование документов, содержащих до 512000 битов. Этот предел должен быть описан в предложении согласования реализации протокола.

Б.4. ТИП ДОКУМЕНТА ОТОБРАЖЕНИЯ РАБОТЫ

1. Номер элемента

ПОЗ (JTM)-4.

2. Идентификатор

{ГОСТ Р 34.1984 Документ (4) Отображение работы (4)}.

3. Значение описателя

"Документ отображения работы службы ПОЗ (JTM) модели ВОС".

4. Синтаксис параметров

Параметры не должны использоваться.

5. Область и поле применения

Этот тип документа определяется при использовании передач службы ПДУФ (FTAM). Он может формировать часть блока данных доступа к файлу службы ПДУФ (FTAM), но не применяется в качестве имени содержания сообщения файла.

6. Ссылка

ГОСТ Р 34.1980.3 "Информационная технология. Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла".

ИСО 8831 "Системы обработки информации. Взаимосвязь открытых систем. Концепции и услуги по передаче заданий и манипулированию заданиями".

7. Определение

В элементе реестра этого типа документа не используются дополнительные определения.

8.Сокращения

Передача, доступ и управление файлом.

9. Семантика документа

См. п.3.5.3 стандарта ИСО 8831.

10. Структура абстрактного синтаксиса

Документ состоит из единственного экземпляра типа данных нотации АСН.1.

"Документ отображения работы", определенного в п.2.6 данного стандарта.

11. Определение передачи

11.1. Определение типа данных

Тип данных ::= Документ отображения работы.

11.2. Имена абстрактного синтаксиста

Имя абстрактного синтаксиса ::=

{ГОСТ Р 34.1984.

Абстрактный синтаксис (2)}.

Значением параметра "Описатель объекта", должен быть

Абстрактный синтаксис службы ПОЗ (JTM) модели BOC".

11.3. 3начения данных уровня представления

Единственное значение данных уровня представления, используемое для передачи, должно состоять из единственного экземпляра "Тип данных" и должно передаваться в любом контексте уровня представления, установленном для имени, указанного значения параметра "Имя абстрактного синтаксиса".

11.4. Последовательность значений данных уровня представления

Используется только одно значение данных уровня представления.

12. Синтаксис передачи

12.1. Имена синтаксиса передачи

Имя синтаксиса передачи ::=

{ГОСТ P 34.1984.

Синтаксис передачи (3)}.

Значением параметра "Описатель объекта" должно быть

"Синтаксис передачи службы ПОЗ (JTM) модели ВОС".

12.2. Требования синтаксиса передачи

12.2.1. Синтаксис передачи, который должен использоваться с именем, указанным значением параметра "Имя синтаксиса передачи", указывается в п.2.2.5.3 данного стандарта.

12.2.2. Должен обеспечиваться синтаксис передачи, указанный параметром "Имя синтаксиса передачи". Другие синтаксисы передачи могут быть дополнительно обеспечены, но любое дополнительное обеспечение должно быть предложено в предложении согласования реализации протокола.

13. Сервисный элемент прикладного уровня - описательная спецификация

13.1. ГОСТ Р 34.1984.

13.1.1. Служба ПОЗ (JTM) - сцепление

Сцепление документов такого типа возможно с документами подобного типа, и в результате формируется документ такого же типа, состоящий из объединенного списка компонентов <Отображение работы>.

Примечание. Границы между исходными списками компонентов <Отображение работы> являются невидимыми.

13.1.2. Служба ПОЗ (JTM) - описательное согласование

См. п.4.1.13 данного стандарта.

Б.5. ТИП ДОКУМЕНТА ОТОБРАЖЕНИЯ УВЕДОМЛЕНИЯ

1. Номер элемента

ПОЗ (JTM)-5

2. Идентификатор

(ГОСТ Р 34.1984 Документ (4) Отображение уведомления (5)}.

3. Значение описателя

"Документ отображения уведомления службы ПОЗ (JTM) модели ВОС".

4. Синтаксис параметров

Параметры не должны использоваться.

5. Область и поле применения

Этот тип документа определяется при использовании передач службы ПДУФ (FTAM). Он может формировать часть блока данных доступа к файлу службы ПДУФ (FTAM), но не применяется в качестве имени содержания сообщения файла.

6. Ссылка

ГОСТ Р 34.1980.3 "Информационная технология. Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла".

ИСО 8831 "Системы обработки информации. Взаимосвязь открытых систем. Концепции и услуги по передаче заданий и манипулированию заданиями".

7. Определение

В элементе реестра этого типа документа не используются дополнительные определения.

8. Сокращения

ПДУФ - Передача, доступ и управление файлом.

9. Семантика документа

См. п.3.5.1 стандарта ИСО 8831.

10. Структура абстрактного синтаксиса

Документ состоит из единственного экземпляра типа данных нотаций АСН.1.

"Документ отображения уведомления", определенного в п.2.6 данного стандарта.

11. Определение передачи

11.1. Определение типа данных

Тип данных ::= Документ отображения уведомления.

11.2. Имена абстрактного синтаксиса

Имя абстрактного синтаксиса ::=

{ГОСТ Р 34.1984.

Абстрактный синтаксис (2)}.

Значением параметра "Описатель объекта" должен быть

"Абстрактный синтаксис службы ПОЗ (JTM) модели ВОС".

11.3. Значения данных уровня представления

Единственное значение данных уровня представления, используемое для передачи, должно состоять из единственного экземпляра "Тип данных" и должно передаваться в любом контексте уровня представления, установленном для имени, указанного значением параметра "Имя абстрактного синтаксиса".

11.4. Последовательность значений данных уровня представления

Используется только одно значение данных уровня представления.

12. Синтаксис передачи

12.1.1 Имена синтаксиса передачи

Имя синтаксиса передачи ::=

{ГОСТ Р 34.1984.

Синтаксис передачи (3)}.

Значением параметра "Описатель объекта" должен быть

"Синтаксис передачи службы ПОЗ (JTM) модели ВОС".

12.2. Требования синтаксиса передачи

12.2.1. Синтаксис передачи, который должен использоваться с именем, указанным значением параметра "Имя синтаксиса передачи", указывается в п.2.2.5.3 данного стандарта.

12.2.2. Должен обеспечиваться синтаксис передачи, указанный параметром "Имя синтаксиса передачи". Другие синтаксисы передачи могут быть дополнительно обеспечены, но любое дополнительное обеспечение должно быть предложено в предложении согласования реализации протокола.

13. Сервисный элемент прикладного уровня - описательная спецификация

13.1. ГОСТ Р 34.1984.

13.1.1 Служба ПОЗ (JTM) - сцепление

Сцепление документов такого типа возможно с документами подобного типа, и в результате формируется документ такого же типа, состоящий из объединенного списка компонентов <Отображение уведомления>.

Примечание. Границы между исходными списками компонентов <Отображение уведомления> являются невидимыми.

13.1.2. Служба ПОЗ (JTM) - описательное согласование

См. п.4.1.13 данного стандарта.

ПРИЛОЖЕНИЕ В (справочное). ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ СЛУЖБЫ ПОЗ (JTM)

ПРИЛОЖЕНИЕ В
Справочное

B.1. ВВЕДЕНИЕ

В этом приложении описываются некоторые тесты, которые могут применяться к реализующей системе службы ПОЗ (JTM), чтобы определить, соответствует ли реализующая система данному стандарту. Это приложение не формирует полную спецификацию тестов, но до некоторой степени предоставляет структуру, внутри которой такая спецификация могла бы развиваться. По этой причине эта структура не является частью данного стандарта.

Это приложение описывает набор тестов для реализующих систем службы ПОЗ (JTM). Реализующая система не обязательно должна тестироваться, a также реализующей системе может просто не потребоваться согласование, потому что она пропускает все перечисленные тесты.

Эти тесты должны применяться при необходимости, когда требуется проверить реализующую систему.

В.2. АРХИТЕКТУРА ТЕСТИРОВАНИЯ

В.2.1. Процедура тестирования нижнего уровня

В этом случае, если применяемые стандарты известны, то возможно присоединить соответствующее тестовое оборудование к физической среде и использовать его для определения протокольных блоков данных, которые должны передаваться, и для формирования протокольных блоков данных. Если нижние уровни реализующей системы службы ПОЗ (JTM), подлежащей тестированию, принимаются во внимание для соответствия (они уже были проверены тестами, указанными для своего уровня), и тестовое оборудование содержит соответствующую реализующую систему нижних уровней, то эта реализующая система может использоваться для распознавания или генерации концептуальных событий на нижней границе этого уровня, подлежащего тестированию (Примитивы индикации P-DATA в контексте службы ПОЗ (JTM) и сервисные примитивы индикации и подтверждения типа "С-").

Если проверка выполняется по нисходящей видимого интерфейса ниже уровня, подлежащего тестированию, но выше физической среды, то предоставляются альтернативные средства распознавания или генерации концептуальных событий на нижней границе этого уровня.

И наконец, события на нижней границе уровня, подлежащего тестированию, также могут распознаваться или генерироваться с помощью использования видимого интерфейса в удаленном оборудовании (вводя примитивы запроса P-DATA или сервисные примитивы запроса типа "С-").

Оборудование или набор процедур, используемых для генерации и отображения этих событий (используя любую из вышепредставленных конфигураций), представляет собой процедуру тестирования нижнего уровня. Подробное определение этого оборудования или набора процедур находится вне компетенции данного стандарта.

Имеется возможность применять ряд тестов, использующих только одни процедуры тестирования нижнего уровня. Такие тесты могут не зависеть от деталей реализующей системы и, следовательно, в основном должны предшествовать тестам, использующим другие интерфейсы. Однако, тесты только в одном этом интерфейсе недостаточны для обнаружения определенных форм несогласованности.

В.2.2. Процедуры тестирования верхнего уровня

Реализующая система службы ПОЗ (JTM) либо:

а) предоставляет видимый интерфейс для сервисных примитивов типа "J-",

либо

б) указывает соответствующий стандарт, который делает возможным использование сервисных примитивов типа "J-", и сама предоставляет видимый интерфейс.

Соответствующая конфигурация теста или процедуры может использовать этот видимый интерфейс, и необходимо выполнять какие-либо тесты, связанные с "реальными" услугами, предоставляемыми службой ПОЗ (JTM), такие как успешное выполнение распечатки выходной информации. Такая конфигурация или набор процедур формирует процедуры тестирования верхнего уровня; она всегда содержит какие-либо возможности, которые зависят от реализующей системы, так как для интерфейсов нет стандартов (кроме интерфейсов для физической среды). Тестируемые интерфейсы нижнего и верхнего уровней показаны на черт.B.1.

Черт.B.1. Архитектура тестирования службы ПОЗ (JTM)

Архитектура тестирования службы ПОЗ (JTM)

ТЕСТИРУЕМЫЙ