ГОСТ Р ИСО/МЭК 8831-99 Информационная технология. Взаимосвязь открытых систем. Концепции и услуги передачи и обработки заданий

ГОСТ Р ИСО/МЭК 8831-99

Группа П85

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

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

Взаимосвязь открытых систем

КОНЦЕПЦИИ И УСЛУГИ ПЕРЕДАЧИ И ОБРАБОТКИ ЗАДАНИЙ

Information technology. Open Systems Interconnection.
Job transfer and manipulation concepts and services

ОКС 35.100.70
ОКСТУ 4002

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

Предисловие

1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного Комитета Российской Федерации по связи и информатизации

ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 "Информационные технологии"

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

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

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

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

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

1.1 Назначение

Настоящий стандарт является стандартом прикладного уровня архитектуры взаимосвязи открытых систем (ВОС), установленной ГОСТ 28906.

Он определяет концепции и услуги для ПОЗ.

Настоящий стандарт требует от пользователя ПОЗ:

- указать открытые системы, в которых должна быть выполнена работа;

- знать локальные функции и возможности открытых систем, в которых должна быть выполнена работа;

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

Настоящий стандарт обеспечивает возможность для:

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

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

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

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

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

Настоящий стандарт содержит ссылки на следующие стандарты:

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

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

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

ГОСТ 27463-87 Обработка информации. Набор символов 7-битного кода ИСО для обмена информацией

ГОСТ 27466-87 Обработка информации. Наборы символов 7- и 8-битных кодов ИСО. Методы расширения кода

ГОСТ 28906-91 (ИСО 7498-84, Доп.1-84 ИСО 7498-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель

ГОСТ Р 34.1980.3-92 (ИСО 8571-3-88) Информационная технология и взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла

ГОСТ Р ИСО/ТО 8509-95. Системы обработки информации. Взаимосвязь открытых систем. Условные обозначения служб

ГОСТ Р ИСО/МЭК 9804-96 Системы обработки информации. Взаимосвязь открытых систем. Определение услуг для сервисного элемента исполнения, совмещения и восстановления

ИСО 2375-85* Обработка данных и процедуры регистрации выходной последовательности
_____________
* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

ИСО/МЭК 8832-92* Информационная технология. Взаимосвязь открытых систем. Спецификация протокола базового класса и полного протокола для передачи и обработки заданий.
_____________
* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

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

1.3.1 Определения услуг СПВ

В настоящем стандарте применимы следующие термины, определенные в ГОСТ Р ИСО/МЭК 9804:

a) элементарное действие;

b) главный управляющий логический объект (ГУЛО);

c) управляющий логический объект (ЛО);

d) управляемый ЛО;

e) исполнение;

f) возврат в первоначальное состояние.

1.3.2 Определения услуг ПОЗ

Определения группируются в основные категории в соответствии с 2.1.

Для настоящего стандарта применяют следующие определения.

1.3.2.1 Общее описание

1.3.2.1.1 Агентство - абстрактное описание таких функций реальной открытой системы, которые необходимы для обеспечения услуги ПОЗ.

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

1.3.2.1.3 Документ - совокупность данных, при помощи которых формируют часть СР и элемент взаимодействия между поставщиком услуг ПОЗ и агентством.

1.3.2.1.4 Инициирующее агентство - агентство, которое вызывает создание СР.

1.3.2.2 Проформы и порождение

1.3.2.2.1 Проформа - часть СР, которая указывает дальнейшую работу и используется для формирования новой СР, как части выполнения более ранней работы.

1.3.2.2.2 Порождение - процесс получения данных из проформы и использования их для формирования новой СР.

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

1.3.2.2.4 Проформа верхнего уровня - проформа, которая не содержится внутри никакой другой проформы.

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

1.3.2.3 Исходные, принимающие и исполняющие агентства

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

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

Примечание - Исходные и принимающие агентства могут получать и размещать документы местными средствами при помощи использования нестандартных протоколов или использования службы "передача файлов, доступ к файлам и управление файлами" (ПДУФ).

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

1.3.2.3.4 Активность (в агентстве) - работа, выполняемая агентством, инициируемым сервисным примитивом (СП), выданным этому агентству поставщиком услуг ПОЗ; завершение этой активности указывается СП, выданным этим агентством поставщику услуг ПОЗ.

1.3.2.4 Задания ВОС

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

1.3.2.4.2 Задание ВОС - общая работа во всех открытых системах, являющаяся непосредственно или косвенно результатом обработки начальной СР.

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

1.3.2.4.4 Предоставление задания ВОС - использование СП инициирования инициирующим агентством для создания начальной СР.

1.3.2.4.5 Система предоставления заданий ВОС - открытая система, в которой имеет место предоставление задания ВОС.

1.3.2.5 Отчетность и функция монитора

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

1.3.2.5.2 Мониторы задания ВОС - открытые системы, в которые посылаются отчеты ПОЗ о состоянии определенного задания ВОС.

1.3.2.5.3 СР отчета - тип СР, созданной поставщиком услуг ПОЗ для перемещения отчетов ПОЗ; целевая открытая система для таких СР представляет собой открытую систему мониторов задания ВОС.

1.3.2.6 Исполнение, совмещение и восстановление (СИВ)

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

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

1.3.2.6.3 Диагностика "повторить-позже" - информация, передаваемая услугой СИВ при возврате в исходное состояние, если действие не может быть завершено по временным причинам.

1.3.2.6.4 Диагностика "не-повторять" - информация, передаваемая услугой СПВ при возврате в исходное состояние, если действие не может быть завершено и позже попытка повторного выполнения не предполагается.

1.3.2.7 Управление передачами

1.3.2.7.1 Передача СР - элементарное действие, при котором СР создается в принимающей открытой системе и разрушается в посылающей открытой системе.

1.3.2.7.2 Запись управления передачей (ЗУП) - концептуальная структура данных, сохраняемая открытой системой, для управления передачей СР и введением СП.

1.3.2.8 Управление отчетами

1.3.2.8.1 Операции управления отчетами - операции, запрашивающие удаление или отображение отчетов, сохраняемых открытой системой, назначенной некоторой СР в качестве пункта монитора.

1.3.2.8.2 Спецификация работы управления отчетами - СР, содержащая операции управления отчетами.

1.3.2.9 Выполнение работы

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

1.3.2.9.2 СР выполнения работы - СР, содержащая операции выполнения работы.

1.3.2.9.3 Селектор - данные, которые используются для указания выбора СР.

1.3.2.9.4 Обновление - данные, которые используются для модификации выбранной СР или проформы.

1.3.2.10 Управление передачами

1.3.2.10.1 Операции управления передачами - операции, запрашивающие ЗУП установки, отображения или проверки.

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

1.3.2.11 Полномочия и учет

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

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

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

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

Примечание - Идентификация пользователя и счета состоят из имени идентифицированного полномочия вместе с одной из идентификаций, которые выдает этот пользователь.

1.3.2.11.5 Идентификация САУ открытыми системами - имя открытой системы, которая, если она аутентифицирована, предоставляет полномочия активностям ПОЗ или подсчитывает расходы, затраченные на административное управление этой открытой системой.

Примечание - Примерами таких активностей является удержание СР, подлежащих передаче, или установка ЗУП.

1.3.2.11.6 Идентификация САУ идентифицированными уполномоченными - имя идентифицированного уполномоченного, который, будучи аутентифицирован, предоставляет полномочия активностям ПОЗ, относящимся к управлению активностью, инициируемой идентификациями пользователя, выдаваемыми этим уполномоченным.

1.3.2.12 Идентификация СР

1.3.2.12.1 Локальный указатель задания ВОС - указатель задания ВОС, который является уникальным в пределах системы предоставления задания ВОС, назначенной этой открытой системой.

1.3.2.12.2 Идентификация инициирования - идентификация, обеспечиваемая пользователем ПОЗ во время предоставления задания для идентификации инициатора задания ВОС.

1.3.2.12.3 Имя задания ВОС - строка знаков, обеспечиваемая инициирующим агентством во время предоставления задания ВОС.

1.3.2.12.4 Идентификатор СР - уникальный указатель СР, содержащий имя системы предоставления задания ВОС, идентификацию инициирующего пользователя, локальный указатель задания ВОС и имя задания ВОС; если СР была создана порождением, идентификатор содержит также одно или несколько имен проформ.

1.4 Сокращения

ВОС - взаимосвязь открытых систем;

ГУЛО - главный управляющий логический объект;

ЗУП - запись управления передачей;

ЛО - логический объект;

ПДУФ - передача, доступ и управление файлом;

ПОЗ - передача и обработка заданий;

PC - реализующая система;

САУ - система административного управления;

СП - сервисный примитив;

СИВ - исполнение, совмещение и восстановление;

СР - спецификация работы;

СЭПУ - сервисный элемент прикладного уровня;

СЭУА - сервисный элемент управления ассоциацией.

1.5 Соглашения

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

РАЗДЕЛ 2. ОБЗОР

2.1 Обзор и общее описание

Чтобы определить услуги ПОЗ, требуется модель элементов, входящих в услуги. Эта модель ПОЗ получается из определений в ГОСТ 28906 с добавлением последующих уточнений, относящихся к этим услугам.

2.1.1 Обзор

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

Запрошенная работа выполняется при помощи:

a) стандартизованных функций поставщика услуг ПОЗ;

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

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

СР имеет поля, содержащие данные для:

a) идентификации работы;

b) полномочий работы;

c) определения адресата для передачи отчетов о выполнении работы;

d) выбора требуемых отчетов;

e) идентификации типа СР;

f) идентификации открытых систем, которые должны выполнять работу;

g) указания срочности выполнения работы;

h) задержки частей работы до тех пор, пока не произойдут определенные события;

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

j) указания дальнейшей работы, которая должна быть выполнена при завершении начальной работы.

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

Содержимое СР имеет отношение к следующим возможностям, которые обеспечиваются службой ПОЗ и полностью определены в 3.4.

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

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

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

Может быть указано поле "мониторы задания ВОС"; это - открытые системы, в которые должны быть посланы выбранные отчеты.

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

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

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

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

Могут быть указаны поля "срочность" и "удержание" требуемой работы.

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

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

2.1.3 Проформы и порождение

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

2.1.4 Исходные, принимающие и исполняющие агентства

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

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

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

В любой момент до завершения активности в принимающем и исполняющем агентстве могут иметь следующие события:

a) поставщик услуг ПОЗ может после обработки запроса на выполнение работы (см. 2.1.11) потребовать, чтобы активность была уничтожена, остановлена, задержана или выполнить разъединение;

b) поставщик услуг ПОЗ может запросить информацию о состоянии активности;

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

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

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

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

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

a) в форме "специфичная-для-ПОЗ", которая соответствует простому локальному или удаленному доступу в нестандартном виде;

b) в форме, определенной ГОСТ Р 34.1980.3, которая соответствует локальному или удаленному доступу при условии обеспечения службы ПДУФ.

2.1.5 Задания ВОС

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

2.1.6 Обработка спецификаций работы

2.1.6.1 Нормальная обработка

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

a) осуществляется доступ к исходным агентствам и документы, переданные этими агентствами, (концептуально) вводятся в СР;

b) СР (включая любые вложенные документы) передается в другую открытую систему, используя протокол ПОЗ;

c) документы внутри СР передаются в одно или несколько принимающих и исполняющих агентств, как указано СР;

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

e) при завершении всех вышеперечисленных действий активности начальная СР уничтожается.

Если при обработке СР были сформированы и новые СР, то после обработки эти новые СР могут в дальнейшем обусловить доступ к исходным агентствам, как это было описано выше.

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

2.1.6.2 Ошибки при обработке задания ВОС

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

Ошибки, обнаруживаемые открытой системой (ответственной за СР) во время ее обработки, трактуются, как описано ниже.

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

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

Обработка ошибок открытой системой, которая ответственна за СР, может быть представлена следующим образом:

a) при обращении к исходному агентству:

1) вставить диагностическое сообщение и продолжить;

2) аварийно завершить;

3) приостановить, чтобы позволить пользователю исправить ошибку и позже повторить попытку;

b) при обращении к принимающему агентству:

1) аварийно завершить;

2) приостановить, чтобы позволить пользователю исправить ошибку и позже повторить попытку;

c) при попытке передать СР:

1) аварийно завершить;

2) приостановить, чтобы позволить пользователю исправить ошибку и позже повторить попытку.

В базовом классе в каждом из перечисленных выше случаев доступной является только факультативная возможность (1).

2.1.7 Отчетность и функция монитора

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

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

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

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

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

СР отчетов отличаются от других СР следующим:

a) СР отчетов не содержат никаких документов пользователя; информация отчета содержится в них в закодированной форме;

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

c) идентификация СР отчетов является такой же, как и для СР, о которых должен быть сформирован отчет;

d) обработка СР отчетов никогда не вызывает создания дополнительных отчетов, которые должны быть сформированы; ошибки, обнаруженные во время их обработки или передачи, вызывают потерю этих СР;

e) СР отчетов содержат все возможности (см. 2.1.13), которые имелись в тех СР, о которых должны быть выданы отчеты; однако они игнорируются, если предпринимается любая попытка модифицировать СР отчетов; эти СР существуют, чтобы предоставить информацию монитору задания ВОС при обработке последующих запросов управления отчетами (см. 2.1.10);

f) передача СР отчетов (и управление, см. 2.1.11) имеет более высокий приоритет относительно другого трафика ПОЗ.

Для уведомляющей службы могут быть выбраны следующие категории событий (определены в 3.3):

a) формирование задания ВОС;

b) передача (ответственности за) СР из одной открытой системы в другую;

c) формирование новой СР путем порождения;

d) прием документов принимающими или исполняющими агентствами;

e) нормальное завершение СР после завершения подзадания;

f) преждевременное окончание подзадания вследствие управляющего запроса (ОСТАНОВ);

g) удаление СР и завершение подзадания вследствие управляющего запроса (УНИЧТОЖИТЬ);

h) модификация подзадания с помощью управляющего запроса;

i) обнаружение ошибок в СР, результатом чего является вложенная в нее диагностика ошибки;

j) задержка СР для корректировки ошибок;

k) аварийное завершение СР вследствие ошибок;

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

m) формирование информации активностью в исполняющем агентстве (сообщения пользователя);

n) аварийное завершение СР вследствие запроса средств, которые не обеспечены;

о) попытка модификации СР подзаданием, которое не имеет необходимых полномочий;

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

СР отчетов содержит одно или несколько отчетов. Каждый отчет имеет следующие параметры:

a) имя открытой системы, формирующей отчет (см. 2.1.14);

b) идентификация подзадания, о котором предстоит выдать уведомление, и идентификация инициатора этого подзадания;

c) тип события, о котором необходимо выдать отчет;

d) дата и время формирования отчета (факультативно);

e) нестандартное текстовое сообщение.

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

2.1.8 Исполнение, совмещение и восстановление

2.1.8.1 Общее описание

Чтобы обеспечить правильное выполнение услуги ПОЗ при наличии сбоев в прикладном процессе или системе связи (восстановление после ошибок), нечувствительность к влиянию других активностей (управление совмещением) и возможность выполнения задания ВОС в виде одного или нескольких элементарных действий (исполнение), используются процедуры СИВ, определенные в ГОСТ Р ИСО/МЭК 9804.

Каждая передача ПОЗ между открытыми системами и каждое взаимодействие с агентством использует СП, к которым применяется семантика СИВ. Процедуры, определенные в ГОСТ Р ИСО/МЭК 9804, выполняются каждой открытой системой и концептуально - каждым агентством.

В приложении С к ГОСТ Р ИСО/МЭК 9804 описывается сущность СИВ для тех, кто не знаком с его работой. Понимание работы СИВ существенно для понимания ПОЗ.

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

Служба СИВ предоставляет параметр "данные пользователя" во всех примитивах.

Эти данные пользователя используются, чтобы:

a) указать минимальный требуемый уровень исполнения операции и действительно достигнутый уровень;

b) указать управляемому ЛО набор символов, которые ГУЛО предпочитает для диагностических сообщений;

c) указать, когда управляемый ЛО возвратится в исходное состояние, может ли последующая попытка быть успешной ("повторить-позже") или сбой был по той же причине ("не-повторять");

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

2.1.8.2 Уровни исполнения операций для ПОЗ

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

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

2.1.8.2.1 Уровень исполнения "завершение" (уровень 3)

Наивысшим уровнем исполнения является ЗАВЕРШЕНИЕ (уровень 3). В этом случае все задание ВОС завершается как часть начального элементарного действия.

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

Такой уровень исполнения операций иногда описывается как "неавтономная" обработка.

2.1.8.2.2 Уровень исполнения "приемлемый для агентства" (уровень 2)

Следующим более низким уровнем исполнения операций является ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА (уровень 2). В этом случае исполнение по отношению к начальному элементарному действию означает, что начальное подзадание ВОС было обработано, по меньшей мере, до момента, когда все указанные исходные агентства стали доступными, и все взаимодействия с принимающими и исполняющими агентствами представили в результате соответствующие документы, обеспечиваемые данным агентством, для более позднего завершения подзадания ВОС, как части последующих элементарных действий.

2.1.8.2.3 Уровень исполнения "приемлемый для поставщика" (уровень 1)

Самым низким уровнем исполнения операций является ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА (уровень 1). (Этот уровень относится также ко всем элементарным действиям, инициированным после начального элементарного действия). На этом уровне начальное элементарное действие заканчивается сохранением СР, сформированной поставщиком услуг ПОЗ, и она становится видимой другим открытым системам. При этом нет гарантии, что указанные исходные документы будут доступны, или какой-либо материал будет передан принимающим или исполняющим агентствам. Этот уровень исполнения всегда доступен пользователю, даже если локальная система в данный момент неспособна установить никакой связи с другими открытыми системами. Он может быть описан как "автономная" обработка.

2.1.8.2.4 Определение действий агентства

Исходное агентство трактует все уровни исполнения как требование выдать запрошенный материал (или отклонить исполнение).

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

2.1.8.3 Тайм-ауты

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

2.1.8.4 Данные пользователя при запуске элементарного действия

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

2.1.8.4.1 Уровень исполнения

Параметр "уровень исполнения" представляет собой целое число (см. 2.1.8.2) Самым низким уровнем исполнения является уровень 1, самым высоким - уровень 3.

Если параметр "уровень исполнения" имеет максимальное значение, все действия завершаются прежде, чем управляемый ЛО предложит уровень исполнения. Если он имеет минимальное значение, управляемому ЛО необходимо только отметить действия, которые должны быть выполнены (например, сохранение данных), и выполнить их несколько позже.

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


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

Элементарное действие, начатое управляемым ЛО, имеет равный или более высокий уровень исполнения, чем принятый от управляющего ЛО в начале действия.

2.1.8.4.2 Указатель кода диагностики

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

Каждый определитель кода имеет ссылку на один или несколько наборов графических знаков в элементах регистра с данными номерами. Каждое последующее диагностическое сообщение, сформированное ПОЗ, содержит только знак ПРОБЕЛ вместе со знаками из набора знаков, на который указывает один из определителей кода.

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


Определители кода представлены в указателе кода диагностики в порядке предпочтительности ГУЛО СИВ. Определитель кода с одним числом 2, указывающим графические знаки международной справочной версии по ГОСТ 27463, всегда неявно существует, по меньшей мере, в качестве предпочтительного выбора. Пустой указатель кода диагностики указывает только ГОСТ 27463.

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

2.1.8.5 Использование данных пользователя СИВ при предложении исполнения

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

2.1.8.5.1 Уровень исполнения

Формат параметра "уровень исполнения" описан в 2.1.8.4.1. Его значение в предложении уровня исполнения выше или равно его значению при запуске элементарного действия.

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

2.1.8.5.2 Параметр "диагностика"

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

a) имени формирователя диагностического сообщения;

b) кода диагностики ПОЗ;

c) читабельного текста сообщения или структуры данных ПДУФ, содержащей предупреждение.

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

Значения кода диагностики ПОЗ описываются в спецификациях протокола ПОЗ.

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

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

Примечания

1 Количество строк знаков не ограничивается.

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

2.1.8.5.3 Параметр "учет"

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

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

a) (глобально однозначную) идентификацию счета (см. 2.1.13);

b) идентификатор ресурса в виде строки знаков;

c) единицу затрат в виде строки знаков;

d) затраты в виде целого числа.

Значения в b) и с) назначаются идентификационным полномочием (см. 2.1.13), связанным с идентификацией учета.

2.1.8.6 Использование данных пользователя СИВ при возврате в исходное состояние

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

Отметим, что средства СИВ не гарантируют передачу данных пользователя при возврате примитива в исходное состояние.

2.1.8.6.1 Параметр "диагностика"

Указывает значение "повторить-позже" или "не-повторять".

В значении "не-повторять" параметр состоит из одного или нескольких диагностических сообщений, содержащих:

a) имя формирователя диагностического сообщения;

b) код диагностики ПОЗ;

c) читабельный текст сообщения, или структуру данных службы ПДУФ, содержащий значение "не-повторять".

В значении "повторить-позже" параметр состоит из факультативного параметра "тайм-аут повторения" и факультативного диагностического сообщения, возможно, содержащего структуру данных ПДУФ, со значением "повторить-позже".

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

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

Порядок предпочтительности следующий:

a) предупреждение (наинизшая);

b) "повторить-позже";

c) "не-повторять" (наивысшая).

2.1.8.6.2 Параметр "учет"

Имеет формат, описанный в 2.1.8.5.3.

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

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

2.1.9 Управление передачами

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

ЗУП не влияет на передачу СР управления передачей (см. 2.1.12). Она может управлять всеми другими типами СР в зависимости от значения селекторов.

Открытая система с СР для передачи другой открытой системе при отсутствии ЗУП для адресуемой системы пытается выполнить передачи по порядку и со степенью совмещения выполнения, определяемой локально.

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

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

2.1.10 Управление отчетами

СР управления отчетами содержит одну или несколько операций управления отчетами. Имеется два типа операций, определенных для управления отчетами.

Первый тип - операция УДАЛИТЬ, которая вызывает удаление всех принятых отчетов об указанном задании ВОС или о дереве подзаданий. Параметром такого типа является только "идентификация СР", который используется для ссылки на отчеты в указанной СР или в спецификации, созданной из нее.

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

Действием, которое выполняется поставщиком услуг ПОЗ в открытой системе, является прием каждого отчета, который был получен в соответствии с указанной СР, в том порядке, в котором они поступали, и формирование документа, содержащего отчет. Если две операции ОТОБРАЗИТЬ указывают одно и то же имя документа, то обе эти операции помещаются в один и тот же документ. Конец активности формирует обычным способом порождение новых СР из проформ; они образуют документ отображения.

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


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

2.1.11 Выполнение работы

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

Первой является операция "выбор"; выбранными СР или проформами являются такие, к которым применяются все операции, предшествующие следующей операции "выбор". Формат селектора СР описывается в 2.1.11.1.

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

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

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

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

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

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

Если подзаданием А предпринимается неполномочная попытка модификации СР В, то результатом является событие ПОПЫТКА-НАРУШЕНИЯ для В, по которому может быть послан отчет в один или несколько пунктов монитора В.

2.1.11.1 Селекторы

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

Базовые тесты имеют формат

Оператор имя-поля значение,

где диапазон допустимых имен полей и операций определен в разделе 3.

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

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

2.1.11.2. Обновления

Операция обновления имеет формат

Оператор имя-поля значение

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

Концептуальная структура данных "список-заголовков" используется, кроме того, для указания обновления, но изменения этих полей вызывают соответствующие изменения в соответствующей СР.

2.1.12 Управление передачами

СР управления передачами содержит одну или несколько операций управления передачами.

Имеются операции управления передачами ПОЗ для установки, отображения и проверки ЗУП.

Операция "установка" имеет параметр, представляющий ЗУП.

Операция "отображение" имеет один параметр, который идентифицирует ЗУП, и второй параметр, содержащий имя документа; он отображает текущую ЗУП в указанном документе для формирования путем порождения.

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

СР управления передачами нуждается в элементе полномочий для системы управления любой открытой системы, на которую имелся указатель в ЗУП операции "установка" или "отображение", а также для системы управления открытой системы, выполняющей операцию "проверка" (см. 2.1.13)

2.1.13 Полномочия и учет

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

Чтобы воспринять поле доступа как "уже проверенное", должна быть доступна аутентифицированная идентификация открытой системы, которая выполнила проверку. Это достигается пошаговым способом. Услуги более нижнего уровня предоставляют поставщику услуг ПОЗ аутентифицированное имя вызывающей открытой системы. Эти данные записываются в СР, так что она содержит имя каждой открытой системы, через которую передается СР (или имя одного из ее "порождающего"). Таким образом, открытая система способна определить при помощи проверки этих данных доступность элементов полномочий, требующих, чтобы идентификация была уже аутентифицирована. (Подробная операция этой процедуры указывается в ГОСТ Р ИСО/МЭК 8832). Дальнейшее описание (и примеры) такого механизма содержатся в приложении С.

Элемент полномочий может идентифицировать пользователя, систему управления идентификационного полномочия или САУ открытой системы.

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

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

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

Локальная САУ открытой системы решает, позволить ли отображения запросов и состояний СР без наличия разрешения или трактовать СР как невидимую никому другому, кроме тех, кто имеет разрешение модифицировать ее.

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

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

2.1.14 Идентификация спецификаций работы

Идентификатор СР предоставляет явное имя, посредством которого к СР можно обращаться для формирования отчета или СР обработки.

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

В результате все СР имеют идентификацию, известную как идентификатор СР. Полное задание ВОС, которое представляется множеством всех его СР, может указываться путем ссылки на имя системы предоставления задания ВОС или:

а) идентификации инициирующего пользователя и имени задания ВОС;

в) локального указателя задания ВОС.

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

2.1.15 Ответственность службы отчетности

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

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

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

2.1.15.1 Отдельная служба отчетности

К отчетам, формируемым в качестве отдельных элементарных действий, относятся:

a) отчеты учетной информации;

b) отчеты о попытке нарушений защиты;

c) отчеты о безуспешности элементарного действия, выражающееся в невыполнении СР или в его аварийном завершении.

2.1.15.2 Интегрированная служба отчетности

К отчетам, формируемым только при завершении главного действия, относятся:

a) отчеты о том, что по примитиву J-INITIATE создана новая СР;

b) отчеты о порождении новой СР;

c) отчеты о том, что другая открытая система приняла ответственность за обработку СР в последующем элементарном действии;

d) отчеты о том, что для подзадания имел место уровень исполнения ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА;

e) отчеты о том, что в СР вместо документа была включена диагностика ошибки (для доставки в принимающее агентство);

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

g) отчеты о нормальном завершении подзадания;

h) отчеты о завершении подзадания или модификации в результате обработки другой СР (см. 2.1.11);

i) предупреждающие отчеты.

2.1.15.3 Ответственность отдельной службы отчетности

Ответственность за выдачу отчетов, сформированных в качестве отдельных элементарных действий, возлагается:

a) за учетную информацию - на ту открытую систему, которая содержит ГУЛО элементарного действия; (отметим, что если ГУЛО имеет агентство ПОЗ, отчет формируется поставщиком услуг ПОЗ, имеющим доступ к этому агентству); учетная информация предоставляется ГУЛО параметром "учет" в данных пользователя примитивов СИВ; количество и частота выдачи таких отчетов не стандартизованы;

b) за попытку нарушения - на открытую систему, ответственную за обработку СР;

c) за отчет о сбое элементарного действия - на открытую систему, содержащую ГУЛО элементарного действия; диагностические сообщения направляются ГУЛО в параметре "диагностика" в данных пользователя примитивов СИВ.

2.1.15.4 Ответственность интегрированной службы отчетности

Возлагается на наиболее заинтересованную открытую систему:

a) за создание - на открытую систему, в которой выдается примитив запроса J-INITIATE;

b) за порождение - на открытую систему, выполняющую порождение;

c) за передачу ответственности - на открытую систему, принимающую ответственность;

d) за уровень исполнения ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА - на открытую систему, в которой выдаются СП индикации J-DISPOSE;

e) за встроенную диагностику об ошибках - на открытую систему, выполняющую встраивание диагностики;

f) за сообщения пользователя - на открытую систему, в которой был выдан СП J-MESSAGE;

g) за нормальное завершение - на открытую систему, завершающую подзадание;

h) за завершение обработки - на открытую систему, выполняющую обработку и ответственную за обработку СР.

2.1.15.5 Трассировка задания

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

Такая трассировка задания не требуется для PC по ИСО/МЭК 8832 и может быть выполнена исключительно неавтоматизированным способом. С другой стороны, не исключаются высокосложные PC.

Минимальными подходящими категориями отчетов являются:

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

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

c) отчеты о передаче ответственности, указывающие новый ЛО в открытой системе, ответственный за обработку подзадания;

d) отчеты о нормальном, аварийном завершении и о завершении обработки, указывающие об окончании поименованного подзадания.

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

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

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

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

a) отчетами ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА;

b) отчетами о задержке и освобождении СР посредством модификации или о состоянии "нет-развития".

2.1.16 Документы

ПОЗ определяет три следующих типа документов, которые содержат информацию ПОЗ: "ПОЗ-отображение-отчета" (определены в 3.5.1), "ПОЗ-отображение-передачи" (определены в 3.5.3) и "ПОЗ-отображение-работы" (определены в 3.5.2).

Семантика документов этих типов полностью определена в настоящем стандарте, а синтаксис передачи таких документов полностью определен протоколом ПОЗ.

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

ПОЗ различает три класса типов документов:

a) типы документов "ПОЗ-сформировано"; это три описанные выше типа;

b) типы стандартизованных документов; это типы документов, семантика и синтаксис передачи которых были определены в другой системе и для которых имеется элемент в регистре типов документов ИСО;

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

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

Эти типы документов определены в ИСО/МЭК 8832. Все они при необходимости могут обеспечиваться ПДУФ.

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

Примечание - В приложении В представлена информация, необходимая в элементе регистра типа документа для регистрации или распределения определений специфических типов документов.

2.1.17 Промежуточные системы ПОЗ

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

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

Примечание - Эти промежуточные системы являются системами прикладного уровня ПОЗ, и их не следует путать с промежуточными системами обмена данными.


СР передается в первую промежуточную систему, затем - во вторую и так далее до тех пор, пока последняя промежуточная система не передаст ее в целевую систему. Если выбрана служба отчетности событий ПЕРЕДАЧА, отчеты формируются для каждой из этих передач.

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

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

Примеры использования промежуточных систем приведены в приложении С.

2.2 Обзор службы

СП ПОЗ, определенные в разделе 3, описываются в понятиях элементов модели, описанных в 2.1. Эти СП ПОЗ предусмотрены для выполнения всех относящихся к заданию активностей между открытыми системами.

Они предназначены для:

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

b) доставки документов принимающим агентствам при взаимодействии с ними до завершения активности, вызнанной этой доставкой;

c) сбора документов из исходных агентств;

Примечание - Использование ПДУФ исходными или принимающими агентствами обеспечено полностью.

d) доставки документов исполняющим агентствам для обработки при взаимодействии с ними до завершения активности этих агентств, вызванной этой доставкой.

2.3 Базовые и расширенные реализующие системы

Примечание - Полное определение службы ПОЗ базового класса приведено в разделе 4.


Различаются PC базисного класса и расширенные. PC базового класса обеспечивает только подмножество возможного диапазона СР и параметров в СП ПОЗ.

Возможно взаимодействие между расширенной PC и РС базового класса. В частности, возможно, чтобы СР, сформированные в PC базового класса, были переданы для обработки в расширенной PC; обратное утверждение также возможно, если эта СР предусмотрена базовым классом (см. раздел 4 и подраздел С.17).

Основными ограничениями и характеристиками, относящимися к PC базового класса, являются:

a) СР содержит самое большее один документ;

b) СР содержит самое большее одну проформу верхнего уровня; любые вложенные проформы полностью прозрачны для PC базового класса;

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

d) могут быть выбраны только следующие службы отчетности:

1) аварийного завершения,

2) нормального завершения,

3) завершения обработки,

4) сообщений пользователя,

e) учет не обеспечивается;

f) уровень 3 исполнения операций ЗАВЕРШЕНИЕ не может быть запрошен;

g) ЗУП не обеспечиваются;

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

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

j) использование ПДУФ для получения или размещения документов не обеспечивается;

k) отсутствуют вторичные мониторы;

l) концепция "удержание" не обеспечивается;

m) не обеспечиваются следующие примитивы:

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

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

Поддержка таких агентств различна в PC базового класса и в расширенной PC.

2.4 Модель спецификации услуг

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

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

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

Рисунок 1 - Пользователи ПОЗ

Рисунок 1 - Пользователи ПОЗ

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

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

Другой набор СП относится к обработке СР.

Наконец, в модели ПОЗ имеется набор СП, относящийся к концепциям диспетчирования и состояний в модели ПОЗ.

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

РАЗДЕЛ 3. ОПРЕДЕЛЕНИЕ ПРИМИТИВОВ

3.1. Сервисные примитивы ПОЗ

Агентство представляет собой абстрактное отображение части реальной открытой системы.

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

Настоящий стандарт связывает семантику СИВ (как определено в ГОСТ Р ИСО/МЭК 9804) с этими СП. В нем представлены средства определения точек в протоколе ПОЗ, когда должны произойти внешне видимые события, и средства установления возможностей СИВ, которые должна проявлять общая реальная система.

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

3.1.1 Группы сервисных примитивов

Группа СП ПОЗ представляет собой последовательность СП, отдельные из которых отображаются в СП СИВ по ГОСТ Р ИСО/МЭК 9804, а некоторые из них имеют только функцию ПОЗ.

3.1.1.1 Создание новых спецификаций работы

Имеются четыре группы примитивов (вводимых инициирующим агентством), каждая из которых определяет создание новой СР в открытой системе:

J-INITIATE-WORK используется инициирующим агентством, чтобы создать СР дли перемещения документов;

J-INITIATE-WORK-MAN - используется инициирующим агентством, чтобы создать, СР для обработки существующих СР;

J-INITIATE-REPORT-MAN эта группа используется инициирующим агентством, чтобы создать СР для управления отчетами, полученными монитором заданий ВОС;

J-INITIATE-TCR-MAN используется инициирующим агентством, чтобы создать СР для обработки ЗУП ПОЗ.

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

3.1.1.2 Перемещение документа

Имеются три группы примитивов, инициируемых поставщиком услуг ПОЗ, являющихся результатом обработки СР перемещения документа, т.е. явным или неявным результатом обработки группы примитивов J-INITIATE. Первая группа выдается принимающему или исполняющему агентству, а две последние группы исполняющему или исходному агентству. Этими группами являются:

J-DISPOSE - используется поставщиком услуг ПОЗ для передачи документа принимающему или исполняющему агентству, создавая новую активность в этом агентстве;

J-GIVE - используется поставщиком услуг ПОЗ для запроса документа от исходного или исполняющего агентства;

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

3.1.1.3 Группы примитивов, инициируемые агентствами

Имеются три группы примитивов, которые инициируются принимающим или исполняющим агентством в отношении к указанной активности, которая выполняется в этом агентстве:

J-MESSAGE - (только исполняющее агентство) используется агентством, чтобы запросить поставщика услуг ПОЗ сформировать СР отчетов СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ;

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

J-END-SIGNAL - используется принимающим или исполняющим агентством для сигнализации конца активности, которая выполнялась после предыдущего исполнения с уровнем ПРИНЯТИЕ.

3.1.1.4 Группы примитивов, инициируемые поставщиком

Имеются пять групп примитивов, которые инициируются поставщиком услуг ПОЗ для принимающего или исполняющего агентства, чтобы управлять активностью, которая выполняется после предыдущего исполнения с уровнем ПРИНЯТИЕ:

J-STATUS - используется поставщиком услуг ПОЗ для получения информации о выполнении активности;

J-HOLD - используется поставщиком услуг ПОЗ для запроса временного приостановления выполнения активности (ее единственным назначением является предотвращение ввода группы примитивов в 3.1.1.3, другие действия не стандартизованы);

J-RELEASE - используется поставщиком услуг ПОЗ для завершения выполнения ранее введенной группы J-HOLD;

J-KILL - используется поставщиком услуг ПОЗ для завершения активности; это непосредственно вызывает группу J-END-SIGNAL, а документы не предоставляются исполняющим агентством; желательно, но не обязательно, чтобы все действия уничтожаемой активности были аннулированы;

J-STOP - используется поставщиком услуг ПОЗ для завершения активности; это непосредственно вызывает группу J-END-SIGNAL, но документы могут быть обеспечены; рекомендуется, но не требуется, чтобы любая уже выполненная работа не была аннулирована.

3.1.2 Компоненты групп сервисных примитивов

3.1.2.1 Группы, инициируемые агентством

Содержат следующие примитивы (в перечисляемом порядке):

Примитивы в подпунктах а), с) и d) содержат только параметры СИВ и точно соответствуют СП СИВ с тем же именем. Их последовательность, семантика и параметры полностью определены в ГОСТ Р ИСО/МЭК 9804, за исключением параметра "данные пользователя" (см. 3.1.3). Агентство представляет собой ГУЛО исполнения (вводит идентификатор элементарного действия СИВ и определяет уровень исполнения) во всех случаях, кроме групп J-MESSAGE и J-SPAWN. Если эти группы вводятся после исполнения с уровнем ПРИНЯТИЕ, агентство представляет собой ГУЛО исполнения, в противном случае оно представляет собой управляемое ЛO. Если агентство является управляемым ЛО, оно выбирает уровень исполнения больший или равный принятому. Для примитива запроса J-END-SIGNAL агентство всегда указывает ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА (уровень 1) и не отклоняет исполнение, если поставщик услуг ПОЗ предлагает его.

3.1.2.2 Группы, инициируемые поставщиком услуг ПОЗ

Состоят из следующих примитивов (в перечисляемом порядке):

Примитивы в подпунктах а), с) и d) содержат только параметры СИВ и точно соответствуют СП СИВ с тем же именем. Их последовательность, семантика и параметры полностью определены в ГОСТ Р ИСО/МЭК 9804, за исключением параметра "данные пользователя" (см. 3.1.3). Поставщик услуг ПОЗ представляет собой ГУЛО исполнения (и вводит идентификатор элементарного действия СИВ) только в том случае, если он уже имеет данный уровень исполнения ПРИНЯТИЕ по отношению к группе J-INITIATE, J-SPAWN или J-END-SIGNAL, которая сформировала СР, обусловившая выдачу примитивов, в противном случае он является управляемым ЛО. Если поставщиком услуг ПОЗ является ГУЛО, он всегда требует уровня исполнения 1.

3.1.2.3 Последовательность совокупности результатов

Эта последовательность состоит из одного или нескольких повторений:

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

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

3.1.3 Параметры примитивов, относящихся к СИВ

Параметры примитивов, относящихся к СИВ, идентифицируемых в 3.1.2.1 и 3.1.2.2, определены в ГОСТ Р ИСО/МЭК 9804. Параметр "данные пользователя", определенный в ГОСТ Р ИСО/МЭК 9804, используется для переноса специфичных для ПОЗ и относящихся к СИВ параметров, как определено ниже.

3.1.3.1 Примитивы запроса и индикации J-BEGIN

Эти примитивы содержат:

a) уровень исполнения (см. 2.1.8.4.1);

b) указатель кода диагностики (см. 2.1.8.4.2).

3.1.3.2 Примитивы ответа и подтверждения J-BEGIN

Параметр "данные пользователя" не используется.

3.1.3.3 Примитивы запроса и индикации J-PREPARE

Параметр "данные пользователя" не используется.

3.1.3.4 Примитивы запроса и индикации J-READY

Эти примитивы содержат:

a) уровень исполнения операций (см. 2.1.8.5.1);

b) факультативные предупреждения (см. 2.1.8.5.2);

c) факультативную учетную информацию (см. 2.1.8 5.3).

3.1.3.5 Примитивы запроса и индикации J-COMMIT

Параметр "данные пользователя" не используется.

3.1.3.6 Примитивы ответа и подтверждения J-COMMIT

Параметр "данные пользователя" не используется.

3.1.3.7 Примитивы запроса и индикации J-ROLLBACK

Если эти примитивы передаются от управляемого ЛО к управляющему, эти примитивы содержат:

a) диагностику (см. 2.1.8.6.1);

b) факультативную учетную информацию (см. 2.1.8.6.2).

3.1.3.8 Примитивы ответа и подтверждения J-ROLLBACK

Параметр "данные пользователя" не используется.

3.1.3.9 Примитивы запроса и индикации J-RECOVER

Параметр "данные пользователя" не используется.

3.1.3.10 Примитивы ответа и подтверждения J-RECOVER

Параметр "данные пользователя" не используется

3.1.4 Последовательность групп сервисных примитивов

Примитивы следующей группы могут выдаваться в любое время:

J-INITIATE-WORK;

J-INITIATE-WORK-MAN;

J-INITIATE-REPORT-MAN;

J-INITIATE-TCR-MAN;

J-DISPOSE;

J-GIVE;

J-ENQUIRE.

На группы примитивов J-GIVE и J-ENQUIRE, выдаваемых исполняющему агентству, налагаются дополнительные ограничения. В этом случае они выдаются только (и завершаются) между примитивами запроса J-END-SIGNAL (или J-SPAWN) и соответствующими примитивами идикации J-READY (или J-ROLLBACK) или между примитивами ответа J-DISPOSE, если предлагается уровень исполнения ЗАВЕРШЕНИЕ, и соответствующими примитивами индикации J-COMMIT (или J-ROLLBACK).

Следующие группы выдаются между примитивом индикации J-DISPOSE и соответствующим примитивом запроса J-READY или J-ROLLBACK:

J-MESSAGE;

J-SPAWN.

Следующие группы выдаются между примитивом ответа J-COMMIT в группе J-DISPOSE, которая предоставила уровень исполнения ПРИНЯТИЕ, и примитивом запроса J-BEGIN, начиная с J-END-SIGNAL для заданной активности:

J-MESSAGE;

J-SPAWN;

J-END-SIGNAL.

Группа J-END-SIGNAL не начнется, если какая-либо другая группа не завершена относительно этой же активности, и на выданный примитив индикации J-DISPOSE примитив запроса J-READY не выдается, если не завершена последовательность примитивов J-MESSAGE или J-SPAWN.

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

J-STATUS;

J-HOLD;

J-RELEASE;

L-KILL;

J-STOP.

В дополнение к этим примитивам примитив J-RECOVER определяется с такой же семантикой и параметрами, что и примитив C-RECOVER, и может выдаваться, как описано в ГОСТ Р ИСО/МЭК 9804.

3.1.5 Последовательность сервисных примитивов

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

a) последовательность внутри группы примитивов определена в 3.1.2;

b) последовательность групп примитивов, выданных одним ЛО ПОЗ для одного подзадания ПОЗ, определена в 3.1.4;

c) последовательность примитивов с семантикой СИВ (в одинаковых или различных открытых системах) определена в определении службы СИВ;

d) если данные, обеспечиваемые одним примитивом (например, примитивом ответа J-GIVE), необходимы для выдачи другого примитива (например, примитива индикации J-DISPOSE), тогда последовательность этих примитивов определяется этим требованием;

e) на последовательность СП не налагается никаких ограничений.

Примеры применения этих правил для указания активности ПОЗ приведены в приложении С.

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

3.2 Нотация для сервисных примитивов и определение структуры данных

В этом разделе описывается нотация, используемая для определения параметров СП ПОЗ, которые не относятся к СИВ. (Параметры примитивов, относящихся к СИВ, имеют менее сложную структуру и определены в 3.1.3).

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

3.2.1 Базовые типы данных

Имеется шесть базовых типов данных, используемых ПОЗ:

a) литералы;

b) целочисленные типы данных;

c) типы данных "строка";

d) типы данных "имя";

e) типы данных "ссылка";

f) типы данных "документ".

Литерал указывается заданием имени литерала прописными буквами. Каждый литерал является неявной идентификацией, семантика которой полностью определяется в этом определении услуги. Например,

Все другие базовые типы данных записываются строчными буквами, заключенными в угловые скобки, со знаками "=I", "=S" или "=OS", "=N" или "=NA" или "=ND", "=R" и "=D", включенными для отметки базовых типов данных в перечислениях b) и f). Например:

Определение этих базовых типов данных приведено в 3.2.3.

3.2.2 Механизмы структурирования

Имеется четыре механизма (и соответствующая нотация) для формирования структурируемых типов данных:

a) упорядоченная последовательность типов данных; типы данных перечислены; например, тип данных <ВОС-параметры-подзадания> определяется как

<список-имен-подзадания>

<список целевых систем>

<срочность>

<удержания>

<тип подзадания>,

каждый из которых является еще и структурированным типом данных;

b) ни одного, одно или несколько повторений одного типа данных, где порядок следования имеет определенное значение и допускается дублирование (список); один тип данных заключается в квадратные скобки, за которыми следует знак "*L"; например, тип данных <список документов> определяется как

[<базовый документ = D> ]*L;

c) ни одного, одно или несколько повторений одного типа данных, где порядок следования не является существенным и дублированные значения не должны иметь места (совокупность); один тип данных заключается в квадратные скобки, за которыми следует знак "*С"; например, тип данных <разрешения> определяется как

[ <разрешения> ]*С;

d) выбор из двух или более вариантов, часто (но не всегда) литералов; варианты разделяются вертикальной чертой и заключаются в круглые скобки; например, тип данных <срочность> определяется как

<ВЫСОКИЙ | СРЕДНИЙ | НИЗКИЙ>.

Структурированный тип данных определяется размещением его имени слева от символа " : : = " со структурной нотацией справа. Например,

<разрешения>:: = [<элемент разрешения> ]*С

3.2.3 Определение базовых типов данных

3.2.3.1 Литерал и целочисленные типы данных

Значение каждого литерала определяется при его появлении.

Целочисленный тип представляет собой любое неограниченное значение от нуля и выше.

3.2.3.2 Типы данных "строка"

Этот тип данных представляет собой последовательность знаков и пробелов, взятых из набора знаков, зарегистрированного для использования в качестве наборов G0, G1, G2 или G3 в регистре наборов знаков ИСО, или строку октетов. В первом случае используется знак "=S", во втором - "=OS".

Требования согласования протокола ПОЗ определяют, что PC:

a) обеспечивает спецификацию полей строк со знаком "=S", используя по крайней мере

1) набор знаков справочной версии ГОСТ 27463 и

2) шестнадцатеричную нотацию для кодирования строк в соответствии с ГОСТ 27466;

b) обеспечивает отображение полей строк со знаком "=S", которые содержат только знаки по ГОСТ 27463, используя репертуар знаков, и других полей строк, используя репертуар знаков или шестнадцатеричную нотацию для кодирования строки в соответствии с ГОСТ 27466;

c) обеспечивает спецификацию и отображение полей строк со знаком "=OS", используя шестнадцатеричную нотацию.

Если строка используется для имени, явные запросы удовлетворяются настоящим стандартом путем их логической увязки с другим типом данных "имя" поля строки, который ограничивает размер строки (см. 3.2.3.3). Например, идентификация пользователя выражается как

<имя уполномоченного = NA>

<идентификация пользователя = S>,

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

Длина строки не ограничена.

3.2.3.3 Типы данных "имя"

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

a) прикладные ЛО, содержащие специфический для ПОЗ сервисный элемент прикладного уровня (СЭП) (прикладной ЛО ПОЗ);

b) уполномоченные по идентификации пользователя;

c) типы документов.

Тип данных, идентифицирующий прикладной ЛО ПОЗ, отмечается знаком "=N". Тип данных, идентифицирующий уполномоченного по идентификации пользователя, отмечается знаком "=NA". Тип данных, идентифицирующий тип документа, отмечается знаком "=ND". Возможно, но не обязательно, для одного и того же имени указывать и прикладной ЛО ПОЗ и уполномоченного по идентификации пользователя.

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

Имена объектов типов в подпунктах а) и b) имеют форму и механизмы размещения, определенные для параметра "наименования - лоп" ВОС. Имена типа в подпункте с) имеют форму и механизмы размещения, определенные для типа данных ИДЕНТИФИКАТОР ОБЪЕКТА в ГОСТ 34.973.

3.2.3.4 Типы данных "ссылка"

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

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

3.2.3.5 Типы данных "документ"

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

a) определение семантики;

b) один или несколько синтаксисов передачи;

c) правила объединения документа с другими типами документов или с другими экземплярами того же типа.

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


Типы данных "документ" определены в настоящем стандарте (см. 3.5), в других стандартах, стандартах ИСО или Рекомендациях МККТТ или непосредственно в регистре типов документов ИСО. Все документы, передаваемые ПОЗ, имеют связанное с ними недвусмысленное имя (=ND), назначаемое при определении документа.

3.3 События ПОЗ и параметры отчетов

Категории событий, которые могут запросить, чтобы поставщик услуг ПОЗ сформировал отчеты, перечислены в 3.3.1. Параметры, содержащиеся в отчетах о событиях в каждой из категорий, перечислены в 3.3.2. Сводный перечень категорий событий и параметров событий приведен в таблице 1.


Таблица 1 - Сводный перечень категорий событий и параметров событий

3.3.1 Категории событий

Обработка СР вызывает одно или несколько элементарных действий, во время выполнения которых ответственность за продолжение работы может быть передана от одной открытой системы другой. Ответственность передается только при исполнении элементарного действия. Отчеты могут формироваться ГУЛО элементарного действия или открытой системой, первой обнаружившей возникновение события. Это определяется для каждого события. Если последующие определения указывают, что отчет должен быть сформирован как часть некоторого элементарного действия, ответвление элементарного действия формирует исполнение отчета только в том случае, если основное элементарное действие исполняет операцию; основное элементарное действие отклоняет исполнение, если отклоняется ответвление действия, формирующее отчет. Уровень исполнения отчета выбирается по обычным правилам. Если последующие определения указывают, что отчет выдается как отдельное элементарное действие, то уровень исполнения имеет значение 1, а успешное завершение или безуспешность двух действий являются независимыми.

Категории событий перечислены и определены ниже.

СОЗДАНИЕ - отчет должен быть сформирован той открытой системой, которая выдала примитив J-INITIATE, как часть этого элементарного действия.

ПЕРЕДАЧА - протокол ПОЗ работает при передаче между открытыми системами концептуальных структур данных (СР), определяющих остальные части задания ВОС; этот литерал требует, чтобы открытая система, принимающая ответственность за СР (то есть исполнение с уровнем ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА или ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА), формировала отчет как часть элементарного действия, передающего ответственность.

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

ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА - отчет должен быть сформирован той открытой системой, которая является ГУЛО элементарного действия, обрабатывающий СР, за которую она ответственна, когда уровень исполнения ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА (или больший) достигнут для всех ответвлений элементарного действия; он формируется как часть элементарного действия.

Примечание - Этот отчет не формируется, если все ответвления действия выполнены с уровнем исполнения ЗАВЕРШЕНИЕ, так как в этом случае формируется отчет о событии НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ.


НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ - отчет должен быть сформирован целевой открытой системой, которая обрабатывает СР, если все ответвления такого элементарного действия выполняют исполнение с уровнем ЗАВЕРШЕНИЕ; он формируется как часть элементарного действия; он также вырабатывается как часть элементарного действия примитива J-END-SIGNAL, когда СР сбрасывается после необходимого порождения; следует заметить, что отчеты о порождениях также могут формироваться как часть одного элементарного действия и что запрошенным минимальным уровнем исполнения для примитива J-END-SIGNAL всегда является ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА.

ЗАВЕРШЕНИЕ-ОБРАБОТКИ - отчет должен быть сформирован открытой системой, выполняющей обработку, если СР аннулируется операцией УНИЧТОЖИТЬ; он формируется как часть элементарного действия обработки.

МОДИФИКАЦИЯ - отчет должен быть сформирован открытой системой, выполняющей обработку, всякий раз, когда СР модифицируется операцией или приостанавливается операцией ОСТАНОВ; он формируется как часть элементарного действия обработки.

ДИАГНОСТИКА-ОШИБОК - отчет должен быть сформирован открытой системой всякий раз, когда указатель источника документа (см. 3.4.4.1.3) в СР заменяется диагностикой ошибок; он формируется как часть основного элементарного действия.

НЕ-ВЫПОЛНЯЕТСЯ - отчет должен быть сформирован, когда открытая система несет ответственность за СР и ГУЛО элементарного действия, пытающийся обработать ее, получает примитив индикации C-ROLLBACK или J-ROLLBACK с диагностикой HE-ПОВТОРЯТЬ и сохраняет СР; он также формируется, если продолжаются возвраты в исходное состояние с диагностикой ПОВТОРИТЬ-ПОЗЖЕ для PC, зависящей от времени; диагностика СИВ становится доступной в отчете, и СР сохраняется для корректирования при последующей модификации; этот отчет формируется как отдельное элементарное действие.

УЧЕТНЫЕ-ДАННЫЕ - отчет должен быть сформирован открытой системой всякий раз, когда становится доступной информация о затратах, относящихся к данному заданию ВОС; отчет формируется как отдельное элементарное действие той открытой системой, которая является ГУЛО элементарного действия, обрабатывающим СР, за которую она несет ответственность.

СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ - отчет должен быть сформирован открытой системой, когда активностью в исполняющем агентстве вводится примитив запроса J-MESSAGE; он формируется как часть элементарного действия примитива J-MESSAGE.

НЕ-ОБЕСПЕЧЕНО-ЗАВЕРШЕНИЕ - отчет должен быть сформирован открытой системой, ответственной за СР, и ГУЛО элементарного действия, если сложность подзадания превышает возможности обрабатывающей открытой системы; он формируется как отдельное элементарное действие, а СР уничтожается.

Примечание - Открытая система проверяет принятую в элементе передачи СР и отклоняет передачу, если она неприемлема; обычно отчет НЕ-ВЫПОЛНЯЕТСЯ формируется посылающим ЛО; событие НЕ-ОБЕСПЕЧЕНО-ЗАВЕРШЕНИЕ имеет место только в том случае, если проформа используется для порождения, которое превышает возможности порождающей системы.


АВАРИЙНОЕ ЗАВЕРШЕНИЕ - отчет должен быть сформирован всякий раз, когда открытая система несет ответственность за СР и ГУЛО элементарного действия, пытающийся обработать ее, принимает примитив J-ROLLBACK или C-ROLLBACK с диагностикой HE-ПОВТОРЯТЬ и уничтожает СР; он также формируется, если продолжаются возвраты в исходное состояние с диагностикой ПОВТОРИТЬ-ПОЗЖЕ для PC, зависящей от времени; диагностика СИВ становится доступной в отчете; этот отчет формируется как отдельное элементарное действие.

ПОПЫТКА-НАРУШЕНИЯ - отчет должен быть сформирован, если обрабатывающая СР пытается смодифицировать, ОТОБРАЗИТЬ, ОСТАНОВИТЬ или УНИЧТОЖИТЬ СР, но не содержит элемента полномочий, разрешающего эту операцию; он формируется как отдельное элементарное действие.

ПРЕДУПРЕЖДАЮЩЕЕ-УВЕДОМЛЕНИЕ - отчет должен быть сформирован, если во время успешного выполнения активности ПОЗ формируются предупреждения, относящиеся к результатам или действиям этой активности.

3.3.2 Отчеты

Отчет содержит следующую информацию:

Параметр <имя уведомителя> указывает открытую систему, формирующую <отчет>. Параметр <отметка времени> содержит дату и время формирования отчета в форме ОбщаяФормаЗаписиВремени по ГОСТ 34.973, если она доступна в открытой системе, в противном случае он равен НУЛЮ. Обеспечение параметра <отметка времени> является факультативным во всех PC ПОЗ.

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

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

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

Параметр <время инициирования> вводится поставщиком услуг ПОЗ при выдаче примитива J-INITIATE.

Параметр <имя задания ВОС> обеспечивается СП J-INITIATE и используется для идентификации полного задания ВОС. Не требуется, чтобы этот параметр имел разные значения в различных заданиях ВОС.

Параметр <локальный указатель задания ВОС> вводится поставщиком услуг ПОЗ (и выдается в примитиве ответа J-INITIATE). Он однозначно указывает задание ВОС в области, указанной параметром <система предоставления задания ВОС>.

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

Параметр <тип подзадания> определен в 3.4.3.3. Он указывает тип подзадания, о котором должен быть выдан отчет. Он никогда не может иметь значения ПЕРЕМЕЩЕНИЕ-ОТЧЕТА, если использовался как указано выше, поскольку в таких подзаданиях отчеты не формируются.

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

Параметр <параметры событий> обеспечивается, как показано в таблице 1 для каждого типа события.

К отчетам ДИАГНОСТИКА-ОШИБОК, АВАРИЙНОЕ-ЗАВЕРШЕНИЕ, НЕ ВЫПОЛНЯЕТСЯ и ПРЕДУПРЕЖДАЮЩИЙ-ОТЧЕТ относятся такие отчеты, которые содержат определенную диагностику (см. 3.3.3 для формы определенной диагностики). Строки <текст> используются в других случаях для переноса диагностической информации, и они не стандартизованы.

Строки параметра <текст> для события СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ образуются из примитива J-MESSAGE (см. 3.6.5).

Длина каждой строки <текст> ограничивается 40 знаками.

Параметр <список целевых систем> указывает параметры <целевая система> и <промежуточные системы> новой СР; он определен в 3.4.3. Параметр <число порождений> указывает число СР, порожденных из прежней СР.

Параметр <защищенные данные> определяется в 3.3.3.1 и представляет идентификацию СР, приводящей к событию ПОПЫТКА-НАРУШЕНИЯ. (Таким образом, поле <идентификация подзадания> в этом параметре отличается от одноименного поля в заголовке параметра <отчет>, представляющего собой СР, при выполнении которой была предпринята попытка нарушения). Для обнаружения маскирования параметр <защищенные данные> содержит копию проверочной трассы.

Параметр <состояние задержки> имеет значение УДЕРЖАНИЕ, если один или несколько элементов в списке удержаний препятствуют дальнейшему выполнению, в противном случае - значение НЕТ-УДЕРЖАНИЯ.

Параметр <сигнал останова> имеет значение ОСТАНОВЛЕНО, если модификация включала операцию ОСТАНОВ, в противном случае - значение МОДИФИЦИРОВАНО.

Примечание - Выполнение операции УНИЧТОЖИТЬ вызывает событие ЗАВЕРШЕНИЕ-ОБРАБОТКИ, а не МОДИФИКАЦИЯ.

3.3.3 Параметр "диагностическая информация"

Примечание - В названиях типов данных "пи" используются в качестве мнемоники "принимающее и исполняющее агентства".

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

Параметр <детали исходного агентства> идентифицирует подчиненный ЛО СИВ и некоторые параметры примитива J-GIVE, если он выполнил примитив J-ROLLBACK. Параметр <детали пи> идентифицирует подчиненный ЛО СИВ и некоторые параметры примитива J-DISPOSE. Параметр <получатель> идентифицирует другую открытую систему, если попытка передачи оказалась безуспешной. Параметр ПОСТАВЩИК идентифицирует прикладной ЛО ПОЗ как формирователя параметра <диагностическая информация>.

Параметр <диагностика СИВ> первоначально содержится в примитиве J-READY или C-READY (только для диагностики ПРЕДУПРЕЖДЕНИЕ) или в примитиве J-ROLLBACK или C-ROLLBACK для диагностики ПОВТОРИТЬ-ПОЗЖЕ или НЕ-ПОВТОРЯТЬ.

Параметр <диагностика СИВ> значения ПРЕДУПРЕЖДЕНИЕ встраивается в параметр <диагностическая информация> для формирования ПРЕДУПРЕЖДАЮЩИХ ОТЧЕТОВ.

Параметр <диагностика СИВ> значения HE-ПОВТОРЯТЬ встроена в параметр <диагностическая информация> для отчетов "аварийное-завершение", "не-выполняется" и "диагностика-ошибок".

Параметр <диагностика СИВ> значения ПОВТОРИТЬ-ПОЗЖЕ никогда не встраивается в параметр <диагностическая информация>, если только не произойдет повторенный возврат со значением "повторить-позже".

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

Параметр <результат ПДУФ> является структурой данных, способной содержать всю информацию, указанную в приложении D ГОСТ Р 34.1980.3, которая получена в результате выполнения попытки передачи, использующей ПДУФ.

Параметр <тайм-аут повторения> задает предполагаемую временную задержку перед повторением элементарного действия. Время равно 2** I с, где "I" - значение параметра <тайм-аут повторения>.

Параметр <причина> содержит одну или несколько строк <текст>. Каждая строка <текст> содержит от нуля до 40 знаков.

Примечание - Этот тип данных используется для читабельной части диагностики ПОЗ. Он должен быть выбран так, чтобы была возможность отображения диагностики, используя двумерное пространство шириной 40 знаков. Формирователь диагностики должен отметить такую назначенную модель отображения.

3.3.3.1 Параметр "защищенные данные"

Копируется из СР, пытающейся выполнить модификацию, которая вызвала событие ПОПЫТКА-НАРУШЕНИЯ.

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

3.3.3.2 Параметр "учетная информация"

Параметр <учетная информация> становится доступным локально или в результате попытки передачи примитива C-READY или C-ROLLBACK.

Он выдается к ГУЛО исполнения, используя механизмы СИВ, и затем в пункты монитора ПОЗ, используя механизмы уведомляющей службы.

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

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

3.4 Поля концептуальных структур данных

Вся активность ПОЗ управляется концептуальными структурами данных, которые называются СР.

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

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

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

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

Этот раздел определяет поля СР, список заголовков и концептуальную структуру данных ЗУП.

3.4.1 Спецификации работы

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

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

Значение НУЛЬ замещает значение поля <спецификация подзадания> только в том случае, если СР, указанная параметром <спецификация работы>, задерживается в ожидании примитива J-END-SIGNAL от принимающего или исполняющего агентства. Параметр <спецификация работы> никогда не передается в этой форме.

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

Поле <параметры действия ПОЗ> зависит от типа подзадания и подробно определяет действия открытых систем, которые предназначены для выполнения работы.

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

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

Поле <параметры активности агентства> представлено в концептуальной структуре данных, только в том случае, если принимающее или исполняющее агентство находится в состоянии выполнения активности относительно этого поля. Оно идентифицирует активность в агентстве для последующих примитивов J-KILL, J-HOLD, J-RELEASE или J-STATUS. В базовом классе имеется не больше одной активности агентства, связанной с СР.

Форма поля <параметры активности агентства> не определена, поскольку это поле имеет только локальную значимость. Оно используется в промежутке между примитивами J-DISPOSE и соответствующим примитивом J-END-SIGNAL для идентификации активности в агентстве, связанной с этой СР. Эти поля обеспечиваются агентством в примитиве ответа J-DISPOSE и используются во всех последующих взаимодействиях, относящихся к этой активности. Они отсутствуют в проформах.

Поле <время ожидания = I> содержит время в минутах, истекшее после того, как СР введена в состояние ожидания обработки поставщиком услуг ПОЗ. Она может находиться в состоянии ожидания передачи или выдачи примитивов J-GIVE или J-DISPOSE. Поле является нулевым, если СР не предполагает участия поставщика услуг, как например, если она находится в состоянии удержания или в состоянии ожидания примитива J-END-SIGNAL.

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

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

3.4.2 Параметры задания ВОС

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

Параметр <идентификация инициирования> обеспечивается пользователем ПОЗ и может использоваться при выборке СР последующей операцией обработки, и этот параметр присутствует при отображении и в отчетах. Форма этой идентификации определена в 3.3.2. Эта идентификация не является предметом аутентификации.

Параметр <время инициирования> вводится поставщиком услуг ПОЗ для указания времени предоставления.

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

Параметр <проверочная трасса> используется для определения источника обмена данными:

Отправитель вводит собственное имя открытой системы с литералом "НЕИЗВЕСТНЫЙ". Если получатель способен проверить это имя, используя механизмы справочника и доверительно отнестись к адресам у вызова более низкого уровня, значение НЕИЗВЕСТНЫЙ заменяется на ИЗВЕСТНЫЙ. Если положительная аутентификация была выполнена более низкими уровнями, значение НЕИЗВЕСТНЫЙ заменяется на АУТЕНТИФИЦИРОВАННЫЙ.

Примечания

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

2. Административное управление сетей общего пользования обычно обеспечивает некоторую гарантию точности адресов вызова, достаточную для нормальной коммерческой работы, и категорию ИЗВЕСТНЫЙ. Для локальных сетей такая гарантия может отсутствовать.


Использование проверочной трассы при установлении полномочия см. в 3.4.2.1.

Параметр <первичная контролирующая спецификация> вводится поставщиком услуг ПОЗ. Параметры <вторичная контролирующая спецификация> (при их наличии) получаются из примитива J-INITIATE.

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

Эти элементы обеспечиваются примитивом J-INIТIAТЕ, но поставщик услуг ПОЗ может время от времени добавлять дополнительные элементы, получаемые из уже существующих элементов (см. 3.4.2.1). В базовом классе параметр <учет> является пустым.

<Параметры защиты> определяют использование со стороны ПОЗ механизмов защиты нижерасположенного уровня при передаче СР. Он определяет также действие, выполняемое ПОЗ при повторном отклонении услуги. В данном издании настоящего стандарта, он имеет только значение "НЕТ", указывающее, что на более низких уровнях механизмы защиты для предотвращения раскрытия, обнаружения вмешательства не используются или используются только защищенные маршруты.

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


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

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

3.4.2.1 Полномочия и учет

Каждый параметр <элемент полномочий> идентифицирует или пользователя (использующего параметр <имя уполномоченного> и одну из введенных им идентификаций), или САУ открытой системы, или идентификационное полномочие (используя имя открытой системы или имя уполномоченного).

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

Идентификация с параметром <секретные данные> аутентифицируется (для использования указанной открытой системой в указанное время), если открытая система может иметь доступ к необходимой базе данных, чтобы проверить параметр <секретные данные>, и если проверка была успешной.

Идентификация с доступом <индекс проверки = I> аутентифицируется, если все поля <элемент проверки>, начиная от места, указанного индексом проверки, и кончая концом проверочной трассы (включительно), имеют удовлетворительную аутентификацию (НЕИЗВЕСТНЫЙ, ИЗВЕСТНЫЙ, АУТЕНТИФИЦИРОВАННЫЙ) и известны той открытой системе, которая доверяет ей. Эта форма поля проверки представляет собой защиту открытой системой, указанной индексом проверки, параметр <идентификация> которой был аутентифицирован ею.

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


Примитив J-INITIATE может обеспечивать элементы полномочий только с полями проверки, содержащими параметр <секретные данные>. Поставщик услуг ПОЗ добавляет элементы полномочий множества <индексов проверки> в следующих случаях:

a) всякий раз, когда проверяется поле <секретные данные>;

b) если во время выдачи примитива J-INITIATE аутентифицированный параметр <идентификация> инициатора становится известен поставщику услуг ПОЗ при помощи локальной функции САУ;

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

Параметр <идентификация инициирования> представляет собой требуемую идентификацию инициирующего ЛO, которая обеспечивается в примитиве J-INITIATE. PC ПОЗ не обязательно должна обладать способностью обнаруживать маскирование такого значения, используя локальные механизмы. С отчетами о попытке нарушения защиты передается также проверочная трасса.

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

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

Каждый параметр <элемент разрешения> позволяет другим подзаданиям выполнения работы вносить изменения в СР, содержащие элемент, предусмотренный только для того, чтобы подзадание обработки содержало допустимый <элемент полномочия> для параметра <идентификация>, предоставленный в параметре <элемент разрешения>, или, в случае параметра <пользователь> - для своей соответствующей САУ.

3.4.2.2 Селекторы отчетов

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

3.4.2.3 Спецификации монитора

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

Параметр <системное имя монитора> указывает открытую систему, в которую должны быть доставлены отчеты. Если значением параметра <инструкции размещения> является СОХРАНИТЬ, открытая система сохраняет отчеты (вместе с соответствующими параметрами задания ВОС) до тех пор, пока она не примет подходящую СР управления полномочным отчетом, требующую его отображения или удаления. Если параметр <данные размещения> присутствует, отчет передается в указанное принимающее агентство, используя группу примитивов J-DISPOSE с параметрами, полученными из параметра <данные размещения>.

Примечание - После завершения времени РС может удалить отчеты, которые она сохраняла.

3.4.3 Параметры подзадания ВОС

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

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

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

Параметр <тип подзадания> определяет природу подзадания и форму параметра <параметры действия ПОЗ>.

3.4.3.1 Срочность

<срочность> : : = (ВЫСОКАЯ | СРЕДНЯЯ | НИЗКАЯ)

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

3.4.3.2 Удержания

Параметр <элемент удержания> игнорируется открытой системой, если параметр <местоположение удержания> не содержит имя этой открытой системы. Если параметр <местоположение удержания> в одном или нескольких параметрах <элемент удержания> соответствует имени открытой системы, СР не будет обрабатываться открытой системой (передавать ее, вводить СП, или выполнять порождения из нее). Она может быть передана в пункт, указанный параметром <местоположение удержания> или может быть создана там при помощи порождения или примитива J-INITIATE.

Параметр <элемент удержания> представляется изначально (установлен примитивом J-INITIATE), добавляется позже при помощи выполнения работы или автоматически вводится, если обработка задерживается из-за ошибок (см. 2.1.6.2 и 3.4.3.4).

Если параметр <элемент удержания> был введен поставщиком услуг ПОЗ в качестве результата обнаружения ошибки в нем, то параметр <диагностическая информация> содержит детали ошибки, но в нем отсутствует параметр <причина>, а параметр <местоположение удержания> содержит имя открытой системы, вводящей параметр <элемент удержания>.

Если параметр <элемент удержания> был введен при обработке, то параметр <причина> содержит читабельный текст.

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

Параметр <время освобождения> указывает время, в которое поставщик услуг ПОЗ автоматически удаляет элемент удержания. (Следует заметить, что это вызывает появление события МОДИФИКАЦИЯ). PC может наложить ограничение на период времени, необходимый для своей подготовки к выполнению состояния удержания для СР. Параметр <дата-время> указывает, что элемент удержания должен быть удален в точно указанное абсолютное время. Параметр <время суток> представляется в форме чч. мм и указывает, что элемент удержания должен быть удален, когда это местное время впервые достигает своего значения после порождения подзадания из проформы, или когда СР достигнет заданной открытой системы. Параметр <временной интервал> преобразуется в значение <дата-время> при его наличии в поле <местоположение удержания> в подзадании верхнего уровня (то есть, когда СР достигает <местоположение удержания>), в проформе, содержащей порождение элемента удержания, или когда при выполнении работы элемент удержания добавляется к подзаданию верхнего уровня. Этот параметр указывает удаление элемента удержания, если значение параметра <временной интервал> в минутах преобразовано в значение <дата-время>.

3.4.3.3 Тип подзадания

Значение этого поля в параметре <параметры подзадания> примитива J-INITIATE фиксируется (для каждого примитива J-INITIATE) относительно значения, соответствующего имени СП. Оно определяет форму параметра <параметры действия ПОЗ>. Значение этого параметра в проформе не ограничивается примитивом J-INITIATE, используемым для указания задания ВОС, но не может принимать значения ПЕРЕМЕЩЕНИЕ-ОТЧЕТА.

3.4.3.4 Действия при ошибке

Параметр <действия при ошибке> управляет действием поставщика услуг ПОЗ в открытой системе, действующего в качестве ГУЛО исполнения операций при обработке СР. Действия описываются ниже.

3.4.3.4.1 Источники ошибок

ГУЛО инициирует одно или несколько ответвлений элементарного действия для:

a) доступа к исходным агентствам (которые, возможно, используют ПДУФ);

b) доступа к принимающим агентствам (которые, возможно, используют ПДУФ);

c) передачи СР (возможно, сформированной в результате порождения).

Одно или несколько этих ответвлений выполнить возврат в исходное состояние из управляемого ЛО с диагностикой СИВ. Последующее действие, выполняемое ГУЛО, определяется параметром <действия при ошибке>.

Примечание - Возврат в исходное состояние примитива J-GIVE исходным агентством может привести к ошибке в таком ответвлении элементарного действия в зависимости от установки параметра <встроенная диагностика> в поле <указатель источника документа> (см. 3.4.4.1.3).

3.4.3.4.2 Действие УДЕРЖАНИЕ

Значение "УДЕРЖАНИЕ <временной интервал>" вызывает действие, по которому поставщик услуг ПОЗ (при наличии ошибки):

a) модифицирует параметр <действия по ошибке> в значение ЗАВЕРШИТЬ;

b) добавляет параметр <элемент удержания> для текущего местоположения с параметром <диагностическая информация>, взятого из диагностики СИВ, значение "НУЛЬ <разрешение освобождения>" и параметр <время освобождения>, вычисленный из текущего времени плюс значение параметра <временной интервал>;

c) формирует любые требующиеся отчеты для события "НЕ-ВЫПОЛНЯЕТСЯ".

3.4.3.4.3 Действие ЗАВЕРШИТЬ

Значение ЗАВЕРШИТЬ вызывает действие, по которому поставщик услуг ПОЗ:

a) удаляет СР;

b) формирует любые требующиеся отчеты для события "АВАРИЙНОЕ ЗАВЕРШЕНИЕ".

3.4.4 Параметры действия ПОЗ

Если поле <тип подзадания> имеет значение ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА, то этот параметр содержит <операции перемещения документов>.

Если поле <тип подзадания> имеет значение ВЫПОЛНЕНИЕ-РАБОТЫ, то этот параметр содержит <операции выполнения работы>.

Если поле <тип подзадания> имеет значение ОБРАБОТКА-ЗУП, то этот параметр содержит <операции управления передачами>.

Если поле <тип подзадания> имеет значение УПРАВЛЕНИЕ-ОТЧЕТОМ, то этот параметр содержит <операции управления отчетами>.

Если поле <тип подзадания> имеет значение ПЕРЕМЕЩЕНИЕ-ОТЧЕТА, то этот параметр содержит <операции перемещения отчета>.

3.4.4.1 Операции перемещения документов

Примечания

1 Все поля <идентификация пи> в списке имеют значение <пи ПОЗ> или <пи ПДУФ>. Произвольное расположение в одном блоке документа не обеспечивается.

2 Если используется параметр <групповая форма>, параметр <идентификация пи> имеет форму <пи ПОЗ>.

Каждый параметр <идентификация пи> идентифицирует принимающее или исполняющее агентство.

По каждому параметру <единичная форма> формируется (с использованием одного или нескольких примитивов J-GIVE) один документ (возможно со встроенной диагностикой - см. 3.4.4.1.3) для размещения целевой системой, возможно, как результат объединения нескольких документов, полученных из исходных агентств. По каждому параметру <групповая форма> либо не формируется, либо формируется один или несколько документов для размещения, каждый с отдельным сочетанием параметров <одна форма> <блок документа>. Все документы, перемещаемые одной операцией <перемещение документа>, имеют один и тот же тип документа. Таким образом, одна операция <перемещение документа> обеспечивает:

a) перемещение нескольких объединенных документов и возможное дублирование результата (использование параметра <единичная форма>);

b) перемещение множества документов, возможно, с их дублированием (использование параметра <групповая форма>).

При обработке целевой системой каждой операции <перемещение документа> принимаются все документы, описанные параметром <блок документа>, и передается каждый из них всем агентствам, указанным параметром <пи агентства>, отдельной группой примитивов J-DISPOSE для каждого документа.

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

Операции <перемещение документа> выполняются целевой системой в порядке поступления всех примитивов индикации J-DISPOSE для одного параметра до принятия какого-либо примитива индикации J-DISPOSE для следующей операции. Порядок примитивов индикации J-DISPOSE при выполнении одной операции <перемещение документа> не определен. Результаты перемещений документов становятся доступны для других элементарных действий только после исполнения. Они становятся доступны в других частях одного и того же элементарного действия во время выдачи примитива индикации J-DISPOSE.

3.4.4.1.1 Идентификация принимающего и исполняющего агентства

Имеются две формы параметра <идентификация пи>. Первая - <пи ПОЗ> используется для принимающих и исполняющих агентств, которые размещают документ локально или удаленно нестандартным способом. Вторая - <принимающее агентство ПДУФ> - используется для идентификации локального принимающего агентства, которое размещает документ (локально или удаленно), используя ГОСТ Р 34.1980.3.

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

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

<Параметр агентства> передается в примитиве J-DISPOSE и используется (вместе с параметром <тип документа>) принимающим или исполняющим агентством для определения пути, по которому документ должен быть представлен, сохранен или интерпретирован. Если значение параметра СОХРАНИТЬ обеспечивается комбинированным принимающим и исполняющим агентством, агентство запоминает документ таким образом, чтобы любой последующий примитив J-GIVE, ссылающийся на такой же параметр <тип документа> и параметр <параметр агентства> вместе с соответствующим параметром <указатель источника документа>, приводил к формированию идентичного документа.

Примечание - Значение СОХРАНИТЬ не относится к исполняющему агентству.


Если параметр указывает НУЛЬ, документ сохраняется или предоставляется локальным способом. Если параметр указывает <формат агентства>, принимающее или исполняющее агентство использует его для определения способа сохранения материала, представления или интерпретации. Возможные значения строки <формат агентства> не стандартизованы и определяются агентством.

Параметр <метка активности агентства> позволяет определить однозначную логическую связь между примитивом J-DISPOSE, выдаваемым исполняющему агентству, и последующим примитивом J-GIVE (из порождаемой проформы), выдаваемым этому агентству. Это необходимо только в том случае, если одной СР инициируется более одной активности в агентстве.

Имена <префикс пи> помещаются в начале списка имен <указатель пи документа> (см. ниже) для каждого документа при формировании параметров, передаваемых в примитиве J-DISPOSE. Этот параметр представляет собой начальную часть поля <список-имен> в примитиве J-DISPOSE, которая должна отличаться для каждого из принимающих и исполняющих агентств в операции <перемещение документа>.

<Имя-хранилища-файлов> в форме <принимающее агентство ПДУФ> идентифицирует (локальное или удаленное) виртуальное хранилище файлов ПДУФ, которое должно принять документ. Вся другая информация по размещению содержится в параметре <указатель пи документа> (см. 3.4.4.1.2).

3.4.4.1.2 Блоки документа единичной формы

Примечание - Форма <ПДУФ писать-данные ПДУФ> используется только в том случае, если соответствующие параметры <идентификация пи> имеют форму <принимающее агентство ПДУФ>.

Эта форма параметра <блок документа> указывает, что документы, которые указаны в параметрах <указатель документа>, должны быть объединены (в порядке ссылок в блоке документа) для формирования одного документа при размещении при помощи примитива J-DISPOSE.

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

Примечание - Этот параметр игнорируется исполняющим агентством.


Он передается как поле параметра примитива J-DISPOSE. Литералы могут иметь следующие значения:

НОРМАЛЬНЫЙ - перезаписать какие-либо старые документы с тем же именем или создать новый документ в принимающем агентстве;

НОВЫЙ - создать новый документ в принимающем агентстве, если возможно, но если старый документ существует с таким же именем, вернуться в исходное состояние с выдачей диагностики;

СТАРЫЙ - перезаписать старый документ с тем же именем, но если старый документ не существует, вернуться в исходное состояние с выдачей диагностики;

ДОБАВИТЬ В КОНЕЦ - добавить в конец какого-либо прежнего документа, но если прежний документ не существует, вернуться в исходное состояние с выдачей диагностики;

ДОБАВИТЬ - добавить в конец какого-либо прежнего документа и, если прежний документ не существует, создать новый документ.

В начало значения <список-имен> добавляется <префикс пи> (см. 3.4.4.1.1) и затем формируется значение <список-имен>, передаваемое в примитиве J-DISPOSE в принимающее или исполняющее агентство для идентификации документа.

Литерал ВЛОЖЕННЫЙ указывает документ в <списке документов>. Количество документов в этом списке равно общему количеству имеющихся литералов ВЛОЖЕННЫЙ в СР (включая проформы). Между позициями в <списке документов> и синтаксисом передачи СР имеется определенное соответствие.

Если обеспечивается значение <ПДУФ писать-данные>, принимающее агентство использует услуги ГОСТ Р 34.1980.3 (ПДУФ) для размещения документа в локальном или удаленном хранилище файлов, как определено в ГОСТ Р 34.1980.3.

Параметр <указатель единичного документа> требует включения документа, который должен быть получен при помощи примитива J-GIVE или ПДУФ. Это выполняется поставщиком услуг ПОЗ в форме ВЛОЖЕННЫЙ или вводится диагностика ошибок.

3.4.4.1.3 Указатели единичного документа и идентификация источника

Примечание - Форма <ПДУФ читать-данные ПДУФ> используется только и том случае, если <идентификация исходного агентства> имеет форму <исходное агентство ПДУФ>.

Параметр <действие открытой системы> указывает имя открытой системы, которая должна ввести примитив индикации J-GIVE (который может включить использование ПДУФ для получения документа). Он указывает открытую систему, создающую СР (порождением или в результате обработки примитива J-INITIATE), целевую систему или одну из промежуточных систем.

Параметр <идентификация исходного агентства> имеет значение ПОСТАВЩИК, только в том случае, если указатель содержится в проформе, которая порождена в результате выполнения работы, управления передачами или отчетами. Он используется, чтобы указать документы, изготовленные поставщиком услуг в результате выполнения команды отображения.

Параметр <идентификация исходного агентства> имеет форму <исходное агентство ПОЗ> для исходных агентств, которые получают документ локально или нестандартным удаленным способом доступа. Форма <исходное агентство ПДУФ> определяет локальное исходное агентство, которое получает документ (локально или удаленно), используя ГОСТ Р 34.1980.3.

Параметр <имя исходного агентства> является строкой, определяемой параметром <открытая система действия> для явной идентификации исходного агентства (внутри такой открытой системы), для которого должен быть введен примитив J-GIVE, чтобы получить документ.

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

Параметр <дополнительные полномочия> выполняет те же функции, которые служат для доступа к принимающим или исходным агентствам,

<Параметр доступа к исходному агентству> передается как одно из нолей в примитиве J-GIVE; если он имеет значение КОПИРОВАТЬ, исходное агентство не подвергается воздействию активности, если - значение ПEPEMЕСТИТЬ, документ помечается для удаления из исходного агентства при исполнении операций и остается неизменным при возврате в исходное состояние. Если этому исходному агентству доступны совмещенные активности (часть одного и того же элементарного действия), документ удаляется (если для какого-либо из них была совершена операция перемещения) при последующем исполнении или при возврате каждого из действий в исходное состояние.

<Список имен> передается в примитиве J-GIVE и идентифицирует указанный документ. Он указывает только один документ; если он отсутствует, то агентство, в которое был выдан примитив J-GIVE, возвращается в исходное состояние с диагностикой.

Параметр <имя-хранилища-файлов> в форме <исходное агентство ПДУФ> идентифицирует (локальное или удаленное) виртуальное хранилище файлов ПДУФ, которое должно обеспечить документ. Вся другая информация, необходимая для получения документа, обеспечивается параметром <ПДУФ читать-данные>.

Следует заметить, что при разрешении указателя единичного документа с использованием примитива J-GIVE обеспечивается также <тип документа> операции <перемещение документа>.

Параметр <встроенная диагностика> указывает действие, которое должно быть предпринято системой <открытая система действия>, если примитив J-GIVE подвергается операции возврата с диагностикой или если значением параметра <идентификация исходного агентства> является ПОСТАВЩИК, а указанный документ недоступен.

Значение ВЛОЖИТЬ требует, чтобы начальное значение НЕТ ПОПЫТКИ поля <состояние> было изменено на БЕЗУСПЕШНОСТЬ. Поле <отметка времени> содержит время безуспешного выполнения примитива J-GIVE, а диагностика примитива J-ROLLBACK помещается в поле <диагностика СИВ>. Обработка указателя документа предшествует предложению исполнения - возврат в исходное состояние из агентства недоступен ГУЛО. Если основное действие предшествует исполнению, выполняется переход в <состояние>. Если это действие возвращается в первоначальное состояние (по другим причинам), то <состояние> возвращается в первоначальное. Это действие формирует событие ДИАГНОСТИКА, которое может быть выбрано для службы отчетности.

Значение ОШИБКА вызывает установку параметра <состояние> в значение НЕТ ПОПЫТКИ и распространяет возврат и диагностику вверх по дереву элементарных действий к ГУЛО. Последующее действие определяется значением поля <действие при ошибке> для полного подзадания (см. 3.4.3.4).

3.4.4.1.4 Блоки документов групповой формы

Поля <действие открытой системы>, <исходное агентство ПОЗ>, <дополнительные полномочия>, <встроенная диагностика>, <параметр доступа к пи> и <параметр доступа к исходному агентству> определены в 3.4.4.1.2 и 3.4.4.1.3.

Блок документов групповой формы используется для формирования одного или нескольких блоков документов единичной формы, каждый из которых содержит значение ВЛОЖЕННЫЙ параметра <указатель документа>.

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

Документы принимаются системой <действие открытой системы> из исходного агентства, указанного параметром <идентификация исходного агентства>. Все они имеют один и тот же <тип документа>, указанный для операции <перемещение документа>. Параметр <указатель документа исходного агентства> для примитива J-GIVE для получения каждого документа формируется из полей <структура документа исходного агентства> добавлением имен (достаточного количества) в конец списка <частичный список-имен>. Это достаточное количество обеспечивается примитивом J-ENQUIRE.

Блок документа групповой формы обрабатывается системой <действие открытой системы>, при первой выдаче примитива J-ENQUIRE в исходное агентство путем передачи параметров <тип документа>, <структура документа исходного агентства> и <селектор документа>. Она выдает список суффиксов (список-имен) по одному имя для каждого документа, который должен быть доступен. Каждый из этих суффиксов (список имен) добавляется к списку <частичный список-имен> в параметре <структура пи документа> и <структура документа исходного агентства>, как определено выше. Множество списков (список-имен), выдаваемого примитивом J-ENQUIRE, является максимальным набором, для которого в результате выполнения примитивов J-GIVE могут быть сформированы документы в зависимости от использования параметров <селектор документа> и <тип документа>. Семантика параметра <локальная строка> не стандартизована. Значение НУЛЬ для параметра <селектор документа> означает максимальный выбор.

Примечание - В настоящее время ПДУФ не обеспечивает средств, необходимых для примитива J-ENQUIRE, поэтому блоки документов групповой формы ограничены локальным доступом.


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

a) <частичный список-имен>;

b) <тип документа>;

c) <параметр агентства>;

d) <параметр доступа к исходному агентству>;

e) <пароль> из параметра <дополнительные полномочия>;

f) <селектор документа>.

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

3.4.4.2 Операции выполнения работы

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

Операции УНИЧТОЖЕНИЕ, ОСТАНОВ и МОДИФИКАЦИЯ могут привести к тому, что поставщик услуг ПОЗ вводит примитивы индикации J-KILL, J-STOP, J-HOLD или J-RELEASE для соответствующих агентств, а операция ОТОБРАЖЕНИЕ приводит к выдаче примитива индикации J-STATUS для соответствующих агентств.

Операция ВЫБОР выбирает одну или несколько СР или проформ для последующих операций. Она выполняет это тестированием значения полей в СР, используя литералы ПОЗ для указания подлежащих тестированию полей. Выбранные СР или проформы используются последующими операциями УНИЧТОЖЕНИЕ, ОСТАНОВ, МОДИФИКАЦИЯ и ОТОБРАЖЕНИЕ. Выбор действует до тех пор, пока не будет введена следующая операция ВЫБОР.

Операция УНИЧТОЖЕНИЕ приводит к появлению события ЗАВЕРШЕНИЕ-ОБРАБОТКИ подзаданий и предотвращает порождение в конце уничтожаемой активности. Она вырабатывает примитив J-KILL или J-ROLLBACK для любого соответствующего агентства, возвращает в исходное состояние любую активность передачи и уничтожает соответствующую СР.

Операция ОСТАНОВ также приводит к выдаче примитива индикации J-STOP или J-ROLLBACK для соответствующих агентств, но не предотвращает порождение в конце активности и не приводит к завершению СР. Операция ОСТАНОВ возвращает в исходное состояние любую повторную попытку активности. Использование операции ОСТАНОВ указывается в любом сформированном отчете МОДИФИКАЦИЯ.

Операция МОДИФИКАЦИЯ вызывает изменения, которые должны быть выполнены для выбранной СР или проформы. Значение <обновление> вызывает изменения указанных полей; если изменяется поле <задержка>, результатом можем быть выдача примитива индикации J-HOLD или J-RELEASE. Изменения в поле "состояние-удержания" отмечаются в любом сформированном отчете МОДИФИКАЦИЯ.

Операция ОТОБРАЖЕНИЕ вызывает копирование данных из выбранной СР или проформы вместе с информацией из примитива J-STATUS, которое должно быть выполнено, как часть документа <документ отображения работы> с именем <имя-док>. Поле <документ отображения работы> определено в 3.5.2.

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

Следующие аутентифицированные параметры <идентификация> допускаются для модификации СР:

a) <идентификация>, который появляется в поле <разрешение> СР;

b) уполномоченный по идентификации, один из параметров которого <идентификация> имеется в поле <разрешения> СР;

c) открытая система, имя которой представлено как <целевая система> или <промежуточная система> для СР или ее проформ, или имя которой представлено в параметре <проверочная трасса> этой СР.

Кроме этого, удаление элемента <элемент задержки> или <элемент разрешения> может быть выполнено только при допустимом равенстве поля <идентификация> полю, представленному в <элементе удержания> (при его наличии) или <элементе разрешения>, или относящимся к нему, как указано в подпункте b). Если <элемент удержания> не содержит <разрешения освобождения>, то такое дополнительное ограничение не применяется.

После операции ''ОТОБРАЖЕНИЕ <имя-док>" документ типа <документ отображения работы> является доступным для сборки при помощи ссылки на параметр <идентификация исходного агентства> со значением ПОСТАВЩИК и на параметр <список-имен>, содержащим только поле <имя-док>. Две операции отображения с одним и тем же значением <имя-док> выполняют оба отображения работы в одном и том же документе. Отображение может быть полным или кратким, как определено в 3.5.2.

3.4.4.2.1 Селекторы

Параметр <селектор> содержит серии тестов, применяемых для концептуальной структуры данных, называемых "список заголовков", который содержит поля, соответствующие СР и ее проформам.

Поля этой структуры данных определены в 3.4.6.

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

Параметр <тест поля> применяется к поименованному полю в параметре <заголовок> и вызывает формирование значения УСПЕШНО или БЕЗУСПЕШНО. Значение параметров <тест поля> комбинируется операторами И, ИЛИ, HЕТ для получения значения УСПЕШНО или БЕЗУСПЕШНО для теста <тест заголовка>.

Проформа выбирается формой ЗАГОЛОВОК-ИМЕЕТСЯ только в том случае, если <тест заголовка> вызывает формирование значения УСПЕШНО при применении этого теста к заголовку, соответствующему данной проформе.

Форма СОДЕРЖИТ-ЗАГОЛОВОК выбирает СР, которые содержат, по крайней мере, одну проформу (на любой глубине), соответствующую параметру <заголовок>, для которого успешно выполняется <тест заголовка>. Форма НЕ-СОДЕРЖИТ-ЗАГОЛОВКА вызывает выбор СР, для которых <тест заголовка> выполняется со сбоем для всех значений <заголовок>, соответствующих проформам в нем. Форма ПЕРВЫЙ-ЗАГОЛОВОК-ИМЕЕТСЯ вызывает выбор СР, для которых успешно выполняется <тест заголовка> для заголовка, соответствующего самой СР.

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

3.4.4.2.2 Операторы выбора

Значение БОЛЬШЕ ЧЕМ, БОЛЬШЕ ИЛИ РАВНО, МЕНЬШЕ ЧЕМ и МЕНЬШЕ ИЛИ РАВНО параметра <оператор выбора> используется только с полями, которые являются цельночисленными элементами (ОБЩИЙ-РАЗМЕР и ВРЕМЯ-ОЖИДАНИЯ) (см. 3.4.6).

Значение РАВНО параметра <оператор выбора> может применяться к любому типу поля. Тестирование будет выполняться успешно только в том случае, если значение параметра <значение выбора> равно по типу и по значению этому полю (см. 3.4.4.2.3).

Три других значения параметра <оператор выбора> применяются к спискам; СОДЕРЖИМОЕ-СПИСКА может также применяться к совокупности. Тестирование выполняется успешно только в том случае, если <значение селектора> будет такого же типа, как и элемент поля <заголовок>, и будет соответствовать любому, первому или последнему элементу в списке.

В 3.4.6 определены операторы, которые могут быть применены к каждому полю заголовка.

3.4.4.2.3 Значения выбора

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

Для каждого синтаксического элемента (базового или структурированного типа данных) в поле <заголовок> литерал ЛЮБОЙ-ЭЛЕМЕНT может использоваться в поле <значение выбора> вместо синтаксического элемента соответствующего типа. Это соответствует любому синтаксическому элементу любого типа.

3.4.4.2.4 Обновления

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

3.4.4.2.5 Операторы обновления

<оператор обновления> : : = (УСТАНОВИТЬ-В | УДАЛИТЬ | ДОБАВИТЬ)

Значения УДАЛИТЬ и ДОБАВИТЬ применяются только к совокупностям. Значение УСТАНОВИТЬ-В может применяться для любого типа поля. Операторы, которые могут применяться для каждого поля <заголовок>, приведены в 3.4.6.

3.4.4.2.6 Значения обновлений

Эти значения относятся к тому же типу, что и поле <заголовок>, соответствующее <имени-поля>, за исключением значений УДАЛИТЬ и ДОБАВИТЬ, когда они относятся к тому же типу, что и элемент поля заголовка. Если элемент добавляется к совокупности, которая уже содержит элемент, равный такому значению, совокупность не изменяется.

3.4.4.2.7 Имена полей

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

3.4.4.3 Операции управления передачами

Операция УСТАНОВКА устанавливает параметр <запись управления передачей> (см. 3.4.7) в указанное значение. Она обычно вызывается САУ той стороны, которая знает, что она является постоянным получателем СР некоторой другой стороны, и желает управлять такими передачами. Она выполняет это, установив ЗУП на передающей стороне. СР должна иметь уполномоченного по <идентификации> открытой системы, указанной в полях <получатель> и <установить системой>. Поле <установить системой> используется только для того, чтобы определить ту открытую систему, в которую должна быть послана последующая операция ПРОВЕРКА. Поле <установить системой> содержит имя открытой системы, САУ которой была определена так, чтобы конкретный путь передачи был управляемым. Обычно оно должно быть идентично полю <получатель>, но может и отличаться от него. Поле <получатель> содержит имя такой открытой системы, передачи к которой должны быть управляемыми. Эта операция устанавливает параметр <управляющая спецификация> для управления передачами к системе <получатель>.

Операция ПРОВЕРКА обеспечивает данные (<получатель> и <управляющая спецификация> при использовании в открытой системе, указанной параметром <проверить системой>, и запрашивает открытую систсму, в которую операция ПРОВЕРКА посылается для того, чтобы создать СР управления передачами, если конкретное значение данных больше не пригодно. Эта операция предохраняет от бесконечно долгого использования несоответствующих ЗУП.

Примечание - Рекомендуется, чтобы открытые системы посылали запрос на выполнение операции ПРОВЕРКА в открытую систему, указанную параметром <установить системой>, если они были отсоединены от функциональной среды открытых систем на некоторое время.


Операция ПРОВЕРКА требует наличия уполномоченного по <идентификации> открытой системы, указанной параметром <проверить системой>.

Операция ОТОБРАЖЕНИЕ передачи формирует параметр <документ отображения передачи> (см. 3.5.3), содержащий копию полей <управляющая спецификация> и <установить системой> для указанного значения <получатель>. Использование значения ВСЕ отображает ЗУП для всех элементов <получатель>, не имеющих значения НЕУПРАВЛЯЕМЫЙ (см. 3.4.7).

3.4.4.4 Операции управления отчетами

Параметр <выбор отчета> указывают все имеющиеся отчеты из подзаданий (или порожденных подзаданий):

a) <система предоставления задания ВОС> (если обеспечивается);

b) <локальный указатель задания ВОС> (если обеспечивается);

c) <идентификация инициирования> (если обеспечивается);

d) <имя задания ВОС> (если обеспечивается);

е) <имя проформы> и <классифицированное целое число> (если обеспечивается);

f) <тип подзадания> (если обеспечивается);

g) тип события, который указан в параметре <селектор отчетов> (если обеспечивается);

h) <время инициирования> между <временем начала> и <временем завершения> (если обеспечивается <ограничение времени инициирования>).

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

Уведомление, в котором <время начала> равно НУЛЮ, включается параметром <ограничение времени-инициирования> только в том случае, если одно из значений <время начала> и <время завершения> равно НУЛЮ.

3.4.4.5 Операции перемещения отчета

<операции перемещения отчетов> : : = [<операция отчета>]*С

<операция отчета>: : = [<индекс монитора= I>]*С

<отчет> (см. 3.3.2)

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

3.4.5 Проформы

<проформа> : : =

<имя проформы = S>

<данные управления порождением> (см. 3.4.5.2)

[<обработка запроса порождения>]*С

(<указатель проформы> | (см. 3.4.5.1)

<спецификация проформы>)

<число порождений = I>

<спецификация проформы> : : =

<спецификация подзадания> (см. 3.4.1)

<список проформ> (см. 3.4.1)

В базовом классе содержимое поля <список проформ> в параметре <спецификация проформы> полностью прозрачно и на него не налагаются ограничения базового класса.

Поля параметра <проформа> такие же, как и поля проформы верхнего уровня, определенные в 3.4.1. Они определяют параметры для подзадания, которое должно быть создано при порождении проформы.

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

Параметр <число порождений> содержит счетчик СР, порождаемых из этой проформы. Поскольку порождение происходит только в целевой системе, этот параметр неявно обнуляется во время передачи. Это используется для формирования параметра <список имен подзаданий> при порождении новой СР из проформы.

Строки <обработка запроса порождения> указывают, должна ли проформа порождаться группой СП J-SPAWN. Проформа порождается, если параметр <обработка запроса порождения> примитива запроса J-SPAWN равен одной из строк в комбинации <обработка запроса порождения> проформы. Если комбинация <обработка запроса порождения> пустая или отсутствует, проформа не может быть порождена запросом.

3.4.5.1 Указатели проформы

<указатель проформы> : : = <имя проформы = S> (см. 3.4.5)

Это поле используется для указания параметра <спецификация подзадания> в поименованной проформе, указанной параметром <проформа>. Требуется, чтобы эта <проформа> находилась в том же списке <список проформ>, что и порождающая <проформа>; она сама может быть порождающей. Когда происходит порождение, то в проформах верхнего уровня в новой СР параметр <указатель проформы> заменяется параметром <спецификация подзадания> в этой поименованной проформе, указанной параметром <проформа>. (Следует заметить, что сюда может относиться проформа, содержащая параметр <указатель проформы>).

3.4.5.2. Данные управления порождением

<данные управления порождением> : : =

(ТОЛЬКО ЗАПРОС | ПРИНЯТИЕ | ЗАВЕРШЕНИЕ | УСЛОВНЫЙ)

Это поле указывает, когда должно происходить порождение из проформы, указанной параметром <проформа>.

Если оно имеет значение ТОЛЬКО ЗАПРОС, порождение происходит только при введении группы СП J-SPAWN из активности в исполняющем агентстве, выполняемой порождающим подзаданием.

Если оно указывает значение ПРИНЯТИЕ, порождение происходит, когда все принимающие и исполняющие агентства порождающего подзадания заданы с уровнем исполнения операций ПРИНЯТИЕ или ЗАВЕРШЕНИЕ.

Если оно указывает значение ЗАВЕРШЕНИЕ, подзадание создается, только в том случае, если все принимающие или исполняющие агентства порождающего подзадания заданы уровнем исполнения операция ЗАВЕРШЕНИЕ или когда введен примитив запроса J-END-SIGNAL.

Если оно указывает значение УСЛОВНЫЙ, подзадание создается как для значения ЗАВЕРШЕНИЕ, но только если по решению указателя исходного агентства последующее порождение собирает, по крайней мере, один документ из исполняющего или исходного агентства в данной открытой системе.

Примечание - Эта возможность предусматривается для обеспечения ситуации, когда обработка может выдать несколько выходных данных для различных адресатов, но также может выдать и меньшее количество данных, чем требуется. Использование значения УСЛОВНЫЙ гарантирует, что проформы порождаются только для таких адресатов, для которых выходные данные были действительно выработаны.

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

Уровень исполнения для запрошенного порождения указывается в примитиве запроса J-SPAWN. Для всех других порождений используется уровень ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА, если порождение не является частью начального элементарного действия.

Если в результате одного события должны быть порождены несколько проформ (например, по примитиву запроса J-END-SIGNAL), они порождаются в порядке их появления в списке <список проформ>.

Любые примитивы J-GIVE, которые должны быть введены из локальной области в агентство, выполняющее порождение, должны предшествовать предложению исполнения до порождения следующей проформы. (Это гарантирует, что операция ПЕРЕМЕЩЕНИЕ, допускаемая некоторыми проформами для объединения поименованных документов, и последующее порождение проформы со значением УСЛОВНЫЙ для объединения всех оставшихся документов, будет продолжаться правильно).

3.4.6 Списки заголовков

Эти поля соответствуют полям в СР или проформе. Изменение полей в списке <список заголовков> изменяет соответствующую СР или проформу.

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

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


Значение <пароль> в параметре <указатель пи документа> и значение <секретные данные> в поле <поле доступа> <элемента полномочий> или <элемента учета> всегда появляется как элемент НУЛЬ в поле <заголовок>.

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

* <система предоставления задания ВОС> - см. 3.3.2. Может применяться только значение РАВНО.

* <идентификации инициирования> - см. 3.3.2. Может применяться только значение РАВНО.

* <имя задания ВОС> - см. 3.3.2. Может применяться только значение РАВНО.

* <локальный указатель задания ВОС> - см. 3.3.2. Может применяться только значение РАВНО.

* <проверочная трасса> - см. 3.4.2. Операции РАВНО, СОДЕРЖИМОЕ-СПИСКА, ПЕРВЫЙ-ИЗ-СПИСКА-ИМЕЕТСЯ, ПОСЛЕДНИЙ-ИЗ-СПИСКА-ИМЕЕТСЯ.

* <первичная контролирующая спецификация> - см. 3.4.2. Операции РАВНО и УСТАНОВИТЬ-В. Значение УСТАНОВИТЬ-В требует наличия полномочий для параметра <идентификация> системы предоставления задания ВОС.

* <вторичная контролирующая спецификация> - см. 3.4.2. Операции РАВНО, СОДЕРЖИМОЕ-СПИСКА, УСТАНОВИТЬ-В, УДАЛЕНИЕ и ДОБАВЛЕНИЕ. В случае СР отчетов разрешенными операциями являются только РАВНО и СОДЕРЖИМОЕ-СПИСКА.

* <полномочия> - см. 3.4.2. (Следует заметить, что все <секретные данные> в полях <поле доступа> появляются как значение НУЛЬ в полях <заголовок>). Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА и ДОБАВЛЕНИЕ. (Параметр <доступ>, содержащий проверяемый индекс, не может появиться в операции ДОБАВЛЕНИЕ).

* <разрешения> - см. 3.4.2. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, ДОБАВЛЕНИЕ, УДАЛЕНИЕ. Операция УДАЛЕНИЕ требует наличия полномочий на удаление.

* <учет> - см. 3.4.2. (Следует заметить, что <секретные данные> в полях <поле доступа> представлены как значение НУЛЬ в полях <заголовок>). Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА и ДОБАВЛЕНИЕ.. (Параметр <доступ>, содержащий проверяемый индекс, не может иметь место в операции ДОБАВЛЕНИЕ).

* <параметры защиты> - см. 3.4.2. Может применяться только значение РАВНО.

<список имен подзаданий> - см. 3.4.3 для первого заголовка. В заголовке для проформы это поле имеет ряд компонентов имен подзаданий, по одному компоненту для каждого имени проформы, используемого для доступа к ней. Первым компонентом является имя проформы верхнего уровня примитива запроса J-INITIATE, последней - имя данной проформы. Значением параметра <классификационное целое число> является НУЛЬ, если спецификация подзадания все еще находится в виде проформы. Могут применяться только операции РАВНО и ПЕРВЫЙ-ИЗ-СПИСКА-ИМЕЕТСЯ.

<промежуточные системы> - см. 3.4.3. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, ПЕРВЫЙ-ИЗ-СПИСКА-ИМЕЕТСЯ, ПОСЛЕДНИЙ-ИЗ-СПИСКА-ИМЕЕТСЯ, УСТАНОВКА-В.

<целевая система> - см. 3.4.3. Операциями являются РАВНО и УСТАНОНКА-В.

<срочность> - см. 3.4.3.1. Операциями являются РАВНО и УСТАНОВКА-В. Операция УСТАНОВКА-В требует аутентифицированного параметра <идентификация>, равного системе предоставления задания ВОС.

<удержания> - см. 3.4.3.2. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, УСТАНОВКА-В, УДАЛЕНИЕ, ДОБАВЛЕНИЕ. Операция УДАЛЕНИЕ требует наличия уполномоченного для параметра <идентификация> представленного в <элементе удержания>, или для своего параметра <уполномоченный>, или для параметра <открытая система>, поименованной в одной из систем <целевая система> или <промежуточная система>.

<тип подзадания> - см. 3.4.3.3. Единственная операция - РАВНО.

<списки пи> - содержит все параметры <идентификация пи>, представленные в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров <идентификация пи>. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, УСТАНОВКА-В.

<списки указателей пи> - содержит все ссылки <указатель пи документа>, представленных в параметрах <блок документа> в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров <указатель пи документа>. Следует заметить, что поле <пароль> всегда имеет значение НУЛЬ. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, УСТАНОВКА-В.

<списки исходных агентств> - содержит все параметры <идентификация исходного агентства>, имеющиеся в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров <идентификация исходного агентства>. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, УСТАНОВКА-В.

<списки указателей исходных агентств> - содержит все параметры <указатель источника документа> и <структура исходного агентства документа>, расположенные в полях <блок документа> в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество элементов в списке. Следует заметить, что поле <пароль> всегда имеет значение НУЛЬ. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, УСТАНОВКА-В.

<действие при ошибке> - см. 3.4.3.4. Операциями являются РАВНО, и УСТАНОВКА-В.

* <время ожидания> - см. 3.4.1. Допустимы только операции РАВНО, БОЛЬШЕ ЧЕМ, БОЛЬШЕ ИЛИ РАВНО, МЕНЬШЕ ЧЕМ, МЕНЬШЕ ИЛИ РАВНО.

* <общий размер> - см. 3.4.1. Равно нулю, если только не ожидается передача СР. Допустимы только операции РАВНО, БОЛЬШЕ ЧЕМ, БОЛЬШЕ ИЛИ РАВНО, МЕНЬШЕ ЧЕМ, МЕНЬШЕ ИЛИ РАВНО.

3.4.7 Записи управления передачей

Открытая система может содержать одну или несколько ЗУП, при помощи которых определяется маршрут, по которому открытая система передает СР в другие открытые системы.

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

Первоначально все ЗУП, хранящиеся открытой системой, устанавливаются в значение НЕУПРАВЛЯЕМЫЙ. В этом случае открытая система будет делать попытки передачи с совмещением выполнения действий, определяемым локально. Она может принять любой алгоритм для выбора СР при передаче. (Алгоритмы будут обычно использовать некоторые комбинации типа "первым обслуживается самый ранний запрос", "первым обслуживается наименьший запрос" и "первым обслуживается запрос с наивысшим параметром <срочность>").

Если значение этого параметра НЕУПРАВЛЯЕМЫЙ, то параметры <установка системой> и <отметка времени> не записываются. Параметр <отметка времени> показывает время выполнения операции УСТАНОВКА.

Если значение этого параметра отличается от НЕУПРАВЛЯЕМЫЙ, то параметр <выбор> используется не только для определения таких СР, которые могут вызывать осуществление попыток передачи, но также для управления степенью совмещенности действий. Если список <выбор> пустой, только СР управления передачами вызывает передачи. Передачи всегда разрешаются, но они не позволяют реализовать совмещенность выполнения действий, устанавливаемую параметром <выбор>, которая превышает одно действие.

Попытка передачи СР агентству <получатель> не предпринимается, если только каждая СР (при ее наличии) еще не передана этому получателю, а СР, которая должна быть передана, выбрана другим параметром <селектор> в списке <выбор>.

Примечание - Это означает, что каждый селектор допускает одновременную передачу нескольких СР. В параметре <выбор> может быть несколько идентичных параметров <селектор>. Там, где более одной СР соответствуют параметру <селектор>, выбор СР для передачи является локальным делом PC (см. 3.4.3.1).

3.5 Документы ПОЗ

Этот раздел определяет семантику документов, содержащих отображения отчетов ПОЗ, отображения работы ПОЗ и отображения - ПОЗ-ЗУП. Синтаксис передачи для этих документов указывается в спецификации протокола ПОЗ.

Документы могут формировать часть СР и параметры примитивов J-GIVE и J-DISPOSE.

3.5.1. Документ "отображение-отчета" ПОЗ

Если эти документы сформированы ПОЗ, они содержат только один параметр <ПОЗ-отображение-отчета>. Объединение этих документов составляет список <ПОЗ-отображение-отчета>.

Если такие документы формируются в результате управления отчетами, выбранные отчеты вносятся в список в порядке получения их системой монитора задания ВОС, чтобы обеспечить список <отчет> для параметра <ПОЗ-отображение-отчета>. Параметр <отметка времени> представляет дату и время выполнения отображения.

Если такие документы формируются пунктом монитора при использовании примитива J-DISPOSE, чтобы разместить <отчет> в соответствии с параметром <данные размещения>, то <отметка времени> содержит время создания документа пунктом монитора, и в подзадании типа ПЕРЕМЕЩЕНИЕ-ОТЧЕТА имеется один параметр <ПОЗ-отображение-отчета>, содержащий все представленные отчеты.

Этот тип документа указывается значением ОписательОбьекта АСН.1 (см. ГОСТ 34.973) параметра "ПОЗ-отображение-отчета" и значением ИДЕНТИФИКАТОР ОБЪЕКТА АСН.1, которое указано в ГОСТ Р ИСО/МЭК 8832.

3.5.2. Документ "отображение-работы" ПОЗ

Поле <отметка времени> в параметре <отображение работы> представляет время выполнения отображения.

Поле <список заголовков> в параметре <полное отображение> содержит заголовки для выбранного подзадания и для всех проформ, содержащихся в нем.

Параметр <состояние системы назначения> содержит информацию об агентствах или передачах, связанных с СР. Поле <отметка времени> в параметре <состояние системы назначения> указывает время введения этого состояния.

Параметр <диагностика СИВ> содержит последнюю принятую диагностику "повторить-позже" и отсутствует, если значение параметра <состояние> не ОЖИДАНИЕ.

Форма <имя-хранилища-файлов> используется для агентств, которые получают или размещают документы, используя ПДУФ. В противном случае используются формы параметров <имя источника> и <имя пи>.

Значение ВЫПОЛНЯЕТСЯ означает, что в настоящее время выполняется элементарное действие. Поставщик услуг ПОЗ формирует <текст>, который содержит читабельную нестандартизованную информацию.

Значение ПРИНЯТО означает, что агентством было выдано сообщение об исполнении по приему информации. Список текстов получается при помощи примитива J-STATUS, который выдает читабельную нестандартную информацию.

Значение ОЖИДАНИЕ означает, что ресурсы недоступны, получен результат диагностики "повторить-позже" или ЗУП препятствует выполнению. Поставщик услуг ПОЗ формирует список текстов, который содержит читабельную нестандартную информацию.

Объединение этих документов создает новый список отображений работы.

Тип этого документа указывается значением ОписательОбьекта АСН.1 (см. ГОСТ 34.973) параметра "документ ПОЗ-отображение-работы" и значением ИДЕНТИФИКАТОР ОБЪЕКТА АСН.1, которое указывается в ГОСТ ИСО/МЭК 8832.

3.5.3 Документ "отображение-ЗУП" ПОЗ

<документ отображения передачи> : : = [<отображение передачи>]* L

<отображение передачи> : : =

<система отображения = N>

<отметка времени> (см. 3.3.2)

[<запись управления передачей>]* L (см. 3.4.7)

Значение параметра <отметка времени> предславляет время, в которое выполнено отображение.

Объединение этих документов создает новый список <отбражение передач>.

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

3.6 Параметры сервисных примитивов ПОЗ

3.6.1 Примитивы запроса и подтверждения J-INITIATE

Примитив запроса J-INITIATE содержит следующие поля СР:

Они полностью определяют работу, которая должна быть выполнена.

Примитив подтверждения J-INITIATE содержит только один параметр <локальный указатель задания ВОС = S>.

Такая строка формируется в системе предоставления задания ВОС для явной идентификации такого использования примитива J-INITIATE в данной открытой системе. Желательно, чтобы локальное представление данных и времени введения примитива было соответствующими, но может использоваться любая другая явная строка.

Уровень исполнения и параметры СИВ указателя кода диагностики (представленные примитивом J-BEGIN) выбираются при помощи введения примитива запроса J-INITIATE.

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

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

3.6.2.1 Примитив индикации J-DISPOSE

Вводится системой <целевая система> СР в принимающее или исполняющее агентство, указанное полем <имя пи = S> для формы <пи ПОЗ>, и в локальное принимающее агентство, осуществляющее доступ к ПДУФ для формы <принимающее агентство ПДУФ>.

Содержит следующие параметры:

Параметр <идентификатор активности поставщика> представляет локальную информацию, необходимую для идентификации активности последующих групп примитивов, используемых агентством (таких, как J-END-SIGNAL, J-MESSAGE и т.д.). Его форма не стандартизована.

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


Параметры <полномочие пользователя> и <счет пользователя> получаются из полей <элемент полномочий> и <элемент учета>. Они проверяются поставщиком услуг ПОЗ, если только обеспечивается параметр <идентификация>, в противном случае обеспечивается полный параметр <элемент полномочий> или <элемент учета>. Выбор параметра <элемент полномочий>, подлежащего использованию для примитива J-DISPOSE, выполняется локальной директивной функцией, использующей имя принимающего или исполняющего агентства и имя уполномоченного по идентификации пользователя в параметре <элемент полномочий>. Значение НЕИЗВЕСТНЫЙ указывает на невозможность отыскания соответствующего элемента полномочий, что часто является причиной возврата в исходное состояние агентства.

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

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

Группа примитива J-DISPOSE также выдается в принимающее агентство, указанное в параметре <данные размещения> (при его наличии) для монитора задания ВОС, при каждом отчете, который поступает в монитор задания ВОС.

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

Параметр <ошибки> содержит список <диагностическая информация>, формируемый из параметров <идентификация исходного агентства> и <информация об ошибке> для любого параметра <указатель одного документа> со значением БЕЗУСПЕШНО параметра <состояние> (см. 3.4.4.1.3). Параметры <ошибки> (при их наличии) передаются в принимающее агентство вместе с параметром <документ размещения>. Размещение параметра <ошибки> не стандартизовано.

Параметр <документ размещения> содержит поле <ПОЗ-отображение-отчета> или документ любого другого (стандартного или нестандартного) типа, обеспечиваемого PC.

Примечание - Необходимо, чтобы PC устанавливали типы документов, которые они обеспечивают (для примитивов J-GIVE, J-DISPOSE и передачи). Предполагается, что универсальные PC должны обеспечивать, по меньшей мере, первые три типа документов, определенные в приложении С.


Размещение отчетов в принимающие агентства выполняется примитивом J-DISPOSE после преобразования параметра <отчет> в параметр <ПОЗ-отображение-отчета>.

3.6.2.2 Примитив ответа J-DISPOSE

Содержит единственный параметр

<идентификатор активности агентства = S>.

Он представляет локальную информацию, необходимую для идентификации активности последующих групп примитивов, выдаваемых поставщиком услуг ПОЗ (J-KILL, J-STATUS и т.д.). Его формат не стандартизован.

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

3.6.3.1 Примитив индикации J-GIVE

Вводится в исходное или исполняющее агентство в результате обработки параметра <указатель единичного документа> или параметров <структура исходного агентства документа> и <список-имен>, следующих за примитивом J-ENQUIRE (см. 3.4.4.1.3 и 3.4.4.1.4).

Примитив индикации J-GIVE выдается системой <открытая система действия = N> в исходное или исполняющее агентство, идентифицированное параметром <имя исходного агентства = S> для формы <пи ПОЗ> и в локальное исходное агентство, осуществляющее доступ к ПДУФ для формы <исходное агентство ПДУФ>.

Примитив индикации J-GIVE содержит следующие параметры:

Все параметры и их смысл определены в предыдущих разделах, кроме параметра <группа документа>. Этот параметр будет иметь значение ПОСТОЯННЫЙ до тех пор, пока примитив J-GIVE не будет введен в исполняющее агентство со значением <группа конца активности> или <группа проформы>. В данном случае это означает, что примитив индикации J-GIVE для документов доступен в конце активности или получается при порождении проформы, которая имеет значение параметра <обработка порождения документа>, соответственно равное значению параметра <обработка запроса порождения>.

Если параметр <имя исходного агентства> указывает исполняющее агентство, то активность, к которой относится примитив J-GIVE, идентифицируется параметром <идентификатор активности агентства>. Из множества документов, к которым должен осуществляться доступ, те, которые становятся доступными в конце активности, имеют параметр <группа конца активности>, а те, которые доступны при выдаче примитива J-SPAWN, имеют параметр <группа проформы>. В дальнейшем параметр <обработка запроса порождения> будет равен его значению в примитиве запроса J-SPAWN.

3.6.3.2 Примитив ответа J-GIVE

Содержит единственный параметр <документ>. Этот <документ> имеет <тип документа> в примитиве индикации J-GIVE. Следует заметить, что если соответствующий документ не может быть найден, примитив запроса J-ROLLBACK выдается вместо примитива ответа J-GIVE, после чего поставщиком услуг используется диагностика услуги типа "С-" ПОЗ для диагностики ПОЗ.

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

Агентство допускает выполнение нескольких примитивов J-GIVE при помощи одного и того же элементарного действия, даже если при последнем доступе указывается значение операции ПЕРЕМЕЩЕНИЕ. Исходный документ удаляется только в том случае, если все группы примитивов J-GIVE исполнили операции или возвращены в первоначальное состояние, по меньшей мере, с одним исполнением операции ПЕРЕМЕЩЕНИЕ.

Параллельно выполняемая активность с другим идентификатором элементарного действия придерживается обычных правил СИВ.

3.6.4 Примитивы индикации и ответа J-ENQUIRE

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

Исходное или исполняющее агентство, которому выдается этот примитив, получает его также, как и примитив индикации J-GIVE. Он содержит следующие параметры:

Примитив ответа J-ENQUIRE содержит только параметр [<список-имен>]* L.

Примитив J-ENQUIRE используется для получения имен всех документов, чей <список-имен> начинается с последовательности <частичный-список-имен> в параметре <структура исходного агентства документа> и к которым возможен доступ при помощи примитива J-GIVE, используя указанные параметры (см. 3.4.4.1.4).

Выданные имена <списка-имен> представляют собой суффиксы, добавляемые к последовательности <частичный-список-имен> при выдаче примитивов J-GIVЕ.

Если документ не может быть найден, выдается примитив запроса J-ROLLBACK вместо примитива ответа J-ENQUIRE, и затем диагностика услуги типа "С-" используется поставщиком услуг ПОЗ для диагностики ПОЗ.

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

3.6.5 Примитив запроса J-MESSAGE

Содержит параметры:

<идентификатор активности поставщика>

<сообщение>

<сообщение>: : = [<текст = S>]* L

Параметр <сообщение> используется поставщиком услуг ПОЗ для формирования списка текстов отчета, который передается в монитор задания ВОС, если выбирается уведомляющая служба типа события СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ. (Если уведомляющая служба такого типа события не выбирается для любого пункта монитора, <сообщение> отклоняется).

Параметр <уровень исполнения> устанавливается в значение ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА, и элементарное действие всегда выполняется до исполнения. Указатель кода диагностики идентичен его указателю в соответствующем примитиве J-DISPOSE, а <сообщение> соответствует наборам знаков, требуемым указателем кода диагностики. Каждая строка <текст> в параметре <сообщение> ограничивается по длине до 40 знаков.

3.6.6 Примитив запроса J-SPAWN

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

<идентификатор активности поставщика>

<обработка запроса порождения>

Порождаемой является любая проформа верхнего уровня с параметром <обработка запроса порождения>, равным одноименному параметру <обработка запроса порождения> примитива запроса J-SPAWN. После соответствующего примитива индикации J-READY любые документы, которые должны использоваться при порождении, могут быть удалены (выбор при помощи примитива J-GIVE завершается).

Параметр <уровень исполнения> может принять некоторое определенное значение. Элементарное действие может быть возвращено в исходное состояние примитивом J-ROLLBACK.

3.6.7 Примитив запроса J-END-SIGNAL

Неявно ссылается на более ранний примитив J-DISPOSE, который задал уровень исполнения ПРИНЯТИЕ. Этот примитив содержит только параметр <идентификатор активности поставщика>. Если привлекается только одна активность, то все проформы верхнего уровня, отмеченные для порождения с условием ЗАВЕРШЕНИЕ или УСЛОВНЫЙ, обязательно порождаются в порядке их появления в списке <список проформ>. См. также 3.4.5.2. Если привлечено более одной активности, то порождение выполняется только в том случае, если выполняются все группы примитивов J-END-SIGNAL.

Уровень исполнения равен 1, и элементарное действие всегда выполняется до исполнения.

3.6.8 Примитивы индикации и ответа J-SТATUS

Примитив индикации J-STATUS выдается поставщиком услуг ПОЗ в принимающее или исполняющее агентство, которое предоставило примитиву J-DISPOSE уровень исполнения ПРИНЯТИЕ, но еще не был введен примитив запроса J-END-SIGNAL. Он содержит только <идентификатор активности агентства>. Примитив ответа содержит единственный параметр <сообщение о состоянии> : : = [<текст = S>]* L

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

Это элементарное действие всегда выполняется до исполнения. Набор знаков в сообщении о состоянии соответствует требованиям указателя кода диагностики. Каждая строка параметра <текст> ограничена по длине до 40 знаков.

3.6.9 Примитивы индикации J-HOLD, J-RELEASE, J-KILL, J-STOP

Эти примитивы содержат только параметр <идентификатор активности агентства>.

Примитив индикации и J-HOLD информирует принимающее или исполняющее агентство о том, что поставщик услуг ПОЗ желает, чтобы активность была приостановлена. Примитивы запроса J-MESSAGE, J-SPAWN и J-END-SIGNAL. не выдаются до тех пор, пока не будет принят примитив индикации J-RELEASE.

Примитив индикации J-RELEASE разрешает выдачу примитивов запроса J-MESSAGE, J-SPAWN, J-END-SIGNAL и используется для отмены примитива J-HOLD.

Примитив индикации J-KILL требует, чтобы принимающее или исполняющее агентство завершило активность, начатую примитивом J-DISPOSE, и сформировало примитив запроса J-END-SIGNAL. Примитив J-END-SIGNAL не может обеспечить никаких документов. (Поставщик услуг ПОЗ не выдает группы J-ENQUIRE или J-GIVE).

Примитив индикации J-STOP имеет такое же действие, как примитив J-KILL, но документы будут доступны в результате выполнения примитива J-END-SIGNAL. (Поставщик услуг ПОЗ выдает группы J-ENQUIRE и J-GIVE). Управляемый ЛО не выдает примитива J-ROLLBACK для этих элементарных действий, но управляющий ЛО может потребовать возвратиться в первоначальное состояние.

3.6.10 Краткое описание

Краткое описание СП ПОЗ представлено в таблице 3. Указания по их использованию представлены в таблице 2.


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

Таблица 3 - Краткое описание СП и параметров ПОЗ

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

РАЗДЕЛ 4. БАЗОВЫЙ КЛАСС

4.1 Группы примитивов и типы документов для базового класса

4.1.1 Группы сервисных примитивов

Можно использовать следующие группы примитивов:

J-INITIATE-WORK

J-INITIATE-WORK-MAN

J-DISPOSE

J-GIVE

J-END-SIGNAL

J-STATUS

J-KILL

J-STOP

J-MESSAGE

PC базового класса может обеспечить любую комбинацию следующих наборов СП:

a) J-INITIATE-WORK;

b) J-INITIATE-WORK-MAN;

c) J-DISPOSE (к принимающему или исполняющему агентству) с уровнем исполнения операций ЗАВЕРШЕНИЕ в примитиве J-READY;

d) J-GIVE (для группы конца активности);

е) J-DISPOSE (к принимающему или исполняющему агентству) с уровнем исполнения ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА в примитиве J-READY

J-END-SIGNAL

J-STATUS

J-MESSAGE

J-KILL

J-STOP

Система базового класса не обеспечивает значения ЗАВЕРШЕНИЕ для уровня исполнения в примитивах C-BEGIN или J-BЕGIN. Однако она может выдать или принять такое значение в примитиве С-READY или J READY.

4.1.2 Типы документов

Системам базового класса нет необходимости обеспечивать полную классификацию типов документов. ГОСТ ИСО/МЭК 8832 определяет три типа документов, поименованных значениями ОписательОбъекта ACН.1 (см. ГОСТ 34.973):

"простой текстовый документ ИСО";

"простой документ для печати ИСО";

"простой документ в двоичном формате ИСО".

Для краткости эти типы документов указываются в этом разделе только, как "текст" (1), "печать" (2) и "двоичный" (3), соответственно.

Кроме того, в базовом классе используются следующие типы документов (см. 3.5):

"документ отображение-paбoты ПОЗ";

"документ отображение-oтчета ПОЗ".

Для краткости эти типы документов указываются в этом разделе только как "отображение-работы (4)" и "отображение-отчета (5)" (см. 4.2.1).

Следующие типы документов, требующиеся для общего назначения, обеспечиваются PC базового класса:

Следует заметить, что другие типы документов нет необходимости обеспечивать в PC базового класса ПОЗ.

4.2 Концептуальные структуры данных для базового класса

В данном разделе описаны подмножества структур данных (определенных в 3.3-3.5), которые используются в базовом классе. В 4.3 определены дополнительные ограничения базового класса на параметры СП.

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

4.2.1 Отчеты

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

Эти отчеты образуют подмножество отчетов, определенных в 3.3.2 следующим образом:

Параметр <идентификация подзадания> имеет весь диапазон значений, указанных в 3.3.2.

<идентификация события> : : =

(НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ | ЗАВЕРШЕНИЕ-ОБРАБОТКИ I

АВАРИЙНОЕ ЗАВЕРШЕНИЕ) | СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ)

Другие события не распознаются в базовом классе. Отчеты о других событиях не обрабатываются пунктами монитора базового класса. Запросы (в параметре <селектор отчета>) отчетов о других событиях СР отклоняются системой базового класса.

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

4.2.1.1 Диагностическая информация

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

Поля <детали исходного агентства> и <детали пи> не относятся к активности ПДУФ, а параметр <диагностика СИВ> не содержит значения <итог ПДУФ>.

4.2.1.2 Информация учета

Информация учета не формируется системами базового класса. Если она передается к таким системам в примитивах C-READY или C-REFUSE, она игнорируется.

4.2.2 Спецификации работы

PC базового класса обеспечивает ограниченную форму СР. СР создаются в системе базового класса как результат поступающей информации или (если инициирующее агентство обеспечивается) примитива J-INITIATE (см. 4.3). Такие СР содержат только определенную ниже информацию. Попытка передать более сложную СР в систему базового класса завершается отклонением и диагностикой СИВ.

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

Параметр <список проформ> для некоторой СР с параметром <целевая система> базового класса содержит, самое большее, одну проформу верхнего уровня. Любые списки проформ внутри этой проформы обрабатываются прозрачно. СР, созданные порождением в системе базового класса и предназначенные для некоторой другой системы, содержат прозрачный список проформ.

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


СР базового класса содержит, самое большее, один параметр <документ>, указываемый подзаданием верхнего уровня.

4.2.2.1 Параметры задания ВОС

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

Отметим, что параметры <первичная контролирующая спецификация>, <учет> и <параметры защиты> отсутствуют.

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


Поля <параметры задания ВОС> имеют полную форму и значения, определенные в 3.4.2 за исключениями, приведенными ниже.

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

Примечание - Не требуется, чтобы системы базового класса обеспечивали исходные агентства. Следовательно, для примитива J-GIVE полномочие не требуется, поскольку доступ имеется только к активности исполняющего агентства, установленной ранее выданным примитивом J-DISPOSE. Связующим параметром между двумя примитивами является идентификатор активности агентства.


Параметр <первичная контролирующая спецификация> не содержит значения <промежуточная система>, а параметр <инструкции по размещению> не имеет значения СОХРАНЕНИЕ.

Параметр <селектор отчета> содержит только следующие категории событий:

НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ

ЗАВЕРШЕНИЕ-ОБРАБОТКИ

АВАРИЙНОЕ ЗАВЕРШЕНИЕ

СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ

4.2.2.2 Параметры подзадания ВОС

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

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

Параметр <тип подзадания> имеет одно из следующих значений:

ПЕРЕМЕЩЕНИЕ-ОТЧЕТА

ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА

ВЫПОЛНЕНИЕ-РАБОТЫ.

Другие значения параметра <тип подзадания> имеются только в проформах, которые остаются прозрачными.

4.2.3 Операции перемещения документов

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

Имеется один параметр <перемещение документа> и один параметр <идентификация пи>. Параметр <блок документа> имеет значение <одна форма>.

Параметр <идентификация пи> не имеет формы <пи ПДУФ>. Он не имеет значения <дополнительные полномочия>; <параметр агентства> имеет значение НУЛЬ, а параметр <префикс пи> является пустым.

Параметр <указатель пи документа> не имеет формы <ПДУФ-писать данные>, а <параметр доступа пи> имеет значение НОРМАЛЬНЫЙ.

Имеется один параметр <указатель документа>, который при достижении целевой системы базового класса имеет значение ВЛОЖЕННЫЙ, или содержит одно поле <указатель единичного документа> со значением параметра <состояние> БЕЗУСПЕШНО.

В последнем случае параметр <идентификация исходного агентства> имеет значение <исходное агентство ПОЗ>, отсутствует параметр <дополнительные полномочия>, а параметр <указатель источника документа> имеет значение <ПОЗ-читать данные>. Параметр <диагностика СИВ> имеет форму, определенную в 4.2.1.1.

Если <операции перемещения документов> имеются в подзадании верхнего уровня, произведенного в системе базового класса порождением, то может иметь место параметр <указатель единичного документа> с состоянием НЕТ-ПОПЫТКИ. Если <действие открытой системы> является локальной, параметр <идентификация исходного агентства> имеет значение ПОСТАВЩИК или <исходное агентство ПОЗ>, которое представляет исполняющее агентство, и имеется <параметр агентства> со значением НУЛЬ и <параметр доступа к исходному агентству> со значением ПЕРЕМЕЩЕНИЕ.

4.2.4 Операции выполнения работы

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

Параметр <операции СР> содержит два поля <операция работы>. Первое поле <операция работы> имеет значение "ВЫБОР <селектор>" (см. ниже).

Второе поле имеет одно из значений

УНИЧТОЖЕНИЕ

ОСТАНОВ

ОТОБРАЖЕНИЕ <имя-док> КРАТКОЕ.

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

ПЕРВЫЙ-ЗАГОЛОВОК-ИМЕЕТСЯ

<тест заголовка>

Три поля <тест поля> содержит тесты на пригодность трех полей

ВОС-СИСТЕМА-ПРЕДОСТАВЛЕНИЯ-ЗАДАНИЯ

ВОС-ИМЯ-ЗАДАНИЯ

ТИП-ПОДЗАДАНИЯ.

Использование значения ЛЮБОЙ-ЭЛЕМЕНТ не обеспечивается в базовом классе.

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

Если СР содержит вложенные проформы, они являются полностью прозрачными, и имена открытых систем, содержащихся в параметре <целевая система> или в параметрах <промежуточная система> этих проформ, не обеспечивают неявных разрешений для обработки или отображения СР.

4.2 5 Операции перемещения отчетов

Параметр <операция перемещения отчетов> имеет полную общность с описанием в 3.4.4.5, за исключением того, что:

a) индекс монитора всегда имеет значение "нуль" (только первичные мониторы);

b) <данные размещения> не имеют значение СОХРАНЕНИЕ;

c) ограничения на форму параметров <идентификация пи> и <указатель пи документа> определены в 4.2.3.

4.2.6 Проформы

Проформа верхнего уровня в системе базового класса имеет параметр <данные управления порождением>, установленный в значение ЗАВЕРШЕНИЕ. Имя проформы не используется ни в одном указателе проформы в любой вложенной проформе.

4.2.7 Прозрачность проформ

СР, передаваемая в систему базового класса, имеет параметр <целевая система> этой открытой системы.

СР, созданная порождением (или примитивом J-INITIATE), может (первый случай) или не может (второй случай) иметь такую открытую систему, которая указана параметром <целевая система>.

В первом случае подзадание, указанное в СР, имеет, самое большее, одну проформу верхнего уровня; основное подзадание, проформа верхнего уровня и подзадание, указанное в проформе верхнего уровня, подчиняются ограничениям базового класса, указанным в этом разделе. Параметр <список проформ> в проформе верхнего уровня является прозрачным и неограниченным.

Во втором случае подзадание, указанное в СР, подчиняется ограничениям базового класса, однако параметр <список проформ> в подзадании является прозрачным и неограниченным.

4.2.8 Записи управления передачей

Системы базового класса не распознают понятие ЗУП, и не обеспечивают подзадания типа ЗУП-ОБРАБОТКА

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

4.2.9 Документы ПОЗ

Система базового класса обеспечивает формирование и передачу отображений работы ПОЗ, содержащих только параметр <краткое отображение>. Она не обеспечивает такие документы, если они содержат параметр <полное отображение>.

Если система обеспечивает формирование примитива J-INITIATЕ-MAN, она обеспечивает прием таких документов и их размещение, используя примитив J-DISPOSE.

Если система базового класса обеспечивает пункт монитора, она способна преобразовать параметр <отчет> (см. 4.2.1) в документ отображения отчета ПОЗ и разместить этот документ, используя примитив J-DISPOSE к принимающему агентству.

Документы отображения ЗУП ПОЗ не обеспечиваются.

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

4.3 Параметры группы примитивов J-INITIATE для базового класса

В службе базового класса группа примитивов J-INITIATE имеет подмножество параметров, доступных в расширенной ПОЗ. Имеются следующие ограничения.

Уровень исполнения имеет только значения ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА и ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА в примитиве J-BEGIN.

Отсутствуют параметры <вторичная контролирующая спецификация>, <учет> и <параметры защиты>.

Допускаются только примитивы

J-INITIATE-WORK

J-INITIATE-WORK-MAN.

Параметр <спецификация подзадания> для примитива J-INITIATE-WORK подчиняется ограничениям, указанным в 4.2, но кроме этого на него налагаются следующие ограничения.

4.3.1 Параметры верхнего уровня

<параметры задания ВОС>;

<параметры подзадания ВОС>;

<параметры действия ПОЗ>;

<действие при ошибке> - ЗАВЕРШЕНИЕ;

<список проформ> - одна проформа или нет проформ. (Одна проформа не имеет вложенных проформ);

<список документов> - один документ "текст (1)" или "печать (2)" для примитива J-INITIATE-WORK. Нет документов для примитива J-INITIATE-WORK-MAN. Если документ "печать (2)", то проформы отсутствуют.

4.3.2 Параметры задания ВОС

<идентификация инициирования> - любое значение;

<ВОС-имя-задания> - любое значение;

<данные полномочия> - параметры <элемент полномочий> и <элемент разрешения>, предоставляющие идентификацию пользователя и пароль для использования в открытой системе <целевая система>. Этот параметр используется для полномочий активностей ПОЗ, таких как обработка или выдача результата. Исполняющее агентство может потребовать, чтобы одна и та же информация повторялась в заголовке документа ("ЯУЗ"), передаваемом в примитиве J-DISPOSE. Могут присутствовать дополнительные полномочия и элемент разрешения, чтобы обеспечить выполнение действия в целевой системе проформы. Идентификация элемента разрешения всегда совпадает с идентификацией элемента полномочий;

<вторичная контролирующая спецификация> - отсутствует. Локальная САУ устанавливает параметр <первичная контролирующая спецификация> с полем <селектор отчетов>, указывающим один или несколько типов событий АВАРИЙНОЕ ЗАВЕРШЕНИЕ, СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ, НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ И ЗАВЕРШЕНИЕ-ОБРАБОТКИ, и с параметром <данные размещения> по своему выбору. Значение СОХРАНЕНИЕ не используется в базовом классе.

4.3.3 Параметры подзадания ВОС

<список целевых систем> - одно поле <целевая система>; параметр <промежуточные системы> имеют пустое значение;

<срочность> - только значение СРЕДНЯЯ;

<удержания> - имеет пустое значение;

<тип подзадания> - только значение ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА или ВЫПОЛНЕНИЕ-РАБОТЫ.

4.3.4 Параметры действия ПОЗ

Ими являются <операции перемещения документа> или <операции выполнения работы>.

4.3.4.1 Операции перемещения документа

Имеется одна операция <перемещение документа>, содержащая параметры:

4.3.4.2 Операции выполнения работы

Имеются две <операции выполнения работы>. Первая - <операция выбора>, а вторая - УНИЧТОЖЕНИЕ, OCТAHOB или ОТОБРАЖЕНИЕ. Параметр <селектор> имеет значения

ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ и

Операция ОТОБРАЖЕНИЕ запрашивает значение КРАТКОЕ, и значением параметра <имя документа> является строка ОТОБРАЖЕНИЕ. Параметр <имя> указывает такую открытую систему, в которой был введен примитив J-INTIATE-MAN.

4.3.5 Проформы

Одна проформа, если она представлена, содержит

<имя проформы> - установить значение ВЫВОД.

Основная часть проформы с параметрами:

<данные управления порождением> - установить значение ЗАВЕРШЕНИЕ;

<параметры подзадания ВОС> - как в 4.3.3, но тип подзадания имеет значение ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА;

<параметры действия ПОЗ> см. ниже;

<список проформ> - проформы не появляются в проформах в примитиве J-INITIATE базового класса.

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

<тип документа> - система предоставления задания ВОС с минимальным согласованием возможна при установке этого поля в значение "печать (2)" (для примитива J-INITIATE-WORK) и в значение "отображение-работы (4)" (для примитива J-INITIATE-WORK-MAN) и любое другое значение устанавливать не требуется. Для системы с минимальным согласованием, принимающей СР, не требуется обеспечение любого значения, отличного от перечисленных выше;

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

<действие открытой системы> равно начальному значению <целевая система>;

<идентификация исходного агентства> значение ПОСТАВЩИК в проформе при обработке, в противном случае - значение <исходное агентство ПОЗ>;

<имя исходного агентства> - равно начальному значению <имя пи>;

<параметр агентства> - НУЛЬ;

<указатель источника документа> - имеет значение <ПОЗ-читать-данные>;

<параметр доступа к исходному агентству> - имеет значение ПЕРЕМЕЩЕНИЕ;

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

<встроенная диагностика> - имеет значение ВСТРОЕННАЯ.

4.3.6 Краткое описание информации, содержащейся в примитиве запроса J-INITIATE базового класса

4.3.6.1 Примитив J-INITIATE-WORK

В этом примитиве поставщику услуг ПОЗ передается следующая информация:

a) идентификация инициирования;

b) имя задания ВОС;

c) имя целевой системы;

d) имя принимающего или исполняющего агентства в целевой системе;

е) идентификация пользователя и пароль для использования в целевой системе;

f) документы "текст (1)" или "печать (2)" для передачи в исполняющее или принимающее агентство (соответственно) и их имена;

g) имя целевой системы проформы (если используется исполняющее агентство);

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

i) имя итоговой распечатки (2), произведенной в начальной целевой системе;

j) имя принимающего агентства в целевой системе проформы для итогового распечатываемого документа (2);

k) имя для итогового распечатываемого документа (2) при передаче его в принимающее агентство в целевой системе проформы.

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

4.3.6.2 Примитив J-IINITIATE-WORK-MAN

В этом примитиве поставщику услуг ПОЗ передается следующая информация:

a) идентификация инициирования;

b) имя задания ВОС для обработки;

c) ВОС-имя-задания для задания ВОС, которое должно выполняться, и тип его подзадания;

d) имя целевой системы;

e) идентификация пользователя и пароль для использования в целевой системе;

f) имеется ли запрос на выполнение операции КРATКОЕ ОТОБРАЖЕНИЕ, ОСТАНОВ или УНИЧТОЖЕНИЕ для задания ВОС, которое должно быть выполнено;

g) имя целевой системы проформы;

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

i) имя принимающего агентства для документа "отображение-работы (4)" в целевой системе проформы;

j) имя для документа "отображение-работы (4)" при передаче его в принимающее агентство в целевой системе проформы.

4.4 Другие группы примитивов в базовом классе

4.4.1 Примитив J-DISРОSЕ

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

Отсутствуют параметры <дополнительные полномочия> и <счет пользователя>, а <параметр агентства> имеет значение НУЛЬ. Параметр <диагностическая информация> не содержит значения <итог ПДУФ>.

Параметр <документ размещения> имеет значение "отображение-работы (4)" (краткое), "отображение-отчета (5)", "текст (1)" (для исполняющего агентства) или "печать (2)" (для принимающего агентства).

4.4.2 Примитив J-GIVE

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

Отсутствуют <дополнительные полномочия> и <счет пользователя>, а <параметр агентства> имеет значение НУЛЬ. Параметр <группа документов> имеет значение <группа конца активности>, а <тип документа> имеет значение "печать (2)".

4.4.3 Другие группы примитивов

Остальные группы примитивов базового класса (J-MESSAGE, J-END-SIGNAL, J-STATUS, J-KILL, J-STOP) содержат полный набор параметров, определенных в 3.6.5, 3.6.7-3.6.9.

4.5 Сводный перечень примитивов и параметров базового класса

Сводный перечень приведен в таблице 4.


Таблица 4 - Сводный перечень примитивов и параметров ПОЗ базового класса

ПРИЛОЖЕНИЕ А (обязательное). Соглашения по услугам ПОЗ

ПРИЛОЖЕНИЕ А
(обязательное)

А.1 Введение

ГОСТ Р ИСО/ТО 8509 ограничивается областью двусторонних операций, используемых на сетевом, транспортном, сеансовом уровнях и уровне представления. Данное приложение представляет модель услуг по ГОСТ Р ИСО/ТО 8509 с минимальными изменениями и определяет соглашения по услугам, используемые в ПОЗ.

А.2 Назначение

Данное приложение устанавливает определения терминов и соглашений при определении услуг, обеспечиваемых ПОЗ.

А.3 Ссылки

ГОСТ 28906-91 (ИСО 7498-84, Доп.1-84 ИСО 7498-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель.

А.4 Определения

А.4.1 Данное приложение построено по концепциям ГОСТ 28906 и использует следующие определенные в нем термины:

a) (N) = услуга;

b) (N) = средство;

c) (N) = уровень.

А.4.2 Для данного приложения применимы также следующие определения:

А.4.2.1 Пользователь услуги - абстрактное отображение ЛО в одной системе, которая использует услугу; любой пользователь услуги может инициировать услугу или ответить на инициирование от поставщика услуг в результате инициирования другого пользователя или пользователей услуг.

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

А.4.2.3 Услуга уровня - услуга, обеспечиваемая уровнем эталонной модели.

А.4.2.4 Сервисный примитив; примитив - абстрактный, независимый от PC элемент взаимодействия между пользователем услуги и поставщиком услуги.

А.4.2.5 Запрос (примитив) - примитив, введенный пользователем услуги, чтобы вызвать процедуру (для подтверждаемой или неподтверждаемой услуги) при помощи поставщика услуг.

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

А.4.2.7 Ответ (примитив) - примитив, введенный пользователем услуги, чтобы завершить процедуры, связанные с подтверждаемой услугой.

А.4.2.8 Подтверждение (примитив) - примитив, введенный поставщиком услуг, чтобы завершить процедуры, связанные с подтверждаемой услугой.

А.4.2.9 Пункт доступа к сервисному элементу - концептуальный пункт, в котором имеют место взаимодействия между поставщиком услуг ПОЗ и агентством ПОЗ.

А.5 Модель ПОЗ

ПОЗ определяется в терминах абстрактной модели (см. рис.A.1), которая имеет следующие элементы:

a) пользователи услуг ПОЗ;

b) поставщик услуг ПO3.

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

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

А.6 Сервисные примитивы

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

a) СП являются концептуальными и не относятся непосредственно к элементам протокола и не рассматриваются как обращения макрокоманд метода доступа к услуге;

b) имеются другие эквивалентные наборы СП, которые могут описывать такую службу;

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

Рисунок А.1 - Модель службы

Рисунок А.1 - Модель службы

А.6.1 Типы услуг

Имеется два типа услуг:

a) неподтверждаемая услуга, включающая в себя

1) один примитив запроса (см. А.4.2.5) и один или несколько примитивов индикации (см. А.4.2.6) в различных пунктах доступа к сервисному элементу;

2) один или несколько примитивов индикации в различных пунктах доступа к сервисному элементу;

b) подтверждаемая услуга, включающая в себя

1) один примитив запроса (см. А.4.2.5);

2) один или несколько примитивов индикации (см. А.4.2.6) и один или несколько примитивов ответа (см. А.4.2.2) - оба в различных пунктах к сервисному элементу из перечисления 1);

3) один примитивов* подтверждения (см. А.4.2.8) в том же пункте доступа к сервисному элементу, как представлено в перечислении 1).
___________
* Текст соответствует оригиналу. - Примечание "КОДЕКС".

А.6.2 Свойства примитивов

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

СП передается в направлениях:

a) от пользователя услуги к поставщику услуг;

b) от поставщика услуг к пользователю услуг.

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

А.6.3 Имена примитивов

Имя каждого СП содержит три элемента:

a) начальное имя (или имена), указывающее услугу (см. А.8.1);

b) общее имя, указывающее группу примитивов (см. А.8.2);

c) специфическое имя, указывающее тип примитива (см. А.8.3).

А.6.4 Группы примитивов

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

Группа, которая включает примитивы, отображающиеся в примитивы СИВ, называется группой исполнения, или, иначе говоря, поименованы как примитивы, например:

группа исполнения J-INITIATE

группа исполнения J-DISPOSE.

А.7 Временные диаграммы

Указывают:

a) последовательность взаимодействий с пользователем услуги;

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

Каждая диаграмма содержит одну или несколько вертикальных линий, отображающих взаимодействие между поставщиком и пользователем услуг (пункт доступа к сервисному элементу); для пользователя инициирующего объекта или ГУЛО (исполнения) левая от линии область отображает пользователя услуг, а правая - поставщика услуг; в других случаях поставщик услуг представляется областью слева от линии, а пользователь услуг - справа.

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

Рисунок А.2 - Неподтверждаемые услуги

Рисунок А.2 - Неподтверждаемые услуги

Рисунок А.3 - Подтверждаемые услуги

Рисунок А.3 - Подтверждаемые услуги

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

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

А.7.1 Примеры неподтверждаемых услуг

Возможны все последовательности, показанные на рисунке А.2.

А.7.2 Примеры подтверждаемых услуг

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

А.8 Соглашения по наименованиям сервисных примитивов

А.8.1 Инициалы

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

F - служба ПДУФ;

J - служба ПОЗ;

V - службы ВТ (виртуальные терминалы);

С - служба СИВ;

А - услуги других прикладных систем;

Р - услуги уровня представления;

S - услуги сеансового уровня;

Т - услуги транспортного уровня;

N - услуги сетевого уровня;

DL - услуги звена данных;

Ph - услуги физического уровня.

Примечание - Использование инициала N для обозначения услуг сетевого уровня не следует путать с использованием символа (N) для обозначения конкретного, но неопределенного уровня модели.

А.8.2 Общее имя

Одно слово или слово, написанное через дефис, используется для общего имени, например, ИНИЦИИРОВАНИЕ, РАЗМЕЩЕНИЕ, КОНЕЦ-СИГНАЛ.

А.8.3 Конкретное имя

Конкретное имя содержит одно из следующих (указывающих тип примитива или группу примитивов):

a) запрос;

b) индикация;

c) ответ;

d) подтверждение;

e) группа исполнения.

А.8.4 Представление

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

Инициал и общее имя разделяются черточкой. Общие и конкретные имена разделяются пробелами.

А.8.5 Примеры

Ниже приведены примеры имен параметров, образованные с использованием указанных соглашений:

a) J-INITIATE запрос;

b) J-KILL индикация;

c) J-DISPOSE группа исполнения.

ПРИЛОЖЕНИЕ В (обязательное). Регистры типов документов

ПРИЛОЖЕНИЕ В
(обязательное)

В.1 Введение

Организация может пожелать установить регистр типов документов личного пользования или регистрировать тип документов в Регистре ИСО типов документов.

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

В.2 Назначение элемента

Назначение элемента состоит в обеспечении:

a) идентификации типа документа;

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

c) определения (возможно, при помощи указателя) одного или нескольких синтаксисов передачи для типа документа;

d) определения правил сцепления для типа документа.

В.3 Идентификация

Тип документа идентифицируется значениями ИДЕНТИФИКАТОР ОБЪЕКТА и ОписательОбъекта АСН.1, назначаемыми согласно правилам ГОСТ Р ИСО/МЭК 8824.

В.4 Семантика документов

Семантика, которая стандартизуется, может быть очень полной, поскольку имеется тип документов, определяемых для обеспечения отображений ПОЗ. Для других типов документов семантики могут быть только частично стандартизованы. Примером этого является тип документа "простой текстовый документ ИСО" (см. ИСО/МЭК 8832), который стандартизован только для строк графических знаков.

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

Абстрактный синтаксис типа данных, обеспечивающих передачу семантик типов документов, определяется и именуется в соответствии с требованиями ГОСТ 34.971 для наименований абстрактных синтаксисов.

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

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

Элемент регистра определяет либо непосредственно, либо путем ссылки на правила кодирования точный набор битов, который должен быть использован для передачи одного значения сервисных данных уровня представления (см. ГОСТ 34.971), которые должны содержать семантики документов (для передачи базового класса) и точный набор битов, который должен использоваться для передачи ряда значений сервисных данных уровня представления в тех случаях, когда расширенные PC обеспечивают передачу.

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


Синтаксис передачи для типа документа получает имя в соответствии с требованиями ГОСТ 34.971 для наименований синтаксисов передачи.

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

8.6 Взаимоотношения синтаксиса и семантики

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

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

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

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

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

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

В.7 Синтаксические соглашения

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

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

В.8 Содержимое регистра

Каждый элемент регистра содержит информацию, определяемую в последующих подразделах.

В.8.1 Идентификатор типа документа

Представляет собой значение ИДЕНТИФИКАТОР ОБЪЕКТА и ОписательОбъекта АСН.1.

В.8.2 Семантики документов

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

В.8.3 Синтаксисы документов

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

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

В.8.4 Имена синтаксисов

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

В.8.5 Сцепление

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

А сцепить с В, чтобы получить С

и который содержит определение операций в каждом случае.

Примечание - Наиболее распространен случай, когда документы А, В и С имеют один и тот же тип.

В.8.6 Дополнительная информация

Дополнительная информация может потребоваться, если тип документа должен использоваться в других протоколах, но не требуется для ПОЗ.

ПРИЛОЖЕНИЕ С (справочное). Консультативный материал

ПРИЛОЖЕНИЕ С
(справочное)

С.1 Введение

Первоначально работа ПОЗ была предназначена для обеспечения удаленной автономной обработки. Однако она никак не вписывается в стандартизованный ЯУЗ и в модель какой-либо информации, которая образует "обработку".

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

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

ПОЗ имеет дело с так называемыми "заданиями ВОС". Их не следует путать с традиционными "заданиями", обрабатываемыми в одной машине.

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

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

С.2 Архитектура

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

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

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

С.2.1 Использование СИВ

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

С.2.2 Агентства ПОЗ

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

С.2.2.1 Исходные агентства

"Исходное агентство" ПОЗ становится доступным для поставщика услуг ПОЗ посредством СП J-GIVE. Этот СП выдается (как результат запросов в СР), чтобы запросить названный документ из исходного агентства. Исходное агентство обычно моделирует условное локальное хранилище файлов, но оно может также моделировать некоторую работающую программу, оператора, которого запросили загрузить магнитную ленту, или обработчика ПДУФ, получившего документ удаленным способом. Следует заметить, что на открытые системы, в которых могут выдаваться примитивы J-GIVE, ПОЗ не налагает никаких ограничений. Открытая система А может выдать примитив J-INITIATE, предназначенный для обработки некоторых документов в открытой системе В, а примитивы J-GIVE, предназначенные для получения начальных документов, могут быть выданы в открытой системе А, открытой системе В или в полностью отдельных открытых системах С, D, Е, . . . Протокол ПОЗ упорядочивает необходимые запросы и документы, которые должны быть переданы между системами.

С.2.2.2 Принимающие агентства

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

С.2.2.3 Исполняющие агентства

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

С.2.3 Уровень исполнения

ПОЗ использует так называемый механизм "уровень исполнения" в примитивах СИВ. Элементарное действие, содержащее примитив J-DISPOSE для принимающего или исполняющего агентства, может завершиться с уровнем исполнения:

- ЗАВЕРШЕНИЕ; в этом случае все запрошенные активности (печать или обработка документа) завершаются до выдачи сообщения об исполнении;

- ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА; в этом случае поставщик услуг ПОЗ просто запоминает (с защитой, на диске) сохраняемые запросы в СР и ожидает сигнала от агентства (СП J-END-SIGNAL) о завершении активности.

Если имеет место уровень исполнения ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА, тогда через некоторое время (возможно, в результате вмешательства оператора, указывающего, например, что работа была отправлена) агентство выдает примитив запроса J-END-SIGNAL для информирования поставщика услуг ПОЗ о завершении работы. Если агентство было исполняющим, оно теперь может выдать примитивы J-GIVE, чтобы собрать документы, и указанная СР работа продолжается.

С.2.4 Размещение новых документов

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

Рисунок С.1 - Иллюстрация обработки СР

Рисунок С.1 - Иллюстрация обработки СР

С.2.5 Обеспечение неавтономной обработки

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

С.2.6 Последовательность примитивов

Активность, запрашиваемая инициирующим агентством, в общих случаях вызывает древовидную структуру СП типа "J-", которые должны выдаваться, возможно, параллельно, возможно, последовательно в нескольких различных системах. Эти примитивы выдаются как часть одного или нескольких элементарных действий (в зависимости от требуемого уровня исполнения). Некоторые примеры приведены в С.16.

С.3 Служба отчетности

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

С.3.1 Доставка и размещение

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

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

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

С.3.2 Ответственность за отчетность

Для каждой категории отчетов ответственность за формирование СР для доставки и размещения отчетов остается за одной определенной открытой системой в древовидной структуре элементарных действий СИВ. Открытая система указывается в спецификации протокола ПОЗ и описывается в основной части этого текста.

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

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

С.4 Обработка

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

- отобразить текущее состояние предоставленных ранее СР;

- модифицировать СР, возможно для коррекции ошибок, о которых был послан отчет пунктам монитора;

- опросить пункты монитора, которые сохраняют отчеты, как описано в С.3.1;

- обеспечить контроль оператора над планированием различных передач, по которым услуга ПОЗ выполняет завершение предоставленных ей СР.

Такие взаимодействия также выполняются инициирующим агентством (любым). Кроме того, агентство обеспечивает информацию для СР, но требуемой работой теперь является одна из перечисленных выше операций. Кроме того, агентство может предпочесть установить режим "автономной" активности или (что более типично для подобных случаев) потребовать уровень исполнения ЗАВЕРШЕНИЕ в примитиве J-INITIATE.

С.5 Примитивы J-INITIATE

СП, предоставляющий обычную СР, называется J-INITIATE-WORK. Примитив, запрашивающий отображение или модификацию СР, называется J-INITIATE-WORK-MAN. ("MAN" означает обработку). Примитив, при помощи которого выполняется опрос пунктов мониторов, называется J-INITIATE-REPORT-MAN. Примитив, выполняющий управление передачами, называется J-INITIATE-TCR-MAN. ("TCR" означает ЗУП); управление передачами описано в С.11.6).

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

С.6 Присвоение имен

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

С.7 Аутентификация

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

С.7.1 Информация защиты

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

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

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

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

С.7.2 Оценки доверительности третьей стороны

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

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

- ИЗВЕСТНЫЙ

- АУТЕНТИФИЦИРОВАННЫЙ

Открытая система с уровнем НЕИЗВЕСТНЫЙ является системой, где при обмене данными вызывающему известен только собственный оператор вызова. В некоторых случаях (внутри единой монолитной зоны защиты информации или при невысоких требованиях к защите информации, например, при выводе на печатающее устройство) этого может оказаться достаточно. Открытая система с уровнем ИЗВЕСТНЫЙ - это система, для которой сама сеть обеспечивает адекватный уровень защиты информации для прикладной программы и обеспечивает аутентификационный сетевой адрес, который может быть использован для проверки правильности имени вызываемой открытой системы. Это обычный уровень аутентификации, применяемый в настоящее время к основной массе банковских коммерческих трафиков. Открытая система с уровнем АУТЕНТИФИЦИРОВАНО - это система, для которой методы криптографического кодирования используются с целью защиты обмена данными от вмешательства в данной открытой системе. Определенные протоколы нижнего уровня, которые должны использоваться для получения этого самого высокого уровня аутентификации, находятся вне области ПОЗ и результаты работ по обеспечению защиты информации в ВОС только ожидаются.

С.7.3 Расширение до многосторонних операций

Третий механизм, используемый ПОЗ, состоит в обеспечении так называемой "проверочный трассы". Это список имен открытых систем, каждая из которых помечена как АУТЕНТИФИЦИРОВАННАЯ, ИЗВЕСТНАЯ или НЕИЗВЕСТНАЯ. Если ответственность за выполнение (части) СР ПОЗ передается из одной открытой системы (скажем, А) в другую открытую систему (скажем, В) система А добавляет свое имя в конец проверочной трассы с пометкой НЕИЗВЕСТНАЯ. При получении система В может изменить этот признак на АУТЕНТИФИЦИРОВАННАЯ или ИЗВЕСТНАЯ. Эта проверочная трасса представляет сущность всей защиты ПОЗ от "маскирования". Все признаки "уже проверено" в идентификациях пользователей определяют элемент в проверочной трассе, о котором известно, что проверка уже выполнена. При условии, что сторона известна и "доверяет" всем именам в этой проверочной трассе (с допустимым уровнем аутентификации в каждом пункте), допускается включение признака "уже проверено" в идентификации пользователя.

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

С.7.4 Подлинность инициатора

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

С.8 Терминология ПОЗ

ПОЗ использует термин "задание ВОС" для полной активности, указанной примитивом запроса J-INITIATE.

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

Открытая система, в которой для определенного задания ВОС выдается примитив J-INITIATE, называется "системой предоставления задания ВОС".

Термин "обработка" означает как модификацию СР (или удаление отчетов), так и отображение СР или отчетов.

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

С.9 Параметры заданий ВОС

Ниже описываются так называемые "параметры задания ВОС".

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

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

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

Параметр "проверочная трасса" описан в С.7.3 и формирует основу механизмов защиты информации ПОЗ.

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

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

- защита не требуется;

- требуется обнаружение несанкционированного вмешательства;

- требуется защита от разрушения.

Однако работы по этим вопросам еще не завершены и не входят непосредственно в сферу ПОЗ.

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

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

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

С.10 Идентификация систем административного управления

В идентификациях ПОЗ распознаются два вида САУ: САУ для открытой системы и САУ для "уполномоченного-по-идентификации-пользователя". Проверка правильности таких идентификаций производится так же, как и идентификаций пользователя. Подтвержденное полномочие для САУ "уполномоченного-по-идентификации-пользователя" содержит все привилегии ПОЗ, которыми может обладать любой из ее пользователей. Подтвержденное полномочие для САУ открытой системы допускает как управление передачами ПОЗ, так и модификацию любых СР, содержащихся в этой открытой системе, или поддерживающих эту открытую систему в проверочной трассе, или указывающих эту открытую систему как необходимую для будущей активности. Такие модификации не требуют явных разрешений в списке разрешений.

С.11 Активность ПОЗ (подзадания)

Теперь может быть описана активность, которая может потребоваться в СР. Она может быть представлена в виде набора активностей, организованных в древовидную структуру и называемых "подзаданиями". Древовидная структура активности может быть выполнена либо как одна древовидная структура элементарного действия СИВ, либо в виде каждого подзадания, формирующего отдельное элементарное действие (в зависимости от требуемого уровня исполнения).

С.11.1 Подзадания перемещения документов

Для СР, предоставленных примитивом J-INITIATE-WORK, первое подзадание является подзаданием перемещения документов. Такое подзадание является по существу простым. Оно обеспечивает две несколько различные возможности.

С.11.1.1 Перемещение конкретных поименованных документов

Первая возможность позволяет инициирующему агентству:

- определить одну открытую систему (называемую "целевая система"), которая должна выдавать один или несколько примитивов J-DISPOSE принимающему или исполняющему агентству;

- определять агентства (со всеми необходимыми параметрами идентификации, полномочия и учета) для каждого примитива J-DISPOSE (агентство может выполнить локальное действие или может использовать ПДУФ для удаленного действия);

- определять (как определено ниже) документы, которые должны быть переданы каждому агентству в примитиве J-DISPOSE, и имена этих документов в принимающем агентстве.

Один и тот же документ может быть передан в нескольких примитивах J-DISPOSE (средства дублирования ПОЗ).

Каждый документ указывается как набор частей документа (средство сцепления ПОЗ). Каждая часть документа обеспечивается в примитиве J-INITIATE или идентифицируется при помощи:

- спецификации для каждой части документа открытой системы (открытая система действия), которая должна собрать часть документа, выдавав примитив J-GIVE в те агентства, которые могут обращаться к этому документу (локально или при помощи ПДУФ);

- спецификации агентства (со всеми необходимыми параметрами идентификации, полномочий и учета) для примитива J-GIVE;

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

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

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

С.11.1.2 Перемещение групп документов

Вторая возможность позволяет инициирующему агентству:

- указать, чтобы целевая система выдала примитив J-DISPOSE (к одному агентству) для каждой группы документов;

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

Эта форма подзадания особенно полезна для перемещения всех файлов, указанных в одном и том же подсправочнике, или для сбора всей выводимой из задания информации, когда неизвестны точные имена файлов/документов. Поставщик услуг ПОЗ узнает имена текущих документов, используя примитив J-ENQUIRE для исходного агентства. Затем, чтобы получить документы, следует серия примитивов J-GIVE. Часть имени документа в исходном агентстве используется при формировании имени документа для принимающего агентства.

С.11.2 Завершение подзадания и порождение проформы

Подзадание готово для завершения, когда все определенные в нем примитивы J-DISPOSE указали готовность, предложив исполнение уровнем ЗАВЕРШЕНИЕ, или более поздним примитивом запроса J-END-SIGNAL из принимающего или исполняющего агентства. В этот момент одно или несколько новых подзаданий инициируется поставщиком услуг ПОЗ. Эти подзадания формируются как часть элементарного действия примитива J-DISPOSE, то есть как элементарное действие более раннего подзадания или элементарное действие примитива J-END-SIGNAL, то есть новое элементарное действие. Эти новые подзадания были определены в начальной СР, созданной примитивом J-INITIATE. Это осуществляется при помощи подпараметров в примитиве J-INITIATE, называемых "проформами". Каждая проформа содержит "имя проформы" и дальнейшую спецификацию подзадания перемещения документа, как было описано выше.

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

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

Предыдущее обсуждение концентрировалось на том, что называется "порождение конца активности". Однако возможно также, что исполняющее агентство до завершения своей работы может выдать примитив J-SPAWN, чтобы породит из поименованной проформы для распределения некоторых документов, которые уже являются доступными. Такое действие называется "порождение запроса". Третье дополнительное действие называется "порождение принятия", предпринимаемое поставщиком услуг ПОЗ, когда все примитивы J-DISPOSE предоставили агентству уровень исполнения ПРИНЯТИЕ (или более высокий).

С.11.3 Обеспечение непрерывной активности

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

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

- факультативный элемент разрешения для его освобождения при помощи обработки;

- местоположение, где должно быть применено удержание (обычно или в области порождения, блокируя примитивы J-GIVE и передачи, или в области целевой системы, блокируя примитивы J-DISPOSE);

- факультативную читабельную причину для удержания;

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

С.11.4 Подзадания "выполнение-работы"

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

ВЫБОР - либо не выбирать ни одной, либо выбрать одну или несколько СР, за которые данная открытая система несет ответственность; выбор определяется общим логическим выражением, включая тесты почти на любое поле в СР;

УНИЧТОЖЕНИЕ - выбранные СР удаляются; любая соответствующая активность в принимающих или исполняющих агентствах завершается при помощи примитива J-KILL, а СР сбрасывается;

ОСТАНОВ - выбранные СР не выполняются, но любые соответствующие принимающие и исполняющие агентства посылают сигнал J-STOP; предполагается, что агентства должны "немедленно" завершить свою работу (возможно, обеспечивая вывод информации); подробности зависят от PC;

МОДИФИКАЦИЯ - указанные поля в выбранной СР изменяются или дополняются; количество модифицируемых полей меньше количества выбираемых полей;

ОТОБРАЖЕНИЕ - выбранные СР должны быть отображены при создании форматированного определенного ПОЗ документа; документ "собирается" от поставщика услуг ПОЗ включением одной или нескольких проформ (обычный тип "перемещение-документа") в СР.

С.11.5 Спецификация работы "управление отчетами"

СР J-INITIATE-REPORT-MAN указывает целевую систему, которая является пунктом монитора, и запрашивает либо отображение (в документе, собранном проформами), либо удаление отчетов, которые были собраны. Кроме того, к активности применяются механизмы полномочий. (На рисунке С.2 показаны некоторые аспекты активности ПОЗ).

Рисунок С.2 - Активность ПОЗ

Рисунок С.2 - Активность ПОЗ

С.11.6 Спецификации работы "управление передачами"

СР J-INITIATE-TCR-MAN обеспечивает управление (определяемое полномочиями) со стороны любой открытой системы так называемыми записями управления передачей, содержащимися в любой другой открытой системе.

C.11.6.1 Модель ЗУП

Модель ПОЗ, в основе которой лежит управление передачами, приведена ниже.

В некоторый момент времени открытая система А должна выполнить некоторое количество передач к открытой системе В, каждый раз передавая ответственность за выполнение СР системе В. САУ в системе В требует осуществлять некоторый контроль над этими передачами. Типичными примерами подобной ситуации являются:

- попросить систему А прекратить попытки, либо потому, что система В неожиданно была отключена, либо система В принимает инициативу по запросу указанной передачи, либо система В является мобильной системой, отключившей себя в данный момент от сети;

- попросить систему А ничего не предпринимать из того, что запросит конкретное устройство в системе В, поскольку оно неисправно;

- попросить систему А не пытаться выполнять более трех одновременных передач системе В, если только одна из них не имеет высокий приоритет (другой параметр примитива J-INITIATE), либо передается отчет или обработка задания.

Эти требования поддерживаются наличием в системе А концептуальной структуры данных, называемой записью управления передачей (ЗУП), управляющей передачами к системе В. Если ЗУП не устанавливается, действия системы А не ограничиваются и зависят от PC. Если она устанавливается, то либо не содержит, либо содержит один или несколько селекторов. Эти селекторы точно такие же, которые использовались в операции выполнения работы ВЫБОР для выбора одной или нескольких СР с использованием многообразия полей в них. (Обеспечивается также выбор, использующий время ожидания и размер).

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

С.11.6.2 Операции ЗУП

СР, предоставленная примитивом J-INITIATE-TCR-MAN, указывает целевую систему и ЗУП в той системе, которая должна обрабатывать. Запись может быть помещена (операция УСТАНОВКА) или отображена (операция ОТОБРАЖЕНИЕ) в документе при его сборке проформой.

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

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

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

Рисунок С.3 - Пример обработки ЗУП третьей стороной

Рисунок С.3 - Пример обработки ЗУП третьей стороной

В этом примере центр САУ системы "А" будет обеспечивать ПОЗ базового класса, расширенную, по меньшей мере, добавлением до функции обработки ЗУП; спул главной системы "В" будет обеспечиваться ПОЗ базового класса, расширенной, по меньшей мере, дополнением до функции ЗУП; устройство управления печатью системы "С" будет обеспечиваться только ПОЗ базового класса.

С.11.7 Иллюстрация

Рисунок С.4 иллюстрирует простое использование ПОЗ, эквивалентное нестандартной операции "удаленный ввод заданий" (УВЗ) (небольшое подмножество возможностей ПОЗ).

Рисунок С.4 - Иллюстрация использования ПОЗ при традиционной активности задания

Рисунок С.4 - Иллюстрация использования ПОЗ при традиционной активности задания

С.12 Действия при ошибках

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

Первое действие применимо только к ошибкам, появившимся с результатом попытки выполнить примитив J-GIVE (например, ошибкам "файл не существует", "недостаточные полномочия" и т.д.). При запросе такого действия диагностика СИВ из примитива J-GIVE вкладывается в СР вместо документа и со временем будет передана в принимающее и исполняющее агентства в примитиве J-DISPOSE. Основное элементарное действие, выдавшее примитив J-GIVE, продолжается нормально с примитивом C-READY, но включается предупреждающий отчет СИВ. Отчет ПОЗ может быть также выработан, если была запрошена такая категория отчетности.

Второе и третье действия выполняются ГУЛО элементарного действия, когда от* получает диагностику СИВ в примитиве C-REFUSE. Если запрашивается второе действие, элемент удержания добавляется к СР и в дальнейшем не выполняется до тех пор, пока не будет исправлена ошибка и не будет снято удержание. (Если удержание заканчивается до модификации и ошибка сохраняется, выполняется третье действие, см. ниже). Добавление элемента удержания (не выполнять) является событием, которое может быть выбрано для отчетности.
___________
* Текст соответствует оригиналу. - Примечание "КОДЕКС".

Третье действие просто аварийно завершает СР, устанавливая диагностику СИВ в отчете "аварийное завершение".

С.13 Документы

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

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

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

Наконец, ПОЗ может запросить и содержать любые документы, которые имеют:

- зарегистрированное имя (тип документа);

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

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

Другим важным свойством ПОЗ является распознавание PC "обеспечение хранения". PC ПОЗ предоставляет "обеспечение хранения" для типа документа, если примитив J-GIVE, следующий за примитивом J-DISPOSE для любого конкретного документа этого типа, имеет результатом идентичное выдаваемое значение. В общем случае те PC, которые не предусматривают возможность обеспечения хранения, например, для документов типа ДВОИЧНЫЙ, могут дополнить битовую строку до размера, кратного восьми битам.

С.14 Ретрансляционные системы ПОЗ

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

Эта простая ситуация неадекватна в следующих четырех случаях:

- обе системы поочередно подключаются к сетям и никогда не подключены одновременно;

- обе системы работают в различных временных зонах и никогда не работают одновременно;

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

- не обеспечены документы, которые должны быть собраны из ретрансляционных систем, и не обеспечивается удаленный доступ к таким системам при помощи (например) ПДУФ.

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

На рисунке С.5 показана обработка подзадания при передаче его к своей целевой системе через ретрансляционную систему. Документы собираются при помощи примитива J-GIVE во всех трех системах.

Рисунок С.5 - Обработка подзадания через ретрансляционные системы ПОЗ

Рисунок С.5 - Обработка подзадания через ретрансляционные системы ПОЗ

На рисунках С.6 и С.7 показаны альтернативные подзадания, которые путем использования ПДУФ дают аналогичные результаты, но с различными временами связок для документов. Различия в подзаданиях определяются в спецификации <действий открытой системы> и в использовании или неиспользовании ПДУФ.

Рисунок С.6 - Обработка подзадания с поздним соединением

Рисунок С.6 - Обработка подзадания с поздним соединением

Рисунок С.7 - Обработка подзадания с ранним соединением

Рисунок С.7 - Обработка подзадания с ранним соединением

С.15 Протоколы доступа к агентству

В начальных стандартах ПОЗ "Действие открытой системы" получаст документы путем использования СП J-GIVE (который может вызвать использование ПДУФ). Целевая открытая система размещает документы путем использования примитива J-DISPOSE (который может вызвать использование ПДУФ).

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

Будет предусмотрено также обеспечение примитивов J-ENQUIRE, J-HOLD, J-END-SIGNAL и др., которые не обеспечиваются ПДУФ.

С.16 Временные соотношения между сервисными примитивами

Последовательность СП ПОЗ, формирующая группу исполнения операций J-INITIATE, целиком представлена в одном пункте доступа к услугам.

Если уровнем исполнения для этой группы является ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА (самый низкий из возможных), тогда нет необходимости выдавать примитивы в любой другой пункт доступа к услугам до тех пор, пока не завершится группа исполнения операций J-INITIATE.

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

Подзадание ПОЗ может включать (например) группы примитивов J-INITIATE, J-DISPOSE и две группы J-GIVE в четырех различных пунктах доступа к услугам.

Даже в случае исполнения с уровнем ЗАВЕРШЕНИЕ возможны значительные расхождения во временной последовательности элементов групп примитивов в различных пунктах доступа к услугам. На рисунке С.9 показаны возможные последовательности примитивов при помощи диаграммы временной последовательности (см. приложение А) для потока обработки, показанного на рисунке С.8.

Рисунок С.8 - Пример потока обработки для уровня исполнения ЗАВЕРШЕНИЕ

Рисунок С.8 - Пример потока обработки для уровня исполнения ЗАВЕРШЕНИЕ

Рисунок С.9 - Пример последовательности примитивов для уровня исполнения ЗАВЕРШЕНИЕ

Рисунок С.9 - Пример последовательности примитивов для уровня исполнения ЗАВЕРШЕНИЕ

Следует заметить, что включение исполнения с уровнем ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА ослабляет еще больше временные ограничения, налагаемые на последовательности примитивов. Показанная на рисунке С.8 конкретная последовательность может, однако, все еще иметь место - PC может всегда попытаться обратиться к более высокому уровню исполнения по сравнению с запрошенным.

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

С.17 Подмножества и соответствие

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

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

СР базового класса и соответствующий элемент протокола являются определенным подмножеством общего случая. Расширенная PC и PC базового класса будут взаимодействовать в том случае, если примитив J-INITIATE гарантирует, что достаточно ограниченные подзадания передаются в PC базового класса (см. С.18).

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

Вторая форма подмножества содержится в характере поддержки агентства, обеспечиваемого PC. Определенная PC может быть предусмотрена для работы только в качестве инициирующего агентства. Это называется "поддержкой для предоставления задания ВОС ПОЗ". Другая PC может быть предусмотрена для работы только определенного устройства в качестве пункта монитора ПОЗ. Следующая PC может обеспечивать использование одного (но, возможно, не всех) из своих печатающих устройств в качестве принимающего агентства ПОЗ. Некоторая PC может обеспечивать все СП ПОЗ при помощи вызовов подпрограмм из программы пользователя на языке ФОРТРАН (но, возможно, не из программ на языке КОБОЛ). Это будет называться "поддержка ПОЗ на языке xyz". Последнее служит примером обеспечения человеку возможности принимать сообщение о документах для обработки и сигнализировать о завершении обработки - "поддержка ПОЗ для обработки человеком".

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

С.18 Взаимодействие базовых и расширенных реализаций

PC базового класса обеспечивает выдачу в своей системе примитивов базового класса и обработку СР базового класса.

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

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

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

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

Рисунок С.10 - Взаимодействие

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

Рисунок С.10 - Взаимодействие

В таблице C.1 представлены (для одного задания ВОС) возможные комбинации функциональных возможностей примитива J-INITIATE, элементы передачи, принятые PC во время выполнения задания ВОС, и результирующие элементы передачи.


Таблица С.1 - Комбинации функциональных возможностей базового и расширенного классов

С.19 Протокол ПОЗ

Спецификация протокола ПОЗ состоит из трех основных частей:

- определение абстрактного синтаксиса передачи (с использованием АСН.1) структуры данных, используемой для передачи СР, при которой получатель информации вместе с проформами и документами в настоящий момент находится в "выделенной части";

- детальные процедурные операторы по действиям, которые должны быть выполнены PC ПОЗ при выдаче примитива запроса J-INITIATE или при приеме вышеописанной структуры данных; эти действия включают в себя задачу (как часть элементарного действия СИВ) примитива J-GIVE и/или J-DISPOSE, порождение, формирование отчетов и так далее;

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

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

С.20 Примеры механизма назначения полномочий

Рассмотрим следующий пример. Пользователь в области А предоставляет СР, содержащую одну проформу, чтобы выполнить задание в области В и выдать результат в область А. Пользователь имеет следующие присвоенные ему имена пользователя: в области А имя пользователя USERA и пароль PASSA, а в области В имя пользователя USERB и пароль PASSB. Имеется четыре случая, которые следует рассмотреть в отношении того, какая область какой области доверяет:

СЛУЧАЙ А - Область А доверяет области В, а область В доверяет области А;

СЛУЧАЙ В - Область А доверяет области В, а область В не доверяет области А;

СЛУЧАЙ С - Область А не доверяет области В, а область В доверяет области А;

СЛУЧАЙ D - Область А не доверяет области В, а область В не доверяет области А.

С.20.1 Определение доверия

Когда СР появляется в области В, проверочная трасса будет иметь один элемент, а именно, элемент области А. Значением состояния будет НЕИЗВЕСТНЫЙ; область В использует сведения об имеющихся сетях и/или методах кодирования, чтобы (возможно) перевести это полученное значение в значение ИЗВЕСТНЫЙ или АУТЕНТИФИЦИРОВАННЫЙ. Область В имеет список областей, которым она будет "доверять, если АУТЕНТИФИЦИРОВАННЫЙ, "доверять, если ИЗВЕСТНЫЙ" или "доверять, даже если НЕИЗВЕСТНЫЙ". Это зависит от того, доверяет ли область В области А. Списки формируются (вручную) в САУ.

Когда (порожденная) СР возвращается обратно в область А, она содержит два элемента проверочной трассы - один для области А, за которым следует один элемент для области В. Область А вначале определяет, доверяет ли она последней области (область В) в проверочной трассе (как описано выше). Если она доверяет последней области, она затем определяет, доверяет ли она предпоследней области (область А) в проверочной трассе, основываясь на оценке значений НЕИЗВЕСТНЫЙ, ИЗВЕСТНЫЙ или АУТЕНТИФИЦИРОВАННЫЙ для области В и своих сведениях об области В. Если она не доверяет последней области, она автоматически не может доверять любой другой области в проверочной трассе до тех пор, пока область, которой не было оказано доверие, не внесет изменения (определением) в любые более ранние элементы в проверочной трассе, таким образом делая ее недействительной.

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

С.20.2 Необходимые списки полномочий

С.20.2.1 Случай А (обе области доверяют друг другу)

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

Когда СР поступает в область В, то поскольку область В доверяет (только) области в проверочной трассе, она изъявляет желание воспринять элемент полномочий

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

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

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

С.20.2.2 Случай В (область В не доверяет области А)

Когда СР поступает в область В, то поскольку область В не доверяет области А, она будет требовать следующий элемент полномочий

прежде, чем она сможет обрабатывать СР. Поэтому пользователь предоставляет свое имя и пароль для области В при предоставлении задачи ПОЗ в области А.

Когда (порожденная) СР с выходной информацией поступает в область А, область А доверяет обеим областям в проверочной трассе и поэтому она будет удовлетворена следующим элементом полномочий

область A USERA 1,

как и в приведенном выше случае А.

С.20.2.3 Случай С (область А не доверяет области В)

В этом случае при предоставлении задачи ПОЗ пользователю необходимо включить свой собственный пароль и имя пользователя для области А, но только единственное имя пользователя для области В, предоставляя следующий список полномочий:

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

С.20.2.4 Случай D (ни одна из областей не доверяет друг другу)

Пользователь предоставляет имена пользователей и пароли для обеих областей А и В, поскольку ни одна область не доверяет другой и ее "маскараду".

С.20.3 Общие пункты

Если пользователь всегда предоставляет имена пользователя и пароли для обеих областей, СР всегда будут иметь достаточное полномочие независимо от того, доверяют области друг другу или нет; цель механизмов доверия - освободить ПОЗ от необходимости содержания паролей, вложенных в свои СР, и избежать забот, которые заставляют человека запоминать несколько паролей.

С.20.4 Иллюстрация

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


Таблица С.2 - Значение списка полномочий и проверочная трасса в примерном сценарии

ПРИЛОЖЕНИЕ D (справочное). Словарь терминов

ПРИЛОЖЕНИЕ D
(справочное)

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

D.1 Агентство - абстрактное описание таких функциq среды локальной системы, которые необходимы для обеспечения услуг ПОЗ.

D.2 Активность (в агентстве) - работа, выполняемая каким-либо агентством, инициируемым СП, выданным в это агентство поставщиком услуг ПОЗ; завершение этой активности указывается СП, выданным этим агентством поставщику услуг ПОЗ.

D.3 Аутентифицируемая идентификация - известные данные, необходимые для правильной идентификации пользователя или САУ, по запросам которых должна выполняться работа путем использования проверки пароля или некоторого другого механизма проверки.

D.4 Данные управления порождением - данные, содержащиеся в проформе, которая управляет состояниями, при которых имеет место порождение из этой проформы.

D.5 Диагностика "не повторять" - информация, передаваемая услугой СИВ при возврате в исходное состояние, когда действие не может быть завершено, а последующая повторная попытка не предполагается.

D.6 Диагностика "повторить позже" - информация, передаваемая услугой СИВ при возврате в исходное состояние, когда действие не может быть завершено по кратковременным причинам.

D.7 Документ - совокупность данных, образующих часть СР и блок взаимодействия между поставщиком услуг ПОЗ и агентством.

D.8 Задание ВОС - общая работа во всех открытых системах, являющаяся непосредственно или косвенно результатом обработки начальной СР.

D.9 Запись управления передачами - концептуальная структура данных, сохраняемая открытой системой для управления передачей СР и выдачи СП.

D.10 Идентификатор спецификации работы - уникальный указатель для СР, который содержит имя системы предоставления задания ВОС, идентификацию инициирующего пользователя, локальный указатель задания ВОС и имя задания ВОС; если СР была создана порождением, идентификатор также содержит одно или несколько имен проформы.

D.11 Идентификатор инициирования - идентификация, обеспечиваемая поставщиком услуг ПОЗ во время предоставления для того, чтобы идентифицировать инициатора задания ВОС.

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

D.13 Идентификация пользователя - данные, которые могут использоваться в определенном контексте, чтобы идентифицировать пользователя, от имени которого должна запрашиваться работа.

D.14 Идентификация уполномоченного по идентификации САУ - имя уполномоченного по идентификации, который будучи аутентифицирован, выдает полномочия активностям ПОЗ, относящимся к управлению активностью, инициируемой идентификаторами пользователя, которые выдает этот уполномоченный.

D.15 Идентификация САУ открытыми системами - имя открытой системы, которая, будучи аутентифицирована, уполномочивает активности ПОЗ или затраты, отнесенные к САУ этой открытой системы.

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

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

D.17 Имя задания ВОС - последовательность знаков, предоставляемая инициирующим агентством во время предоставления задания ВОС.

D.18 Инициирующее агентство - агентство, которое вызывает создание СР.

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

D.20 Исходное агентство - некоторая часть открытой системы, которая может представить документы в результате обработки СР для включения в СР при их запросе поставщиком услуг ПОЗ.

D.21 Локальный указатель задания ВОС - указатель задания ВОС, который является уникальным внутри системы предоставления задания ВОС, назначаемый этой открытой системой.

D.22 Мониторы задания ВОС - открытые системы, в которые посылаются отчеты ПОЗ об определенном задании ВОС.

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

D.24 Обновление - данные, которые используются для модификации выбранной СР или проформы.

D.25 Операции выполнения работы - операции, которые выбирают одну или несколько СР или проформ и запрашивают отображение, уничтожение, останов или модификацию.

D.26 Операции управления передачами - операции, запрашивающие ЗУП для установки, отображения или проверки.

D.27 Операции управления отчетностью - операции, запрашивающие удаление или отображение отчетов, сохраняемых открытыми системами, назначенные некоторой СР в качестве пункта монитора.

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

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

D.30 Порождение - процесс получения данных из проформы и использования их для формирования новой СР.

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

D.32 Предъявление задания ВОС - использование СП инициирования инициирующим агентством для создания начальной СР.

D.33 Принимающее агентство - некоторая часть открытой системы, в которую в результате обработки СР могут быть переданы документы поставщиком услуг ПОЗ.

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

D.35 Проформа верхнего уровня - проформа, не содержащая внутри никакой другой проформы.

D.36 Селектор - данные, используемые для указания выбора СР.

D.37 Система предоставления задания ВОС - открытая система, в которой имеет место предоставление задания ВОС.

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

D.39 Спецификация выполнения работы - СР, содержащая операции выполнения работы.

D.40 Спецификация управления передачами - СР, содержащая операции управления передачами.

D.41 Спецификация выполнения отчетов - тип СР, созданной поставщиком услуг ПОЗ для перемещения отчетов ПОЗ; целевая открытая система для таких СР представляет собой один из мониторов задания ВОС.

D.42 Спецификация работы управления отчетами - СР, содержащая операции управления отчетами.

D.43 Уведомление ПОЗ - закодированная информация, регистрирующая обработку или сбой задания ВОС, сформированная поставщиком услуг ПОЗ, возможно, в результате взаимодействия с агентством.

D.44 Уровень исполнения - параметр, который определяет либо необходимость выполнения операций, затребованных в элементарном действии, во время элементарного действия, либо необходимость пометить эти операции (как сохраняемые данные) для последующего выполнения.



Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 1999