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

Группа П85

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

Информационная технология ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ. КОНЦЕПЦИИ И УСЛУГИ ДЛЯ ПЕРЕДАЧИ И ОБРАБОТКИ ЗАДАНИЙ

Information technology Open Systems Interconnection.

Job Transfer and Manipulation concepts anb services

ОКСТУ 0034

Дата введения 01.01.94

ВВЕДЕНИЕ

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

Раньше фоновые задания представлялись для рассмотрения непосредственно в главной системе, где они запускались для выполнения, или в станции удаленного ввода заданий, подсоединенной к этой системе. Файлы данных, программа и язык «JCL» (Job Control Language — язык управления заданием) должны быть доступны главной системе, или должна быть сформирована часть представленной для рассмотрения «колоды задания». Выходные данные должны быть переданы в главную систему или альтернативно на печатающее устройство, подсоединенное к станции удаленного ввода заданий. В сети открытых систем такие задания могут быть предъявлены на рассмотрение в любую открытую систему, обеспечивающую службу ПОЗ для того, чтобы они были выполнены в другой открытой системе, используя файлы, собранные из каких-либо других открытых систем, с выходными данными, направленными к периферийным устройствам, или используя фай-лы, содержащиеся в каких-либо других открытых системах.______

Издание официальное

★

© Издательство стандартов, 1993

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен без разрешения Госстандарта России

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

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

• 1.1. Назначение

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

Стандарт определяет концепции и услуги для передачи и обработки заданий.

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

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

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

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

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

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

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

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

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

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

ИСО 2375¹ «Обработка данных. Процедуры регистрации выходной последовательности».

ГОСТ 28906 (ИСО 7498) «Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель».

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

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

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

ИСО 8832² «Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола базисного класса для передачи и манипулирования заданиями».

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

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

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

• 1.3.1. Определения услуг элемента СПиВ

В настоящем стандарте применены термины, определенные в ИСО 9804:

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

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

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

г) управляемый логический объект;

д) совершение операций;

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

• 1.3.2. Определения услуг службы ПОЗ

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

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

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

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

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

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

• 1.3.2.1.4. Инициирующее агентство (initiation agency) — такое агентство, которое вызывает создание спецификации работы.

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

• 1.3.2.2.1. Проформа (proforma) — часть спецификации работы, которая указывает дальнейшую работу и используется для формирования новой спецификации работы как части выполнения более ранней работы.

• 1.3.2.2.2. Порождение (spawning) — процесс получения данных из проформы и использования их для формирования новой спецификации работы.

• 1.3.2.2.3. Данные управления порождением (spawning control data) — данные, содержащиеся в проформе и управляющие состояниями, при которых имеет место порождение из этой проформы.

1.3.2 2.4. Проформа верхнего уровня (top level proforma) — проформа, которая не содержится внутри никакой другой проформы.

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

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

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

• 1.3.2.3.2. Принимающее агентство (sink agency) — какая-либо часть открытой системы, в которую в результате обработки спецификации работы поставщиком услуг службы ПОЗ могут быть переданы документы.

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

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

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

• 1.3.2.4. Задания модели ВОС.

• 1.3.2.4.1. Начальная спецификация работы (initial work specification) — спецификация работы, созданная в результате введения инициирующим агентством сервисного примитива инициирования.

• 1.3.2.4.2. Задание модели ВОС (OSI job) — общая работа во всех открытых системах, являющаяся непосредственно или косвенно результатом обработки начальной спецификации работы.

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

• 1.3.2.4.4. Предъявление задания модели ВОС (OSI job submission) — использование сервисного примитива инициирования инициирующим агентством для создания начальной спецификации работы.

• 1.3.2.4.5. Система предъявления задания модели ВОС (OSI job submission system) — открытая система, в которой имеет место предъявление задания модели ВОС.

• 1.3.2.5. Уведомляющая служба и функция монитора.

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

• 1.3.2.5.2. Мониторы задания модели ВОС (OSI job monitors) — открытые системы, в которые посылаются уведомления службы ПОЗ о состоянии определенного задания модели ВОС.

• 1.3.2.5.3. Спецификация работы по уведомлению (report work specification) — тип спецификации работы', созданной поставщиком услуг службы ПОЗ для перемещения уведомлений службы ПОЗ; целевая открытая система для таких спецификаций работы представляет собой открытую систему мониторов задания модели ВОС.

• 1.3.2.6. Совершение операций, согласованность действий и восстановление после ошибок.

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

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

• 1.3.2.6.3. Диагностическое сообщение «Повторить позже» (retry-later diagnostic) — информация, передаваемая услугой элемента СПиВ при отказе совершения операции, когда действие не может быть завершено по причинам, которые могут быть кратковременными.

• 1.3.2.6.4. Диагностическое сообщение «Не повторять» (по — retry diagnostic) — информация, передаваемая услугой элемента СПиВ при отказе совершения операции, когда действие не может быть завершено, а позже попытка повторного выполнения не предполагается.

• 1.3.2.7. Управление передачей.

• 1.3.2.7.1. Передача спецификации работы (work specification transfer) — элементарное действие, при котором спецификация работы создается в принимающей открытой системе и разрушается в посылающей открытой системе.

• 1.3.2.7.2. Запись управления передачей (transfer control record) — концептуальная структура данных, сохраняемая открытой системой, для управления передачей спецификаций работы и введением сервисных примитивов.

• 1.3.2.8. Манипулирование уведомлениями.

• 1.3.2.8.1. Операции манипулирования уведомлениями (report manipulation operations) — операции, запрашивающие удаление или отображение уведомлений, сохраняемых открытой системой, назначенной некоторой спецификацией работы в качестве пункта монитора.

• 1.3.2.8.2. Спецификация работы по манипулированию уведомлениями (report manipulation work specification) — спецификация работы, содержащая операции манипулирования уведомлениями.

• 1.3.2.9. Манипулирование работой.

• 1.3.2.9.1. Операции манипулирования работой (work manipulation operations) — операции, которые выбирают одну или несколько спецификаций работы или проформ и запрашивают отображение, уничтожение, остановку пли модификацию.

• 1.3.2.9.2. Спецификация работы по манипулированию работы (work manipulation work specification) — спецификация работы, содержащая операции манипулирования работой.

L3.2.9.3. Селектор (selektor) — данные, которые используются для указания либо не выбирать, либо выбрать одну или несколько спецификаций работы.

• 1.З.2.9.4. Корректировка (update) — данные, которые используются для модификации выбранной спецификации работы или проформы.

• 1.3.2.10. Манипулирование передачей.

• 1.3.2.10.1. Операции манипулирования передачей (trasfer manipulation operations) — операции, запрашивающие записи управления передачей для установки, отображения или проверки этих записей.

• 1.3.2.10.2. Спецификация работы по манипулированию передачей (transfer manipulation work specification) — спецификация работы по манипулированию, содержащая операции манипулирования передачей.

• 1.3.2.11. Санкционирование и учет.

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

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

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

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

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

• 1.3.2.11.5. Идентификация системы административного управления открытыми системами (open system management identification) — имя открытой системы, которая, если она аутентифицирована, санкционирует активности службы ПОЗ или расходы, отнесенные к системе административного управления этой открытой системой.

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

• 1.3.2.11.6. Идентификация системы административного управления идентификационными санкциями (identification authority management identification) — имя идентификационной санкции, которая, если она аутентифицирована, санкционирует активности службы ПОЗ, имеющие отношение к управлению активностью, инициируемой идентификациями пользователя, вводимыми при помощи такой санкции.

• 1.3.2.12. Идентификация спецификации работы.

• 1.3.2.12.1. Локальный указатель задания модели ВОС (OSI job local referense) — указатель для задания модели ВОС, который является уникальным внутри системы предъявления задания модели ВОС, назначенной этой открытой системой.

• 1.3.2.12.2. Идентификация инициирования (initiating identification) — идентификация, обеспечиваемая пользователем службы ПОЗ во время предъявления задания, чтобы идентифицировать инициатора задания модели ВОС.

• 1.3.2.12.3. Имя задания модели ВОС (OSI job name) — строка знаков, предоставляемая инициирующим агентством во время предъявления задания модели ВОС.

• 1.3.2.12.4. Идентификатор спецификации работы (work specification identifier) — уникальный указатель для спецификации работы, который содержит имя системы предъявления задания модели ВОС, идентификацию инициирующего пользователя, локальный указатель задания модели ВОС и имя задания модели ВОС; если спецификация работы была создана порождением, идентификатор также содержит одно или несколько имен проформы.

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

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

OSI (Open systems interconnection);

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

JTM (Job transfer and manipulation);

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

FTAM (File transfer, access and management);

СПиВ Совершение, параллельность и восстановление —

CCR (Commitment, concurrency and recovery).

• 1.5. Соглашения

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

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

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

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

2.1.1 Обзор

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

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

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

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

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

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

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

б) санкционирования работы;

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

г) выбора требуемых уведомлений;

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

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

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

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

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

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

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

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

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

Поля «идентификация инициирующего агентства (initiating identification)» и «время предъявления (time of submission)» формируются при создании спецификации работы в результате предъявления задания инициирующим агентством. Эти поля копируются, когда новые спецификации работы создаются службой ПОЗ в результате обработки предыдущих спецификаций работы.

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

Может быть указано поле «мониторы задания модели ВОС (OSI job monitors)»; мониторы — это открытые системы, в которые должны быть посланы выбранные уведомления.

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

Поле «тип спецификации работы (type of work specification)» определяется в соответствии с различными типами начальной работы, которая должна быть выполнена. Наиболее важным типом является спецификация работы по перемещению документа, которая содержит данные о перемещении документов пользователя между открытыми системами. Другие типы спецификаций содержат данные для перемещения уведомлений и манипулирования; они будут рассмотрены позже.

Поле «целевая открытая система (target)» указывает такую открытую систему, которая выполняет заключительную обработку начальной работы и которая может формировать новые спецификации работы для дальнейшей работы.

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

Могут быть указаны поля «срочность (urgency)» и «задержка» выполнения требуемой работы.

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

Поле «дальнейшая работа (further work)» содержит данные в формате, который допускает создание целевой открытой системой новых спецификаций работы.

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

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

С. 12 ГОСТ Р 34.1983—03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 2.1.5. Задания модели ВОС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в) при попытке передать спецификацию работы;

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

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

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

• 2.1.7. Уведомляющая служба и функция монитора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

б) передача спецификации работы из одной открытой системы в другую открытую систему;

в) формирование новой спецификации работы с помощью порождения;

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

д) нормальное завершение обработки спецификации работы, выполняемое после завершения подзадания;

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

ж) удаление спецификации работы и завершение подзадания вследствие запроса на манипулирование (KILL (УНИЧТОЖИТЬ));

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

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

к) задержка спецификации работы для корректировки ошибок;

л) аварийное завершение обработки спецификации работы вследствие ошибок;

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

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

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

п) попытка модификации спецификации работы подзаданием, которое не имеет необходимое санкционирование;

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

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

а) имя открытой системы, формирующей уведомление (см. п. 2.1.14);

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

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

г) дата и время формирования уведомления (необязательно);

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

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

• 2.1.8. Совершение, параллельность и восстановление

• 2.1.8.1. Обзор.

Для того, чтобы .обеспечить правильное выполнение услуги службы ПОЗ при наличии сбоев в прикладном процессе или в системе связи (восстановление после ошибок), свободу от влияния со стороны других активностей (управление параллельным выполнением активностей) и возможность выполнения задания модели ВОС как одного или нескольких элементарных действий (совершение операций), используются процедуры элемента «Совершение, параллельность, восстановление» (элемент CCR — Commitment, Concurrency and Recovery), определенные в стандарте ИСО 9804.

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

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

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

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

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

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

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

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

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

• 2.1.8.2.1. Уровень совершения операций «Завершение» (уровеньЗ).

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

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

Та^ой уровень совершения операций иногда описывается как «неавтономная» обработка.

• 2.1.8.2.2. Уровень совершения операций «Принятие агентством» (уровень 2).

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

• 2.1.8.2.3. Уровень совершения операций «Принятие поставщиком» (уровень 1).

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

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

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

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

• 2.1.8.3. Тайм-ауты.

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

С 22 ГОСТ Р 34.1983-93

тояние, если этот таймер истекает; он может использовать параметры элемента СПиВ, чтобы указать такое намерение своим управляемым логическим объектам.

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

Данные пользователя содержат параметр «Уровень совершения операций» и параметр «Индикатор кода диагностики».

• 2.1.8.4.1. Уровень совершения операций.

Параметр «Уровень совершения операций» является целым числом (см. п. 2.1.8.2). Самым нижним уровнем совершения операций, является уровень 1. Наивысшим является уровень 3.

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

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

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

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

Параметр «Таймер элементарного действия» (см. стандарт ИСО 9804) позволяет управляемому логическому объекту оптимизировать свои действия таким образом, чтобы сначала сделать попытку использования более высокого уровня совершения операций, а затем перейти на более низкий уровень.

• 2.1.8.4.2. Индикатор кода диагностики.

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

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

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

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

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

• 2.1.8.5. Использование данных пользователя элемента СПиВ при обеспечении совершения операций.

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

• 2.1.8.5.1. Уровень совершения операций.

Формат параметра «Уровень совершения операций» описывается в п. 2.1.8.4.1. Его значение в сообщении о совершении операций выше или равно значению при запуске элементарного действия.

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

• 2.1.8.5.2. Параметр «Диагностическое сообщение».

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

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

б) кода диагностического сообщения службы ПОЗ;

С. 24 ГОСТ.Р 311983-93

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

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

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

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

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

Примечания:

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

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

• 2.1.8.5.3. Параметр «Учет».

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

Параметр «Учет» имеет формат списка, состоящего из четырех частей и содержит:

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

б) идентификатор ресурса строк символов;

в) единицу расхода строк символов;

г) расход, представленный целым числом.

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

• 2.1.8.6. Использование данных пользователя элемента СПиВ при отказе совершения операций.

Эти данные содержат только параметр «Диагностическое сообщение» и необязательный параметр «Учет».

• 2.1.8.6.1. Параметр «Диагностическое сообщение».

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

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

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

б) код диагностического сообщения службы ПОЗ;

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

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

Параметр «Таймер повторения» имеет такой же формат и значения, как и параметр «Таймер элементарного действия» элемента СПиВ. Если он присутствует, то указывает, что управляющий логический объект должен ждать указанное время перед попыткой повторить элементарное действие. Он может игнорироваться управляющим логическим объектом.

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

Сообщения являются следующими:

а) предупреждающее диагностическое сообщение (самое низкое);

б) диагностическое сообщение «Повторить позже»;

в) диагностическое сообщение «Не повторять» (самое высокое).

• 2.1.8.6.2. Параметр «Учет».

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

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

• 2.1.8.7. Использование данных пользователя элемента СПиВ в примитивах рестарта.

Параметр «Данные пользователя» не используются в примитивах запроса и индикации (он является необязательным в элементе СПиВ).

В примитивах ответа и подтверждения параметр используется, только в том случае, если ответом является примитив RETRY-LATER (ПОВТОРИТЬ ПОЗЖЕ) или REFUSE (ОТВЕРГНУТЬ), и содержит только параметр «Диагностическое сообщение» и необязательный параметр «Учет».

Если параметром указания продолжения является RETRY-LATER (ПОВТОРИТЬ ПОЗЖЕ), то параметр «Диагностическое сообщение» является необязательным и его отсутствие соответствует диагностическому сообщению «Повторить позже». Если данный параметр присутствует, он указывает на то, что управляющий логический объект должен ждать указанное время перед повторной попыткой запуска. Он может игнорироваться управляющим логическим объектом.

Если параметром указания продолжения является REFUSE (ОТВЕРГНУТЬ), параметр «Диагностическое сообщение» присутствует и указывает диагностическое сообщение «Не повторять» пли «Повторить позже». Формат параметра «Учет» описывается в п. 2.1.8.5.3. Параметр «Учет» в этом случае повторяет информацию, ранее обеспеченную при отвержении совершения операций.

• 2.1.9. Управление передачей

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

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

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

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

Наличие записей управления передачей может предотвратить совершение операций для элементарных действий. Такие отказы всегда отмечаются как «повторить позже».

• 2.1.10. Манипулирование уведомлениями

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

Первый тип представляет операцию DELETE (УДАЛИТЬ), которая вызывает удаление всех принятых уведомлений об указанном задании модели или о дереве подзаданий. Параметром такого типа является только идентификация спецификации работы, кото-передача без дальнейшего выполнения операций, последние воз-фикации работы или в спецификации, построенной из нее.

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

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

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

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

• 2.1.11. Манипулирование работой

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

С. -28 ГОСТ Р 34.W83-J93

ция», «Уничтожение», «Останов», «Отображение» над спецификацией работы и связанных с ними подзаданий. (Действие этих операций описывается ниже).

Первой операцией является операция «Выбор»; выбранными спецификациями работы или проформами являются такие, к которым применяются все операции, предшествующие следующей операции «Выбор».

Формат селектора спецификации работы описывается в п. 2.1.11.1.

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

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

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

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

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

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

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

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

• 2.1.11.1. Селекторы.

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

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

Имя поля Оператор Значение,

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

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

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

• 2.1.11.2. Корректирования.

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

Имя Поля Оператор Значение

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

С. 30 ГОСТ Р 34.1983—03

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

• 2.1.12. Манипулирование передачей

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

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

Операция «Установка» имеет параметр, который является записью управления передачей.

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

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

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

• 2.1.13. Санкционирование и учет

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

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

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

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

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

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

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

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

С. 32 ГОСТ Р 34.1983—93

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

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

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

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

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

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

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

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

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

• 2.1.15. Ответственность уведомляющей службы

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

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

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

2.L15.1. Отдельная уведомляющая служба.

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

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

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

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

• 2.1.15.2. Интегральная уведомляющая служба.

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

а) уведомление о том, что ^по примитиву j-INITIAJE уже построена новая спецификация работы;

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

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

г) уведомления о том, что для подзадания ицел место уровень совершения операции AGENCY ACCfiPTANCE (ПРИНЯТИЕ АГЕЩОДОМ)';

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

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

ж) уведомления о нормальном завершении подзадания;

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

и) предупреждающие уведомления.

• 2.1.15.3. Ответственность отдельной уведомляющей службы.

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

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

б) за попытку нарушения защиты — на той открытой системе, которая ответственна за манипулирование спецификацией работы;

в) за уведомления об отказе элементарного действия — на той открытой системе, которая содержит главный управляющий логический объект элементарного действия; диагностические сообщения направляются главному управляющему логическому объекту с помощью параметра «Диагностическое сообщение» в данных пользователя примитивов элемента СПиВ.

• 2.1.15.4. Ответственность интегральной уведомляющей службы. Ответственность интегральной уведомляющей службы лежит

на самой заинтересованной открытой системе:

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

б) за порождение — на той открытой системе, которая выполняет порождение;

в) за передачу ответственности — на той открытой системе, которая принимает ответственность;

г) за уровень совершения операций AGENCY ACCEPTANCE (ПРИНЯТИЕ АГЕНТСТВОМ) — на той открытой системе, в которой выдаются сервисные примитивы индикации J-DISPOSE;

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

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

ж) за нормальное завершение — на той открытой системе, которая завершает подзадание;

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

2.L15.5. Трассировка задания.

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

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

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

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

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

в) уведомления о передаче'ответственности, указывающие новый логический объект в открытой системе, ответственный за обработку подзадания;

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

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

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

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

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

а) уведомлений об уровне совершения операций AGENCY ACCEPTANCE (ПРИНЯТИЕ АГЕНТСТВОМ);

б) уведомлений о задержке и освобождении спецификации работы посредством модификации или о «невыполнении».

• 2.1.16. Документы

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

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

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

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

а) тиры документов, сформированные службой ПОЗ; это три типа документов, которые были описаны выше;

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

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

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

Эти типы документов определяются в стандарте ИСО 8832. Они все могут поддерживаться службой, если это необходимо.

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

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

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

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

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

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

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

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

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

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

• 2.2. Обзор услуг

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

Они предоставляются для:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 3) завершения манипулирования;

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

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

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

ж) записи управления передачей не обеспечиваются;

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

и) обеспечивается выбор только следующих операций в соответствии с параметрами «Тип подзадания», «Имя задания модели ВОС» и «Система предъявления задания модели ВОС»): «Короткое отображение», «Останов» и «Уничтожение»;

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

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

м) концепция «задержка» не обеспечивается;

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

• 1) J-JNITIATE-TCR-MAN

• 2) J-INITIATE-REPORT-MAN

• 3) J-ENQUIRE

• 4) J-HOLD

• 5) J-RELEASE

• 6) J-SPAWN

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

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

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

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

С. 40 ГОСТ P 54.1033-93

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

Такой выбор объема обеспечения агентства не относится к объему реализации базисного класса и расширенной реализаций.

• 2.4. Модель для сервисной спецификации

Услуги службы ПОЗ предоставляются (^рвцснЫйй элейентами специфической прикладной системы службы ПОЗ, сёрвгисйййи элементами для управления ассоциацией й для совершения Операций, согласованности действий и восстановления после 6Й1Йбох и логическими объектами более нижнего уррвня. Все имеете эТр образует поставщика услуг службы ПОЗ. Услуги службы ПОЗ оп^де-ляются по отношению к выражениям и д терминах втйфаЖёйий элементов модели службы ПОЗ, которые былЙ описаны ранее.

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

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

Пользователи службы ПОЗ

Зллршивающий

ГЮЛи>О»1Т»ЯЬ услуги

Ответственные логические объекты услуг

гест р инод-*» е. 4t

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

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

Другое м#оЖёстйо сервисных примитивов относится к манипулированию спецификаций работы.

Найо^ёЦ, Я модели службы ПОЗ имеется множество сервисных примитивов, отйоСйЩйхСй к концепциям управления и состояния.

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

Каждый такой сервисный примитив необходим для описания полной обработки одного задания модели ВОС.

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

3.L Сервисные примитивы службы ПОЗ

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

КаЖдое концептуальное взаимодействие между поставщиком услуг службы ПОЗ и агентством определяется введением последовательности сёрвйсНЫх примитивов (называемой групйой сервисных примитивов службы ПОЗ или группой совершения операций). Настоящий стандарт связывает семантики совершения операций, параллельность выполнения Действий и восстановления после ошибок (как определено в стандарте ИСО 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-INITIATE». В частности, различия между параметрами этих примитивов имеются только в природе параметров действия службы ПОЗ вне проформ и ограничений базисного класса.

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

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

две другие группы в исполняющее или исходное агентство. Этими группами являются:

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

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

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

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

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

Этими группами являются:

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

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

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

• 3.1.1.4. Группы примитивов, инициируемые поставщиком. Имеется пять групп примитивов, которые инициируются поставщиком услуг службы ПОЗ для принимающего или исполняющего агентства, чтобы управлять активностью, которая выполняется после предыдущего совершения операции с уровнем ACCEPTANCE (ПРИНЯТИЕ). Этими группами являются:

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

J-HOLD — используется поставщиком услуг службы ПОЗ для запроса временного приостановления выполнения

• 1) примитив запроса и подтверждения J-C0MM1T (только следуя за примитивом индикации J-READY);

• 2) примитив запроса и подтверждения J-RQLLBACK.

Примитивы в подпунктах а, в и г содержат только параметры элемента СПиВ и точно соответствуют сервисным примитивам элемента СПнВ с таким же именем. Их последовательность, семантика и параметры полностью определены в стандарте HCQ 9804, за исключением параметров «Данные пользователя» (см. п. 3.1.3). Агентство является главным управляющим логическим объектом совершения операций (и вводит идентификатор элементарного действия элемента СПиВ, и определяет уровень совершения операций и .таймер элементарного действия) во всех случаях, кроме.группы примитивов J-MESSAGE и J-SPAWN. Если этигруп-ны зродятсд .после совершения операций с уровнем ACCEPTANCE .(ПРИНЯТИЕ), агентство является главным управляющим логическим объектом совершения операций, в противном случае оно является управляемым логическим объектом. Если агентство яв-.ляется управляемым логическим объектом, оно выбирает уровень совершения операций больший или равный принятому. Для примитива запроса J-END-SIGNAL агентство всегда указывает уровень совершения операций PROVIDER-ACCEPTANCE (ПРИНЯТИЕ ПОСТАВЩИКОМ) (уровень 1) и не отвергает совершение операций, если поставщик услуг службы ПОЗ сообщает о совершении операций.

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

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

а) примитив индикации J-BEGIN, за которым следует б>) одни из:

• 1) .примитив индикации и ответа J-DISPOSE, за которым юаобязательно следует последовательность совокупности результата, указанная в п. 3.1.2.3;

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

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

• 4) примитив.индикации и ответа J-STATUS;

• 5) примитив индикации J-HOLD;

• 6) примитив индикации J-RELEASE;

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

• 8) примитив индикации J-STOP, за которыми следует

в) один из:

• 1) примитив запроса J+READY;

• 2) примитив запроса JtREFUSE, за которым следует

г) один из:

• 1) примитив индикации и ответа J-CDMMIT (только после примитива запроса J-READY);

• 2) примитив индикации и ответа J-ROLLBACK.

Примитивы в подпунктах а, в и г содержат только параметры элемента СПиВ и точно соответствуют сервисным примитивам элемента СПиВ, имеющим то же имя. Их последовательность, семантика и параметры полностью определены в стандарте ИСО 9804, за исключением параметра «Данные пользователя» (см. п. З.1.З.).

Поставщик услуг службы ПОЗ является главным управляющим логическим объектом совершения операций (и вводит идентификатор элементарного действия элемента СПиВ) только в том случае, если он уже имеет данный уровень совершения операций ACCEPTANCE (ПРИНЯТИЕ) по отношению к группе примитивов J-INITIATE, J-SPAWN или J-END-SIGblAL, которая сформировала спецификацию работы, по которой должны быть введены примитивы, в противном случае поставщик услуг является управляемым логическим объектом. Если поставщик услуг службы ПОЗ является главным управляющим логическим объектом, он всегда требует уровень совершения операций 1.

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

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

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

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

• 3.1.3. Параметры примитивов, относящихся к элементу СПиВ

Параметры примитивов, относящиеся к элементу СПиВ, идентифицируемых в пп. 3.1.2.1 и 3.1.2.2, описываются в стандарте ИСО 9804. Параметр «Данные пользователя», описанный в стандарте ИСО 9804, используется для содержания параметров, относящихся к элементу СПиВ, характерных для службы ПОЗ, как определено ниже.

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

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

а) уровень совершения операций (см. п. 2.1.8.4.1);

б) индикатор кода диагностического сообщения (см. п. 2.1.8.4.2).

• 3.1.3.2. Примитив запроса и индикации J-READY.

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

а) уровень совершения операций (см. п. 2.1.8.5.);

б) необязательные предупреждения (см. п. 2.1.8.5.2);

в) необязательную учетную информацию (см. п. 2.1.8.5.3).

• 3.1.3.3. Примитив запроса и индикации J-REFUSE.

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

а) диагностические сообщения (см. п. 2.1.8.6.1);

б) необязательную учетную информацию (см. п. 2.1.8.6.2).

• 3.1.3.4. Примитив запроса и индикации J-RESTART.

Параметр «Данные пользователя» не используется.

• 3.1.3.5. Примитив ответа и подтверждения J-RESTART.

Параметр «Данные пользователя» используется, если ответом является RETRY-LATER (ПОВТОРИТЬ ПОЗЖЕ) или REFUSE (ОТВЕРГНУТЬ) он содержит:

а) диагностическое сообщение (см. п. 2.1.8.7);

б) необязательную учетную информацию (см. п. 2.1.8.7).

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

Следующие группы примитивов вводятся в любое время: J-INITIATE-WORK

J-INITIATE-WORK-MAN J-IN1TIATE-REPORT-MAN J-INITIATE-TCR-MAN J-DISPOSE

J-GIVE

J-ENQUIRE

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

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

J-MESSAGE J-SPAWN

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

J-MESSAGE J-SPAWN J-END-SIGNAL

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

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

J-STATUS

J-HOLD

J-RELEASE

JKILL

J-STQP

В дополнение к этим примитивам примитцв J-RESTAR.T определяется с такой же семантикой и параметрами, как рдимитив C-RESTART или как описано в стандарте ;ИСО 9804.

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

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

а) последовательность внутри группы примитивов определяется, как указано в,п. 3.1.2;

б) последовательность групп примитивов, вводимых одним логическим объектом иди к одному логическому объекту службы ПОЗ для одного «под зад ан ця службы ПОЗ, определяется в п. 3.1.4;

В) последовательность примитивов с семантикой элемента СПиВ (в одинаковых или различных открытых системах) определяется описанием услуг элемента СПиВ;

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

д) нет никаких ограничений, накладываемых на последовательность сервисных примитивов.

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

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

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

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

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

• 3.2.1. Базисные типы данных

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

а) литералы;

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

в) типы данных «Строка»;

г) типы данных «Имя»;

д) типы данных «Ссылка»;

е) типы данных «Документ».

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

MOVE HIGH CREATION

Все другие базисные типы данных записываются строчными буквами, заключенными в угловые скобки, со знаками « = 1>, « = S> или « = OS>, « = N» или « = NA» или < = ND>, < = R> и « = D», включенными для отметки базисных типов данных по подпунктам б—е.

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

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

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

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

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

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

<срочностВ>

<задержки>

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

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

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

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

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

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

(HIGH (ВЫСШИЙ) | MEDIUM (СРЕДНИЙ) | LOW (НИЗКИЙ))

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

Например,

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

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

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

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

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

• 3.2.3.2. Типы данных «Строка».

Тип данных «Строка представляет собой последовательность символов плюс символ ПРОБЕЛ, взятых из набора символов, зарегистрированного для использования, как, например, наборы GO, Gl, G2 или G3 в реестре наборов символов стандартов ИСО, или представляет собой*строку октетов. В первом случае используется знак «==S», во втором случае используется знак « = OS>.

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

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

• 1) набор символов международной эталонной версии ГОСТ 27463;

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

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

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

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

<санкционированное имя =NA>

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

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

• 3.2.3.3. Типы данных «Имя».

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

а) прикладные логические объекты, содержащие элемент услуг

С. 52 ГОСТ Р 34,1963—93

специфического прикладного процесса (прикладной логический объект службы ПОЗ);

б) санкция идентификации пользователя;

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

Тип данных, который идентифицирует прикладной логический объект службы ПОЗ отмечается знаком «=₽№►. Тип данных, который идентифицирует санкцию идентификации пользователя, указывается знаком « = NA». Тип данных, который идентифицирует тип документа, отмечается знаком « = ND». Возможно, но не обязательно, для одного и того же имени указывать и прикладной логический объект службы ПОЗ, и санкцию идентификации пользователя.

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

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

• 3.2.3.4. Типы данных «Ссылка».

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

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

• 3.2.3.5. Типы данных «Документ».

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

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

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

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

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

Типы данных «Документ» определяются в данном стандарте (см. п. 3.5), в других стандартах или рекомендациях международной консультативной комиссии по телефонии и телеграфии (МККТТ) или непосредственно в реестре типов документов стандартов ИСО. Все документы, передаваемые службой ПОЗ, имеют связанное с ними явное имя (==ND), назначаемое, когда документы определяются.

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

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

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

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

Категории событий перечислены и определены ниже. CREATION (СОЗДАНИЕ)

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

TRANSFER (ПЕРЕДАЧА)

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

SPAWNING (ПОРОЖДЕНИЕ)

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

AGENCY-ACCEPTANCE (ПРИНЯТИЕ АГЕНТСТВОМ)

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

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

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

MANIPULATION-TERMINATION (ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ)

Уведомление должно быть сформировано открытой системой, выполняющей манипулирование, если спецификация работы завершается операцией манипулирования KILL (УНИЧТОЖИТЬ); уведомление формируется как часть элементарного действия манипулирования.

MODIFICATION (МОДИФИКАЦИЯ)

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

ERROR-DIAGNOSTIC (ДИАГНОСТИЧЕСКОЕ СООБЩЕНИЕ ОБ ОШИБКАХ)

Уведомление должно быть сфрмировано открытой системой всякий раз, когда указатель источника документа (см.

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

NO-PRO.GRESS (НЕ ВЫПОЛНЯТЬ)

Уведомление должно быть сформировано открытой системой всякий раз, когда открытая система, ответственная за спецификацию работы, и главный управляющий логический объект элементарного действия, пытающийся обработать ее, получают примитив запроса C-REFUSE или J-REFUSE с диагностическим сообщением NO-RETRY (НЕ ПОВТОРЯТЬ) и сохраняют спецификацию работы; данное уведомление также формируется, если непрерывна отказы с диагностическим сообщением RETRY-LATER (ПОВТОРИТЬ ПОЗЖЕ) повторяются для реализации, зависящей от времени; диагностическое сообщение элемента СПиВ становится доступным в уведомлении, и спецификация работы сохраняется для корректирования при последующей модификации; это уведомление формируется как отдельное элементарное действие.

ACCOUNTING-DATA (ДАННЫЕ УЧЕТА)

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

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

FVCT P 34.1983—93 C. 37

формируется как часть элементарного действия примитива J-MESSAGE.

NOT-SUPPORTED-TERMINATION (НЕОБЕСПЕЧИВАЕМОЕ ЗАВЕРШЕНИЕ)

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

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

ABNORMAL-TERMINATION (АВАРИЙНОЕ ЗАВЕРШЕНИЕ) Уведомление должно быть сформировано всякий раз, когда открытая система, ответственная за спецификацию работы ,и главный управляющий логический объект элементарного действия, пытающийся обработать ее, получают примитив запроса J-REFUSE или C-REFUSE с диагностическим сообщением NO-RETRY (НЕ ПОВТОРЯТЬ) и сбрасывают спецификацию работы; уведомление также формируется, если повторяются постоянные отказы с диагностическим сообщением RETRY-LATER (ПОВТОРИТЬ ПОЗЖЕ) для реализации, зависящей от времени; диагностическое сообщение элемента СПиВ становится доступным в этом уведомлении; это уведомление формируется как отдельное элементарное действие.

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

WARNING REPORT (ПРЕДУПРЕЖДАЮЩЕЕ УВЕДОМЛЕНИЕ)

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

3.3.2. Уведомления

Уведомление содержит следующую информацию: <уведомление>: := <имя уведомителя =N>

<штамп времени>

<идентификация подзадания>

• < идентификация события > (см. п. 3.4.2.2)

• < параметры события > <штамп-времени>: := (NULL) <дата-время =S>) <идентификация-подзадания>: : =

<система предъявления задания OSI = N>

«^идентификация инициирования> <время инициирования> <имя задания OSI = S> Слокальный указатель задания OSI»=S>

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

<тип подзадания> (см. п. 3.4.3.3)

<идентификация инициирования> : := <идентификация> <идентификация>: : =

(<система административного управления открытой систе-мой> I

Ссистема административного управления санкциями>| <пользователь>)

ГОСТ Р 34.1M3-«S3 С. 5»

<система административного управления открытой системой^ : =

<имя открытой системы = N>

<система административного управления санкциями>: : = <имя санкции =*NA>

<пользователь>: := <имя санкции =NA>

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

<список имен подзадания>: :=[<компонент имени подза-дания>]*Ь

<компонент имени подзадания>: : = <имя проформы =S> (см. п. 3.4.5) -Определяющее целое число =1> <параметры события>: : = (NULL ‘

(NULL (NULL (NULL (NULL (NULL (NULL (NULL

<состояние задержки>: : = (HELD (ЗАДЕРЖАНО) I NOT-HELD (HE ЗАДЕРЖАНО)) <сигнал останова>: : =

(STOPPED (ОСТАНОВЛЕНО) | MODIFIED (МОДИФИЦИРОВАНО))

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

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

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

Параметр Сидентификация инициирования> также является глобально явным и. идентифицирует систему административного

С. 60 ГОСТ F Ml983—98

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

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

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

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

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

Параметр <тип подзадания> определяется в п. 3.4.3.3. Он указывает тип подзадания, о котором должно быть выдано уведомление. Он никогда не может иметь значения <REPORT-MOVEMENT> (ПЕРЕМЕЩЕНИЕ УВЕДОМЛЕНИЯ), если использовался, как это описано выше, когда уведомления не формируются в таких подзаданиях.

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

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

Уведомлениями о событиях ERROR-DIAGNOSTIC (ДИАГНОСТИКА ОШИБОК), ABNORMAL-TERMINATION (АВАРИЙНОЕ ЗАВЕРШЕНИЕ), NOPROGRESS (НЕ ОБРАБАТЫВАТЬ) и WARNING REPORT (ПРЕДУПРЕЖДАЮЩЕЕ УВЕДОМЛЕНИЕ) являются такие уведомления, которые содержат определенное диагностическое сообщение (см. п. 3;3.3 для формирования определенных диагностических сообщений). Строки <текст> ис-

гост ршэ1мз с. 6t

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

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

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

Таблица I

Параметры событий

G. 62 ГОСТ P 34.1963—93

Продолжение табл. 1

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

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

Параметр <состояние задержки> имеет значение HELD (ЗАДЕРЖАНО), если один или более элементов в списке задержки препятствуют дальнейшему выполнению, в противном случае этот параметр имеет значение NOT-HELD (НЕ ЗАДЕРЖАНО).

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

Примечание. Аннулирование, выполняющее операцию KILL (УНИЧТОЖИТЬ), вызывает событие MANIPULATION-TERMINATION (ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ), а не событие MODIFICATION (МОДИФИКАЦИЯ).

3.3.3. Параметр «Диагностическая информация» «^Диагностическая информация^*: : =

<детали формирователя>

<штамп времени> (см. п. 3.3.2)

<диагностическое сообщение элемента CCR> (см. ниже)

<детали формирователя >: : =

(<детали источника>|

<детали пи> | получатель = М> | PROVIDER (поставщик))

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

<детали источника>: :=

<идентификация источника> (см. п. 3.4.4.1.3) <указатель источника документа> (см. п. 3.4.4.1.3) <детали пи>: :==<идентификация пи> (см. п. 3.4.4.1.1)

<указатель пи документа> (см. п. 3.4.4.1.2)

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

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

Параметр «^диагностическое сообщение элемента CCR> первоначально содержится в примитиве J-READY или C-READY (только для диагностического сообщения WARNING (ПРЕДУПРЕЖДЕНИЕ)), или в примитиве J-REFUSE, или C-REFUSE для диагностических сообщений RETRY-LATER (ПОВТОРИТЬ ПОЗЖЕ) или NO-RETRY (НЕ ПОВТОРЯТЬ).

Параметр <диагностическое сообщение элемента CCR> для диагностического сообщения WARNING (ПРЕДУПРЕЖДЕНИЕ) вкладывается в параметр -^диагностическая информация> для формирования уведомления WARNING REPORTS (ПРЕДУПРЕЖДАЮЩИЕ УВЕДОМЛЕНИЯ).

Параметр <диагностическое сообщение элемента CCR> для диагностического сообщения NO-RETRY (НЕ ПОВТОРЯТЬ) вкладывается в параметр -^диагностическая информация> для уведомлений об аварийном завершении, о невыполнении и для диагностических сообщений об ошибках.

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

<диагностическое сообщение элемента CCR>: : =

([Предупреждение]*С | [<Повторить позже>]*С | [<Не повторять>]*С) <Предупреждение>: := <формирователь =N>

<код>

(<причина> | <результат FTAM>)

• < Повторить позже >: := <формирователь =N>

<код>

(<причина> | <результат FTAM>) <таймер повторения =1> <Не повторять>: := <формирователь =N>

<код>

(Спричина > | <результат FTAM>) (см. ниже)

• < результат FTAM>: : =

<«результэ-т*выполнения передачи для операции Писать» или «результат выполнения передачи для операции Читать», как определено в приложении Г ГОСТ Р 34.1980.3>.

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

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

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

Параметр Стаймер повтбрения> задает предполагаемую временную задержку перед повторением выполнения элементарного действия. Время равйо 2**1 секунд, где «I» — значение параметра <таймер Повторениям

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

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

• 3.3.3.1. Параметр «Защищенные данные».

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

Спроверочная трасса> (см. п. 3.4.2) < идентификация подзадания> (см. п. 3.3.2)

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

• 3.3.3.2. Параметр «Учетная информация».

Сучетная информация^*: : = [Синформация расходов>]*С Синформация расходов>: С идентификация > (см. п. 3.3.2)

Симя ресурса =S> Сединица расхода =S> Срасход =1>

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

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

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

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

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

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

Дальнейшая обработка может вызвать то, что семантика этой спецификации работы будет передана в другую открытую систему, используя синтаксис элемента передачи службы ПОЗ [блок PDU (Protokol Data Unit — протокольный блок данных) службы ПОЗ]. Некоторые изменения семантики выполняются в структуре данных, когда она передается, особенно дополнение информации о том, откуда она поступает.

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

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

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

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

<спецификация работы>: : —

<параметры задания OSI> (см. п. 3.4.2) Ссписок имен подзаданий> (см. п. 3.3.2) (Сспецификация подэадания> | NULL) Ссписок проформ> Слокальные поля>

<список документов>

<локальные поля>: :==

<параметры активности агентства> (см. текст ниже)

<время ожидания =1> <подсчитанный размер =1>

Сспецификация подзадания>: : =

Спараметры подзадания OSI> (см. п. 3.4.3) Спараметры действия службы JTM> (см. п. 3.4.4) <действие при ошибке> (см. п. 3.4.3.4)

<список проформ>: : = [<проформа>]*11 (см. п. 3.4.5) <список документов>: : = [Сдокумент=О>]*Е

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

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

Значение NULL (НОЛЬ) замещает значение поля Сспецифй-кацйя подзадания> только в том случае, если выполнение спецификации работы, указанной параметром <спецификация работы> задерживается в ожидании примитива J-END-SIGNAL из прини-

e. OS fGCT P 84.1983-93

мающего Или исполняющего агентства. Параметр Спецификация р'абюты> никогда не передается в этом формате.

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

Поле < параметры действия службы JTM> зависит от типа подЭад'ан|/я и подробно определяет действия открытых систем, которые предназначены для выполнения работы.

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

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

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

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

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

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

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

На каждое поле <документ> имеется ссылка из поля <пара-метры действия JTM> с помощью указания его позиции в списке. Значение параметра <тип документа> также записывается в поле <параметры действия службы JTM>.

• 3.4.2. Параметры задания модели ВОС <нараметры задания OS1>: : =

<система предъявления задания OSI = N> <идентификация инцциирования> (см. п. 3.3.2) <время инициирования> (см. п. 3.3.2) <имя задания QSI = S> (см. п. 3.3.2) <локальный указатель задания OSI = S> (см. п. 3.3.2) <проверочная трасса> (см. ниже)

<спецификация первичного монитора> (см. ниже) <спецификация вторичных мониторов> (см. ниже) <санкционирование> (см. ниже) <разрешения> (см. ниже) <счет> (см. ниже) <параметры защиты = 1?>

< параметры элемента CCR> (см. ниже)

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

С. 70 ГОСТ Р 34.1983-93

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

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

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

Параметр <проверочная трасса> используется для определения исходного агентства данной связи:

<проверочная трасса>: : = [<элемент проверки>]*Е

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

<элемент проверки>: :==

<имя открытой системы = N> (UNKNOWN (НЕИЗВЕСТНЫЙ) | KNOWN (ИЗВЕСТНЫЙ) | AUTHENTICATED (АУТЕНТИФИЦИРОВАННЫЙ))

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

Примечания:

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

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

Обратитесь к п. 3.4.2.1 для использования проверочной трассы при установлении санкционирования.

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

Сспецификация первичного монитора>: : = <спецификация монитора >

<спецификация вторичных мониторов>: : =

[<спецификация монитора>]*Ь Сспецификация монитора>: : =

Сспецификация монитора> (см. п. 3.4.2.3) Сселектор уведомления> (см. п. 3.4.2.2)

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

Параметры Ссанкционирование>, Сразрешение> и <счет> являются следующими:

< санкционирование^ : =

[Сэлемент санкционирования>]*С (см. п. 3.4.2.1) Сразрешение>: : =

(Сэлемент разрешения>]*С (см. п. 3.4.2.1) Ссчет>: := [Сэлемент счета>]*С (см. п. 3.4.2.1).

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

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

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

Параметр <параметры элемента CCR> используется, если спецификация работы защищена, в конце элементарного действия и сохраняется поставщиком услуг службы ПОЗ. В процессе выполнения первого элементарного действия задания модели ВОС параметры элемента СПиВ в примитиве J-BEQIN определяются инициирующим агентством. Значение параметров «индикатор кода диагностики», используемых поставщиком услуг службы ПОЗ для последующих элементарных действий, является таким же, как значение этого параметра в группе совершения операций примитива J-INITIАТЕ. Параметр «^параметры элемента CCR> показывает это значение. (При этом данное значение никогда не передается явно в элементе передачи, будучи передаваемым с помощью примитива C-BEGIN).

Спараметры элемента CCR>: : =

<индикатор кода диагностического сообщения = R>

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

• 3.4.2.1. Санкционирование и учет.

Олемент санкционирования^*: : =

<ндентификация> (см. п. 3.3.2)

Споле доступа > <элемент счета >: : =

<идентификация> (см. п. 3.3.2)

<лоле доступа >

<элемент разрешения^*: : =

< идентификация > (см. п. 3.3.2) <поле доступа>: : =

(< индекс проверки = 1> ] •<секретные данные>) <секретные данные>: : =

(UNSET) Сграфический пароль=8>|

<двоичный пароль = ОБ>)

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

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

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

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

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

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

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

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

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

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

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

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

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

• 3.4.2.2. Селекторы уведомлений.

<селектор уведомления>: : =

[<идентификация событиям*]*С

<идентификаиия события>: : =

(НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ |

ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ |

АВАРИЙНОЕ ЗАВЕРШЕНИЕ | СООБЩЕНИЕ ПОЛЬЗОВАТЕЛЯ I СОЗДАНИЕ |

ПЕРЕДАЧА | ПОРОЖДЕНИЕ I ПРИНЯТИЕ АГЕНТСТВОМ | МОДИФИКАЦИЯ |

ДИАГНОСТИЧЕСКОЕ СООБЩЕНИЕ ОБ ОШИБКЕ |

НЕ ВЫПОЛНЯТЬ |

ДАННЫЕ УЧЕТА (

НЕ ОБЕСПЕЧЕННОЕ ЗАВЕРШЕНИЕ |

ПОПЫТКА НАРУШЕНИЯ |

ПРЕДУПРЕЖДАЮЩЕЕ .УВЕДОМЛЕНИЕ)

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

• 3.4.2.3. Спецификация монитора. <спецификация монитора>: :==

[Спромежуточная система = 1Ч>]*Ь (см. п. 3.4.3)

Ссистемное имя монитора = N> <команды размещения^*

Скоманды размещениям : =

(KEEP | Сданные размещения>) Сданные размещения>: : —

Сидентификация пи> (см. п. 3.4.4.1.1)

Суказатель пи документа> (см. п. 3.4.4.1.2)

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

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

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

• 3.4.3. Параметры подзадания модели ВОС Спараметры подзадания OSI>: : —

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

Ссрочность> (см. п. 3.4.3.1) <задержки> (см. п. 3.4.3.2) <тип подзадания> (см. п. 3.4.3.3)

С. 7« ГОСТ ₽ 34.1983—93

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

<промежуточные системы>

<целевая система=N> <промежуточные системы>: : —

^промежуточная cncTeMa = N>]*L

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

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

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

Параметр <тип подзадания> определяет природу подзадания и формат параметра Спараметры действия службы JTM>.

• 3.4.3.1. Срочность. <срочность>: : =

(HIGH (ВЫСОКАЯ) | MEDIUM (СРЕДНЯЯ) | LOW (НИЗКАЯ))

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

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

• 3.4.3.2. Задержки. <задержки>: : = <элемент задержки>*С <элемент задержки>: : —

<местоположение задержки=Ы>

(<npH4HHa = S> |

•^диагностическая информация>) (см. п. 3.3.3)

<разрешение освобождения>

<время освобождения^* <разрешение освобождения>: : =

(<идентификация> | NULL) (см. п. 3.3.2)

<время освобождения >.* : =

(<дата-время = 3> | (см. п. 3.3.2)

<время дня==Б> |

<временной интервал —1>)

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

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

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

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

С. ?8 ГОСТ Р 34.1983—93

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

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

• 3.4.3.3. Тип подзадания. <тип подзадания>: :«

(ПЕРЕМЕЩЕНИЕ ДОКУМЕНТА | МАНИПУЛИРОВАНИЕ РАБОТОЙ i ПЕРЕМЕЩЕНИЕ УВЕДОМЛЕНИЯ | МАНИПУЛИРОВАНИЕ TCR |

МАНИПУЛИРОВАНИЕ УВЕДОМЛЕНИЕМ)

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

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

<действие при ошибке>: : =

(HOLD <временной интервал = 1> j TERMINATE

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

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

Главный управляющий логический объект инициирует одно или несколько ответвлений элементарного действия для:

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

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

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

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

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

• 3.4.3.4.2. Действие HOLD (ЗАДЕРЖКА).

Значение параметра «HOLD <временной интервал^*» вызывает, чтобы поставщик услуг службы ПОЗ (когда имеет место ошибка):

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

б) добавил параметр Олемент задержки> для текущего размещения с параметром «^диагностическая информация^ происходящего из диагностического сообщения (диагностических сообщений) элемента СПиВ, значение NULL (НОЛЬ) параметра разрешение освобождения> и параметр <время освобождения^*, вычисляемый из текущего времени плюс значение параметра <временной интервал>;

€. SO roe? P Э4ЛШ-93

в) сформировал любые требующиеся уведомления для события «NO PROGRESS» (НЕ ВЫПОЛНЯТЬ).

• 3.4.3.4.3. Действие TERMINATE (ЗАВЕРШИТЬ).

Значение TERMINATE (ЗАВЕРШИТЬ) вызывает, чтобы поставщик услуг службы ПОЗ:

а) сбросил спецификацию работы;

б) сформировал любые требующиеся уведомления для события «ABNORMAL-TERMINATIOH (АВАРИЙНОЕ ЗАВЕРШЕНИЕ)».

• 3.4.4. Параметры действия службы ПОЗ

<параметры действия службы JTM>: : =

(Соперации по перемещению документа> | (см. п. 3.4.4.1) Соперации по манипулированию работой> | (см. п. 3.4.4.2) Соперации по манипулированию передачей> (см. п. 3.4.4.3) Соперации по манипулированию уведомлениями> | (см.

п. 3.4.4.4.)

Соперация по перемещению уведомлений>) (см. п. 3.4.4.5). Если поле Стип подзадания> имеет значение DOCUMENT

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

Если поле Стип подзадания> имеет значение WORK-MANIPULATION (МАНИПУЛИРОВАНИЕ РАБОТОЙ), то этот параметр действия содержит значение Соперации по манипулирований» работой>.

Если поле Стип подзадаНия> имеет значение TCR-MANIPU-LATION (МАНИПУЛИРОВАНИЕ TCR), то этот параметр действия содержит значение Соперации по манипулированию пере-дачей>.

Если поле Стип подзадания> имеет значение REPORT-MANIPULATION (МАНИПУЛИРОВАНИЕ УВЕДОМЛЕНИЯМИ), то этот параметр содержит значение Соперации по манипулированию уведомлениями>.

Если поле Стип подзадания> имеет значение REPORT-MOVEMENT (ПЕРЕМЕЩЕНИЕ УВЕДОМЛЕНИЯ), то этот Параметр действия содержит значение Соперации по перемещению уведомлений>.

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

Соперации по перемещению документа>: : =

[Сперемещение документа>]*Е

Сперемещение документа>: : =

Стип документа = ND>

Спи агентства>

Сблок документа>

Спи агентства^*: : —

[< идентификация пи>]*Ь (см. п. 3.4.4.1.1).

Примечания:

• 1. Все поля идентификация пи> в списке являются элементами <пи службы JTM> или все они являются элементами <пи службы FTAM>. Смешанное расположение в одном блоке документа не обеспечивается.

• 2. Если используется параметр <множественный формат>, параметр <идентификация пи> имеет формат параметра <пи службы JTM>.

< блок документа >: : =

(Сединый формат> | (см. п. 3.4.4.1.2)

С множественный формат>) (см. п. 3.4.4.1.4).

Каждый параметр <идентификация пи> идентифицирует принимающее или исполняющее агентство.

По каждому параметру Сединый формат> формируется (с помощью использования одного или нескольких примитивов J-GIVE) один документ (возможно с вложенным диагностическим сообщением — см. п. 3.4.4.2.3) для размещения целевой системы возможно, как результат объединения нескольких документов, полученных из исходных агентств. По каждому параметру Смноже-ственный формат> либо не формируется, либо формируется один или несколько документов для размещения, каждый с отдельным сочетанием параметров Сединый формат> <блок документа>. Все документы, перемещаемые одной операцией СперемеЩение документа>, имеют один и тот же тип документа. Итак, одна операция Сперемещение документа> обеспечивает:

а) перемещение нескольких объединенных документов и возможное дублирование результата (использование параметра Сединый формат>);

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

Система обработки целевой системы по каждой операции Сперемещение документа> принимает все документы, описанные параметром <блок документа >, и передает каждый из них всем агентствам, указанным параметром Спи агентства> при помощи отдельной группы примитивов J-DISPOSE для каждого документа.

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

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

• 3.4.4.1.1. Идентификация принимающего и исполняющего агентства.

<идентификация пи>: : = (<пи службы JTM> | <принимающее агентство службы FTAM>) <дополнительное санкционирование>

<пи службы JTM>: : = <имя пи = Б>

<параметр агентства>

<метка активности агентства = 5> <префикс пи>

<принимающее агентство службы FTAM>: : =

<имя файлохранилища = Ы>

<параметр агентства>: : =

(<iN,ULL | STORE | <формат агентства —S>)

Спрефнкс пи>: : = [<hmh = S>]*L

«^дополнительное санкционирование^* : = ляется строкой, определяемой целевой открытой системой для явной идентификации принимающего или исполняющего агентства (внутри такой открытой системы), для которого, чтобы разместить документ, должен быть введен примитив J-DISPOSE.

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

Примечание. Значение STORE (СОХРАНИТЬ) параметра <параметр агентства> Ие применимо к исполняющему агентству.

Если параметр указывает значение NULL (НОЛЬ), документ сохраняется или предоставляется по определяемому локально способу.

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

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

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

Параметр <имя файлохранилища> в форме <принимающее агентство службы FTAM> идентифицирует (локальное или удаленное) виртуальное файлохранилище службы ПДУФ, которое должно принять документ. Вся другая информация по размещению содержится в параметре <указатель пи документа> (см. п. 3.4.4.1.2).

• 3.4.4.1.2. Блоки документа единого формата.

<единый формат>: : =

<указатель пи документа>

[<указатель документа>]*L

<указатель документа>: : =

(<записать данные службы JTM> i

<записать данные службы FTAM>j

<записать данные службы JTM>: : =

<параметр доступа пи>

<список имен.>

<записать данные службы FTAM>: : =

<«спецификация передачи записи», как определено в приложен нии Г ГОСТ Р 34.1980.3>.

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

<параметр доступа пи>: : =

(NORMAL (НОРМАЛЬНЫЙ) I

NEW (НОВЫЙ) |

OLD (СТАРЫЙ) |

APPEND (ПРИЛОЖЕННЫЙ) I

ADD (ДОБАВЛЕННЫЙ))

Ссписок имен>: :=±[<имя-S>]*L

<указатель документа >: : =

(EMBEDDED (ВЛОЖЕННЫЙ) |

<указатель единого документа^*) (см. п. 3.4.4.1.3).

Этот формат параметра <блок документа> указывает, что документы, которые указаны в параметоах <указатель документа> должны быть объединены (в порядке ссылок в блоке документа) для формирования одного документа для размещения при помощи примитива J-DISPOSE.

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

Примечание. Этот параметр игнорируется исполняющим агентством.

Параметр передается как поле параметра примитива J-DISPOSE. Значение литералов может быть следующим:

NORMAL (НОРМАЛЬНЫЙ) —

перезаписать какие-либо старые документы с тем же именем или создать новый документ в принимающем агентстве; NEW (НОВЫЙ) —

создать новый документ в принимающем агентстве, если возможно, но если старый документ существует с таким же именем, отвергнуть совершение операций с выдачей диагностического сообщения; OLD (СТАРЫЙ) —

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

APPEND (ПРИЛОЖЕННЫЙ) —

добавить в конец какого-либо старого документа, но если старый документ не существует, отвергнуть совершение операций с диагностикой;

ADD (ДОБАВЛЕННЫЙ) -

добавить в конец какого-либо старого документа и, если старый документ не существует, создать новый документ.

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

Литерал со значением EMBEDDED (ВЛОЖЕННЫЙ) отображает документ в списке, указанный параметром <список документов >. Количество документов в списке, указанном параметром <список документов>, равно общему количеству имеющихся литералов EMBEDDED (ВЛОЖЕННЫЙ) в спецификации работы (включая проформы). Имеется соответствие позиций в параметре Ссписок документов> и в синтаксисе передачи спецификации работы.

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

Параметр Суказатель единого документа> требует включения документа, который должен быть получен примитивом J-GIVE или при использовании службы ПДУФ. Это выполняется поставщиком услуг службы ПОЗ либо в формате EMBEDDED (ВЛОЖЕННЫЙ), либо включается диагностическое сообщение об ошибке.

• 3.4.4.1.3. Указатели единого документа и идентификация исходного агентства.

Суказатель единого документа>: ; =

<открытая систем'а выполнения действия = N>

< идентификация исходного агентства>

Суказатель Источника документа>

<вложенное диагностическое сообщение> <состояние>

<идентификация исходного агентства>: : =

(PROVIDER (ПОСТАВЩИК) |

<исходное агентство службы JTM> |

<исходное агентство службы FTAM>)

<дополнительное санкционирование>

<исходное агентство службы JTM>: : =

С имя исходного агентства = S>

Спараметр агентства> (см. п. 3.4.4.1.1)

Сисходное агентство службы FTAM>: : =

<имя файлохранилища = 1Ч> <указатель источника документам*: : =

(<читать данные службы JTM> |

-Считать данные службы FTAM>)

<читать данные службы JTM>: : =

Спараметр доступа к источнику> Ссписок имен>

Считать данные службы FTAM>: : =

С «специфика передачи для операции ЧИТАТЬ», как определено в приложении Г ГОСТ Р 34.1980.3>.

Примечание. Формат <читать данные службы FTAM> используется только в том случае, если параметр <иден5ификация исходного агентства> имеет формат Сисходное агентство службы FtAM>.

Спараметр доступа к ,псточнику>: : =

(MOVE (ПЕРЕМЕСТИТЬ) |

COPY (КОПИРОВАТЬ)) Свложенное диагностическое сообщенпе>: : =

(EMBED (ВЛОЖИТЬ) |

ERROR (ОШИБКА)) состояние

(NOT ATTEMPTED (ПОПЫТКИ НЕ БЫЛО) |

FAILED (ОТКАЗАНО) Синформация об ошибке>) «^информация об ошибке>: : —

<штамп времени> (см. п. 3.3.2)

<диагностическое сообщение элемента CCR> (см. и. 3.3.3).

Параметр <открытая система выполнения действия> указывает имя открытой системы, которая должна ввести примитив индикации J-QIVE (который может включить использование службы ПДУФ для получения документа). Параметр <открытая система выполнения действия> указывает либо открытую систему, создающую спецификацию работы (при помощи порождения или в результате примитива J-INITIАТЕ), либо целевую систему, либо одну из промежуточных систем.

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

Параметр <тентнФикяпия исходного агентства> и-меет формат параметра «< исходное агентство службы JTM> для исходных .агентств. которые получают документ локально или при помощи нестандартного удаленного способа доступа. Формат параметра «< исходное агентство службы FTAM> идентифицирует локальное исходное агентство, которое подучает документ (локально или удаленно), используя стандарт ИСО 8571—3.

Параметр <*имя исходного агентства> является строкой, определяемой параметром <пткг>ыгая система выполнения действия> иля явной идентификации такого исходного агентства (внутри такой открытой системы), для которого должен быть введен примитив J-GIVE. чтобы получить от него документ.

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

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

Параметр <параметп доступа к исходному агентству> передается как одно из полей в примитиве J-GTVF: если значением этого параметра является COPY (КОПИРОВАТЬ), исходное агентство не Подвергается действию. Если значением ЭТОГО параметра является MOVE (ПЕРЕМЕСТИТЬ), документ помечается для удаления из исходного агентства при совершении операций и остается неизменным при возвращении действия в первоначальное состояние. Если этому исходному агентству доступны активности параллельных действий (часть того же самого элементарного действия), документ удаляется (если для какого-либо из них была совершена операция по перемещению) при последующем совершении операций или при возврате каждого из действий в первоначальное состояние.

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

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

Отметим, что при разрешении ссылки на один документ, используя примитив J-GIVE, также обеспечивается поле <тип документа > параметра < перемещение доку мента >.

Параметр <вложенное диагностическое сообщение> указывает действие, которое должно быть предпринято системой, указанной параметром <открытая система выполнения действия >, если примитив J-GIVE отвергается с выдачей диагностического сообщения или если значением параметра <идентификация исходного агентства> является PROVIDER (ПОСТАВЩИК), а указанный документ не доступен.

Значение EMBED (ВЛОЖИТЬ) требует, чтобы поле <состоя-ние> было изменено из его начального значения NOT ATTEMPTED (ПОПЫТКИ НЕ БЫЛО) на значение FAILED (ОТКАЗАНО). Поле <штамп времени> содержит время, когда была предпринята безуспешная попытка выполнения примитива J-G1VE, и диагностическое сообщение примитива J-REFUSE помещается в поле <диагностическое сообщение элемента CCR>. Это ответвление элементарного действия предшествует совершению операций. Отказ на принятие действия к выполнению является невидимым для главного управляющего логического объекта. Если основное действие предшествует совершению операций, то совершается изменение в состояние, указанное параметром <состоякие>. Если это действие возвращается в первоначальное состояние (по другим причинам), то состояние, указанное параметром Ссостоя-ние>, возвращается в первоначальное. Это действие генерирует событие DA1QNOSTICS (ДИАГНОСТИКА), которое может быть выбрано для уведомляющей службы.

Значение ERROR (ОШИБКА) вызывает установление параметра <состояние> в значение NOT ATTEMPTED (НЕТ ПОПЫТКИ) и возвращает отказ и диагностическое сообщение вверх по дереву элементарных действий к главному управляющему логическому объекту. Последующее действие определяется значением поля Сдействие при ошибке> для полного подзадания (см. п. 3.4.3.4.).

• 3.4.4.1.4. Блоки документов множественного формата <множественный формат>: :=«

<открытая система действия = N>

Сконструкция документа пи>

<исходное агентство службы JTM> (см. п. 3.4.4.1.3) «^дополнительное санкцнонирование> Сконструкция документа исходного агентства> <селектор документа >

<селектор документа>: : =

(NULL | Слокальная строка = S>)

• < конструкция документа пи >: : =

<параметр доступа к пи> (см. п. 3.4.4.1.2)

<список частичных имен>

• < конструкция документа исходного агентства>: : =

<параметр доступа к исходному агентству> (см. п. 3.4.4.1.3) <список частичных имен>

Ссписок частичных имен>: : = [<hmh = S>]*L

Поля параметров Соткрутая система выполнения действия>, <исходное агентство службы JTM>, «^дополнительное санкционирование^ <параметр доступа к пи> и <параметр доступа к исходному агентству> определены в пп. 3.4.4.1.2 и 3.4.4:1.3.

Блок документа множественного формата используется либо для неформирования, либо для формирования одного или нескольких блоков документов единого-формата, каждый из которых содержит значение EMBEDDED (ВЛОЖЕННЫЙ) параметра указатель документа >.

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

Документы принимаются системой, указанной параметром Соткрытая система выполнения действия^*» из исходного агентства, указанного параметром Сидецтнфикдция исходного .агецтст-ва>. Они имеют одно и то ₍же значение параметра <тип документах указанного для операции Спепсмщценне документаX Параметр <указатель исходного аг^нтстз^ документа> для примитива J-GIVE, чтобы получить каэедь^ документ,.составляется из полей < конструкция документа исходного агентства > добавлением имен (достаточного количества) в конец параметра Ссписок частичных именх Это достаточное количество обеспечивается примитивом J-ENQUJRE.

Блок документа множественного формата обрабатывается системой, указанной параметром <открытая система выполнения действиях при первом введении примитива J-ENQUIRE в исходное агентство, передавая параметры <тип документах Сконст-рукция документа исходного агентства> и Сселектор документа >. Эта система возвращает список достаточного количества (списки имен), одно имя для каждого документа, который должен быть доступен. Каждый из этих полей (описки имен) достаточного количества добавляется к параметру <список' частичных имен> в параметре Сконструкция документа пи> и Сконструкция документа исходного агентствах как определено выше. Множество достаточного количества (список имен), возвращаемое после выполнения примитива J-ENQU1RE, является максимальным множеством, для которого в результате выполнения примитивов J-GIVE могут быть сформированы документы, субъекты для использования параметров Сселектор документа> и <тип документах Семантика параметра Слокальная строка> не стандартизована. Значение NULL (НОЛЬ) для параметра Сселектор документа> означает максимальную выборку.

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

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

а) параметр Ссписок частичных именХ

б) параметр Стип документах

в) параметр Спараметр агентства>;

г) параметр Спараметр доступа к исходному агентствуX;

д) параметр Спароль> из параметра Сдополнительное санкционирован исХ

е) параметр Сселектор документах

Отметим, что-решение такой ссылки не является субъектом отказа. Результатам: такого решения всегда является либо не получение.. аюо получение одного .или нескольких документов. Это решение, имеет осодое эдцс>дьзование. если совокупность документов с последующей обработкой исполняющим агентством,, где имена и количества документов могут быть не известны зарайее и могут зависеть от, степени успешности.выполнения идц.от того, прерыва-лррь ли.выполнение, с помощью операции по манипулированию STO?,,(QCTAft(W

• 3.4.4.2. Операции по манипулированию работой. <операнрн Щ? манипулированию работой>: : —

[ <операция да,(юты> J*L <операция работы>: : =

(<операцвд.выбора> |

<операция,у^ичтожеция;> |

Соцерация

<.оге,рацщ| отэдрадедид работы> |

,< оцер аии| мрдифи^ций >.)

<операция выбора.: =

SELECT <селв£гор> , (см. п. 3.4,4.2.1) <операиия, уничдоженир>.:'_|.'_;:=йК11_Е <операция останова >: : = STOP Соперация отображении работы>: : =

DISPLAY. ^н£я, документа = S>

(XfULt ( ’ kofejj

BRIEF (Kft QRj>) Операция, мрдифлкации^; : =

MODIFY 3.4.4.2.4)

Операции по^.м^ципу^ирорауик), работой вызывают то, что целевая открытая илиМодифицирует определение

спецификации работы, за которую она ответственна.

..Операции KJLL (УНИ₍ЧТОХИТ^). STOP (ОСТАНОВ) и MODIFYХМОДИфИЦ^РрВдТБ). могут вызывать то, что поставщик услуг службы JTM\ЧЧр.ДиТ^примитцвы индикаций J-RILL, J-STOP, .J-HOL0 или J-ftEt’EASE.’Для соответствующих агентств, а операция DISPLAY ЮТОБРДЗЙ ГЬ)’ вызывает введение примитива индикации J-STATy$ ^для соответствующих агентств.

По операции SELECT (ВЫБРАТЬ) либо не выбирается, либо выбирается одна ,и/1и несколько спецификаций работы или проформ для последующих операций. Эта операция выполняется с помощью тестирования, значения пол^й в спецификации работы, используя литералы службы ПОЗ для указания подлежащих тестированию полей. Выбранные спецификации, работы или профор-

С. 92 ГОСТ Р 34.1993-93

мы используются последующими операциями (KILL (УНИЧТОЖИТЬ), STOP (ОСТАНОВ), MODIFY (МОДИФИЦИРОВАТЬ) и DISPLAY (ОТОБРАЗИТЬ)). Эта операция SELECT (ВЫБРАТЬ) действует до тех пор, пока не будет введена следующая операция SELECT (ВЫБРАТЬ).

Операция KILL (УНИЧТОЖИТЬ) вызывает появление события MANIPULATION-TERMINATION (ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ) для подзаданий г предотвращает порождение в конце уничтожаемой активности. Эта операция сформирует примитивы J-KILL или J-^ROLLBACK для какого-либо соответствующего агентства и возвратит в первоначальное состояние какое-либо действие по передаче и сбросит соответствующую спецификацию работы.

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

Операция MODIFY (МОДИФИЦИРОВАТЬ) вызывает изменения, которые должны быть выполнены для выбранной спецификации (спецификаций) работы или проформы (проформ). Параметр <модификация> вызывает изменения для указанных полей; если изменяется параметр <задержка>, результатом модификации может быть введение примитива индикации J-HOLD или J-RELEA-SE. Изменения в состоянии задержки отмечаются в каком-либо уведомлении MODIFICATION (МОДИФИКАЦИЯ), которое формируется.

Операция DISPLAY (ОТОБРАЗИТЬ) вызывает копирование данных из выбранной спецификации (спецификаций) оаботы или проформы (проформ) вместе с информацией из примитива J-STATUS, которое должно быть выполнено тац, как указано в части параметра <документ отображения ра'боты> с именем <имя документа^*. Поле Сдокумент отображения работы> определено в п. 3.5.2.

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

Следующие аутентифицированные параметры «^идентификация > допускаются для модификации спецификации работы:

а) какой-либо параметр <идентификация>, который появляется в поле <разрешение> спецификации работы;

б) какая-либо санкция идентификации, один из параметров которой <идентификация > появляется в поле <разрешение> спецификации работы;

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

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

После операции DISPLAY (ОТОБРАЗИТЬ) с параметром <имя документа> документ типа <дакумент отображения рабо-ты> является доступным для сборки с помощью указателя к параметру <идентификация исходного агентства> со значением PROVIDER (ПОСТАВЩИК) и к параметру <спнсок имен>, содержащему только поле <имя документа >. Две операции отображения одним и тем же значением параметра <имя документа > выполняют оба отображения работы в том же самом документе. Отображение может «быть полным отображением или кратким отображением, как определено в п. 3.5.2.

3.4.4 J.I. Селекторы.

<селектор>: : =

<формат селектора >

<тест заголовка >

• < формат селектора >: : =

(CONTAINSHEADER (СОДЕРЖИТ ЗАГОЛОВОК) |

DOES-NOT-CONTAINS-HEADER (НЕ СОДЕРЖИТ ЗАГОЛОВОК) |

FIRST-HEADER-IS (ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ) | HEADER-IS (ЗАГОЛОВОК ИМЕЕТСЯ))

• < тест заголовка >: : =

(<тест поля> |

С. 94 ГОСТ Р 34.1983—93

• < предложение NOT ₍(НЕТ),> <предложение ANvth ’> |

  <предложение ANv

  
  

• < предложение QR |

SUCCESS (УСПЕШНЕЙ ¹ <предложение AND (И)>: : =

AND <тест заголовка > < тест за головка > <предложение OR (ИЛИ)>Г : =

OR Стест заголовка > СТест заголовка>

Стест поля>: : =

Снмя поля>

<оператор выбора>

Сзначение выбора>

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

Поля этой структуры данных определяются в п. 3.4.6.

Список заголовков, ррдер^ит один или несколько заголовков. Каждый заголовок содержит поля, являющиеся глобальными в полном 'задании модели' рОС, вместе с полями,, которые являются специфичными для п^дз^данйя мЬДелй В0С'¹ &а(к 'у’каЗанО ¹ спецификацией‘работы или одной из' её'п^6форУ.^:’,МУлю^6м уровне.вложенности) (см. п. 3.4.6).

Параметр стест поля^> применяется к поименованному полю в параметре <заго/ювок>’ п вызывает формирование знания SUCCESS (УСПСШНО? или FAIL (ОТКАЗ). Зкач^ Параметров <тест поля> комбинируется операторами ANET ’(И), OR (ИЛИ) пли NOT (НЕТ) для получений'^,зйачё‘йия S0CCESS (УСПЕШНО) или FAIL (ОТКАЗ) для параметре’Стест заголовкам*.

Проформа выбирается при помощи формата HEADER4S (ЗАГОЛОВОК ИМЕЕТСЯ) только в том случаелесЯй Параметр Стест заголовка> вызывает формирование значения SUCCESS (УСПЕШНО) при применении этого теста к заголовку, кюотзетстьую-щему данной пр’бформё.

Формат CONTAINS-HBADER (СОДЕРЖИТ ЗАГОЛОВОК) вызывает выбор спецификаций рарохы, которые содержат, по крайней мере, одну проформу (Ца Я©бой глубине), соответствующую параметру <заголовок>, за которым следует параметр Стест заголовка>. Формат DOES-NOT-CONTAIN-HEADER (НЕ СОДЕРЖИТ ЗАГОЛОВОК) вызывает выбор спецификаций рабо

ГОСТ Р М.1983—93 С. 95

ты, для которых параметр <тест.заголовка> вызывает отказ по всем параметрам <заголойок>, соответствующим проформам в нем. Формат¹ FIRST^JHEADER-!S (ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ) вызывает BbttJbp спецификаций работы, для которых параметр <тест'заГдловка> следуеФ за заголовком, соответствующим самой спецификации работы.

Примечание. Пр значению селектора формата HEADER-IS (ЗАГОЛОВОК ИМЕЕТСЯ)'выбирали ’(указывается) спецификация работы или проформа. В ПосЛйЯйем слуМае этот¹ формат также Неявно указывает спецификацию работы» содержащую проформу, прк использовании в параметре <запись управления передаяеЯ>. форматы. CONTA1NS-H£ADER (СОДЕРЖИТ ЗАГОЛО-ВОК), OOES-NOt-CONTATN-HfeADBR (НЕ СОДЕРЖИТ ЗАГОЛОВОК) и FIRST-HEADER-IS (ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ) всегда выбирают полную спецификацию работы.

• 3.4.4.2.2. Операторы выбора.

<оператор выбора>: : —

(EQUALS (РАВНО) |

LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА) ] FIRST-OF-LIST-IS (ИМЕЕТСЯ ПЕРВЫЙ ИЗ СПИСКА) | LAST-OF-LiSt-tS (ИМЕЕТСЯ ПОСЛЕДНИЙ ИЗ СПИСКА) | GT (БОЛЬШЕ ЧЕМ) |

GE^; (БОЛЬШЕ ИЛИ РАВНО) [

ЕТ (МЕНЬШЕ ЧЕМ) ]

LE (МЕНЬШЕ ИЛИ РАВНО);)

Значения параметра <опёратор выбора> GT (БОЛЬШЕ ЧЕМ), GE (БОЛЬШЕ ИДИ РАВНО), LT (МЕНЬШЕ ЧЕМ) и LE (МЕНЬШЕ ИЛИ РАВНО) параметра <оператор выборки> используется только с полями, которые являются целочисленными элементами (TOTAL.-SIZE (ОБЩИЙ РАЗМЕР)) и TIME-WAITING (ВРЕМЯ ОЖИДАНИЯ)). (См. п. 3.4.6).

Значение EQUALS (РАВНО) параметра <оператор выбора> может йрт^Мёняться К любому типу поля. Тестирование будет выполняться успешно только в том случае, если значение параметра <значение выбора> равно по типу и по значению этоМу полю (см. п. 3.4.4.2.3).

Три других параметра <оператор выбора> применяются к спискам; формат LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА) может также применяться к совокупности. Тестирование выполняется успешно только в том случае, если значение параметра <значение селектора> будет такого же типа, как элемент поля <зйголов(5к>, и будет соответствовать любому, первому или последнему элементу в списке.

В п. 3.4.6 определены операторы, которые могут быть применены к каждому полю заголовка.

• 3.4.4.2.3. Значения выбора.

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

Для каждого синтаксического элемента (базисного или структурированного типа данных) в поле <заголовок> значение литерала ANY-ITEM (ЛЮБОЙ ЭЛЕМЕНТ) может использоваться в поле Сзначение выбора> вместо синтаксического элемента соответствующего типа. Это соответствует любому синтаксическому элементу любого типа.

• 3.4.4.2.4. Модификация.

<модификация>: : =

<имя поля>

<оператор модификации^*

<значение модификации>

Этот параметр модифицирует одно поле выбранной проформы или спецификации работы, в. соответствии с параметром «Сопера-тор модификации> и <значение модификациях Если была выбрана полная спецификация работы, параметр <модификация> применяется к самой спецификации работы, относящейся к первому параметру <заголовок> в параметре <список заголовков>.

• 3.4.4.2.5. Операторы модификации.

Соператор модификациях : =

(SET-TO (УСТАНОВИТЬ В) |

REMOVE (УДАЛИТЬ) |

ADD (ДОБАВИТЬ))

Значения REMOVE (УДАЛИТЬ) и ADD (ДОБАВИТЬ) применяются только к совокупностям. Значение SET-TO (УСТАНОВИТЬ В) может применяться для любого типа поля. Операторы, которые могут применяться для каждого поля параметра <заго-ловокХ приведены в п. 3.4.6.

• 3.4.4.2.6. Значения модификации.

Это значение имеет такой же тип, как и поле <заголовок>, соответствующее параметру <имя полях за исключением операторов со значениями REMOVE (УДАЛИТЬ) и ADD (ДОБАВИТЬ), когда оператор имеет такой же тип, как и элемент поля заголовка. Если элемент добавляется к совокупности, которая уже содержит элемент, равный такому значению, совокупность не изменяется.

• 3.4.4.2.7. Имена полей.

<имя полях : =

(OSI-JOB-SUBMISSION-SYSTEM (СИСТЕМА. ПРЕДЪЯВЛЕНИЯ ЗАДАНИЯ МОДЕЛИ OSI) |

OSI-JOB-NAME (ИМЯ ЗАДАНИЯ МОДЕЛИ .OS 1) |

SUB-JOB-TYPE (ТИП ПОДЗАДАНИЯ) |

INITIATOR (ИНИЦИАТОР) |

OSI-JOB-LOCAL-REFERENCE (ЛОКАЛЬНЫЙ УКАЗАТЕЛЬ ЗАДАНИЯ МОДЕЛИ OSI) |

PRIMARY-MONITOR (ПЕРВИЧНЫЙ МОНИТОР) | SECONDARY-MONITORS (ВТОРИЧНЫЕ МОНИТОРЫ) | SECURITY-PARMS (ПАРАМЕТРЫ ЗАЩИТЫ) | AUTHORISATION-SET (УСТАНОВКА САНКЦИОНИРОВАНИЯ) |

ACCOUNT-SET (УСТАНОВКА СЧЕТА) |

PERMISSION-SET (УСТАНОВКА РАЗРЕШЕНИЯ) | SUBJOB-NAME-LIST (СПИСОК ИМЕН ПОДЗАДАНИЙ) | RELAYS (ПРОМЕЖУТОЧНЫЕ СИСТЕМЫ) |

TARGET (ЦЕЛЕВАЯ СИСТЕМА) |

SE-LISTS (СПИСКИ ПИ) J

SE-REF-LISTS (СПИСКИ УКАЗАТЕЛЕЙ ПИ) I

SOURCE-LISTS (СПИСКИ ИСХОДНЫХ АГЕНТСТВ) | SOURCE-REF-LISTS (СПИСКИ УКАЗАТЕЛЕЙ ИСХОДНЫХ АГЕНТСТВ) |

URGENCY (СРОЧНОСТЬ) |

HOLDS (ЗАДЕРЖКИ) |

ERROR-ACTION (ДЕЙСТВИЕ ПРИ ОШИБКЕ) |

TIME-WAITING (ВРЕМЯ ОЖИДАНИЯ) |

TOTAL-SIZE (ОБЩИЙ РАЗМЕР))

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

• 3.4.4.3. Операции по манипулированию передачей Сопервция по манипулированию передачей>: : =

(<операция уетановюо |

<операцйя йроверки> |

<операция отображения нередачи>) Соперация установки >: : =

SET

< уста повить свстемой = \>

<получатель = N >

<управлйющ*я спецвфикащгя> (см. п. 3.4.7)

«терапия проверки>:

CHECK

<проверить системой = N> (см. п. 3.4.2.1)

<получатель = N>

<управляющая спецификация> (см. п. 3.4.7) <операция отображения передачи>: : =

DISPLAY

(<пункт назначения | ALL)

<имя документа = S>

Операция SET (УСТАНОВКА) устанавливает параметр <за-пись управления передачей> (см. п. 3.4.7) в указанные значения. Эта операция обычно вызывается системой административного управления некоторой области, которая знает, что она является постоянным получателем спецификаций работы из этой области и хочет управлять такими передачами. Она делает это установкой записи управления передачей в посылающей области. Спецификация работы по манипулированию должна иметь санкцию для параметра <идентификация> открытой системы, указанной в поле <получатель >, и для параметра <идентификация> открытой системы в поле <установить системой>. Поле <установить системой> используется только для того, чтобы определить такую открытую систему, в которую должен быть послан последующий запрос на выполнение операции CHECK (ПРОВЕРИТЬ). Поле <установить системой> содержит имя открытой системы, система административного управления которой была определена так, чтобы конкретный путь передачи был управляемым. Обычно это поле должно быть идентично полю <получатель>, но может от него отличаться. Поле <получатель> содержит имя такой открытой системы, в которой передачи должны быть управляемыми. Эта операция устанавливает параметр <управляющая спецификация> для управления передачами к системе, указанной параметром Сполуча-тель>.

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

Примечание. Рекомендуется, чтобы открытые системы посылали запрос на выполнение операции по манипулированию CHECK (ПРОВЕРИТЬ) в открытую систему, указанную параметром <установитъ снстемой>, если эти открытые системы были отсоединены от среды открытых систем на некоторое время.

Операция CHECK (ПРОВЕРИТЬ) требует санкцию для параметра <идентификация> открытой системы, указанной параметром Спроверить системой>.

Операция DISPLAY (ОТОБРАЗИТЬ) передачи формирует параметр Сдокумент отображения передачи> (см. п. 3.5.3), содержащий копию поля <управляющйя спецификация> и поля установить системой> для указанного параметра <получатель>. Использование значения ALL (ВСЕ) отображает записи управления передачей для всех элементов <получатель>, которые не являются UNCONTROLLED (НЕКОНТРОЛИРУЕМЫЙ) (см. п. 3.4.7).

• 3.4.4.4. Операции по манипулированию уведомлениями Операции по манипулированию уведомлениями>: : =

(•Операция удаления> |

Операция отображения уведомления службы JTM>) Операция удалениям*: : =

DELETE <выбор уведомления>

Операция отображения уведомления службы JTM>: : =

DISPLAY <выбор уведомления>

<имя документа = Б>

<выбор уведомлениям :==

уточнение системы предъявления задания>

уточнение инициирующего агентства>

уточнение указателя >

уточнение имени задания>

уточнение подзадания>

уточнение типа>

уточнение события> уточнение системы предъявления задания>: : =

(NULL |

Оистема предъявления задания модели OSI>) (см. п. 3.4.4.2.7) уточнение инициирующего агентства>: : =

(NULL |

<идентификация инициирования> (см. п. 3.4.2.1)

<уточнение указателя>: : =

(NULL | Оокальный указатель задания модели OSI = S>) (см. п. 3.4.6) уточнение имени задания>: :==

(NULL |

Описок имен подзаданий>) (см. п. 3.4.3) уточнение типа>: : =

(NULL |

<тип подзадания>) (см. п. 3.4.3.3)

<уточнение событмя>: : =

(NULL |

<селектор уведомления^») (см. п. 3.4.2.2).

Параметр <выбор уведомления > указывает Все уведомления из подзаданий (или порожденных подзаданяй), которые имеют следующие параметры:

а) < система предъявления задания модели OSI> (если обеспечивается);

б) Слбкальйый указатель задания модели OSI> (если обеспечивается);

в) <идентификация инициирования> (если обеспечивается);

г) <имя задания модели OSI> (если обеспечивается);

д) <имя проформы> и <определяющее целое число > (если обеспечивается);

е) < тип подзадания > (если обеспечивается);

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

Операция DELETE (УДАЛИТЬ) удаляет эти уведомления-, опе_; рация DISPLAY (ОТОБРАЗИТЬ) отображает их как документ отображения уведомления службы ПОЗ (см. п. 3.5.1). Операция DELETE (УДАЛИТЬ) требует санкцию для параметра Саденти-фикация>, соответствующего параметру <элемент разрешения^*, который появлялся в спецификации работы, о которой должно быть выдано уведомление. Тип документа отображения уведомления службы JT-M приведен в п. 3.5.1.

• 3.4.4.5. Операции по перемещению уведомлений. Соперации по перемещению уведомленнй>: :=»

[<операция уведомле«ия}*С <операция уведомления^*: : =

[<Яндекс монитора ==1>]*С

<уведомление> (см. п. 3.3.2)

Каждый параметр Соперацйй уведомле*йк#> вызывает то, что одно уведомление обрабатывается (при достижении целевой системы), как указано спецификацией монйтора, указанной индексом монитора. Значение «нуль» указывает первичный монитор, а значения «один», чдва» и г; д. указывают последующие вторичные мониторы в списке вторичных мониторов из спецификация работы.

• 3.4.5. Проформы <проформа>: : =

<имя проформы=»8>

<данные управления порождением > (см. ft. 3.4.5.2) (<указатель проформы> | (см. п. 3.4.5.1) <спецификация проформы>)

гост f a4.im-rS3 c iqi

< число порождений ₽= I > Спецификация проформы>:

Спецификация подзадания> (см. и. 3.4.1)

Список проформ> (см. п. 3.4.1)

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

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

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

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

• 3.4.5.1. Указатели проформы. <указатель проформы>: : =

<нмя проформы—S> (см. ц. 3.4.5).

Это пале используется для указания параметра Спецификация подзадання> в поименованной проформе, указанной параметром <проформа>. Требуется, чтобы эта поименованная проформа, указанная параметром <праформа>₁ находилась в том же списке, указанном параметром Список проформ>, что и родительская проформа, относящаяся к проформе, указанной этим параметром < проформа >; она сама может быть «родителем». Если имеет место порождение, проформы верхнего уровня в новой спецификации работы имеют параметр <указатель проформы>, замененный параметром Спецификация подзадания> в этой поименованной проформе, указанной параметром <проформа>. (Кроме того, это может включить проформу, содержащую параметр <указатель проформы>).

• 3.4.5.2. Данные управления порождением.

Санные управления порождением>:

G 102 ГОСТ P 34.1983—93

(DEMAND-ONLY (ТОЛЬКО ЗАПРОС) |

ACCEPTANCE (ПРИНЯТИЕ) |

COMPLETION (ЗАВЕРШЕНИЕ) | CONDITIONAL (УСЛОВНЫЙ)) Это поле указывает, когда должно происходить порождение из проформы, указанной параметром <проформа>.

Если это поле указывает значение DEMAND-ONLY (ТОЛЬКО ЗАПРОС), порождение имеет место только при введении группы сервисных примитивов J-SPAWN из активности в исполняющем агентстве, введенных родительским подзаданием.

Если это поле указывает значение ACCEPTANCE (ПРИНЯТИЕ), порождение имеет место, когда все принимающие и исполняющие агентства родительского подзадания заданы с уровнем совершения операций или со значением ACCEPTANCE (ПРИНЯТИЕ) или со значением COMPLETION (ЗАВЕРШЕНИЕ).

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

Если это поле указывает значение CONDITIONAL (УСЛОВНЫЙ), подзадание создается как для значения COMPLETION (ЗАВЕРШЕНИЕ), но только при условии, что по решению указателя исходного агентства последующее порождение собирает, по крайней мере, один документ из исполняющего или исходного агентства в данной открытой системе.

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

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

Уровень совершения операций для запрошенного порождения указывается в примитиве запроса J-SPAWN. Для всех других порождений уровень PROVIDER-ACCEPTANCE (ПРИНЯТИЕ ПОСТАВЩИКОМ) испрльзуется, если порождение не является частью начального элементарного действия.

Когда несколько проформ, указанных параметром Спрофор-ма>, должны быть порождены в результате одного события (например, по примитиву запроса J-END-SIGNAL), то они порождаются в порядке их появления в списке, указанном параметром <список проформ>.

Любые примитивы J-GIVE, которые должны быть посланы из локальной области в агентство, выполняющее порождение, должны предшествовать выдаче сообщения о совершении операций до порождения следующей проформы. (Это гарантирует, что выбор операции MOVE (ПЕРЕМЕСТИТЬ) некоторыми проформами для объединения поименованных документов и последующее порождение проформы со значением CONDITIONAL (УСЛОВНЫЙ), чтобы объединить все оставшиеся документы,-продолжается правильно).

• 3.4.6. Списки заголовков

<список заголовков>: : = [Сзаголовок>]*Ь •<заголовок>: : =

<система предъявления задания модели OSI = N>

<идентификация инициирования> (см. п. 3.3.2)

<имя задания модели OSI —S> (см. п. 3.3.2)

<локальный указатель задания модели OSI = S> (см. п, 3.3.2)

<спецификация первичного монитора> (см. п. 3.4.2) Сспецификация вторичных мониторов> (см. п. 3.4.2) <санкционирование> (см. п. 3.4.2) <разрешения> (см. п. 3.4.2)

<счет> (см. п. 3.4.2)

Спараметры защиты=Е> (см. п. 3.4.2) <список имен подзаданий> (см. п. 3.4.3) <промежуточные системы> (см. п. 3.4.3) <целевая cncreMa = N> (см. п. 3.4.3) <срочность> (см. п. 3.4.3.1) <задержки> (см. п. 3.4.3.2) <тип подзадания> (см. п. 3.4.3.3) Ссписки пи>

<списки указателей пи>

<списки исходных агентств>

<списки указателей исходных агентств>

Сдействие при ошибке> (см. п. 3.4.3.4)

Свремя ожидания = 1> (см. п. 3.4.1)

<подсчитанный размер = 1> (см. п. 3.4.1) Ссписки пи>: : =

[Сидентификация пи>]*Ь (см. п. 3.4.4.1.1)

Ссписки указателей пи>: : =

{Суказатель пи документа>]*Ь (см. п. 3.4.4.1.2)

С. 1М ГОСТ Г M.W8S— м

Ссписки исходных агентств>: : =

[Сидентификация исходного агентства>)*Е (см. п. 3.4.4.1.3)

Ссписки указателей исходных агентств>: : =

[Сукаэатель источника документов>Л*Ь (см. п. 3.4.4.1.3)

Эти ноля соответствуют полям в спецификации работы или проформе. Изменение полей в параметре Ссписок заголовков> изменяет соответствующую спецификацию работы или проформу.

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

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

Параметр С пароль^* в параметре Сукаэатель пи документа > и параметр Ссекретные данные> в поле Споле доступа> в элементе, указанном параметром Сэлемент санкционирования> или в элементе, указанном параметром Сэлемент счета>, всегда появляется как элемент NULL (НОЛЬ) в параметре Сзаголовок>.

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

*Ссистема предъявления задания OSI>

Это определено в п. 3.3.2. Может применяться только значение EQUALS (РАВНО).

• * Сидентификация инициирования>

Это определено в п. 3.3.2. Может применяться только значение EQUALS (РАВНО).

• * С имя задания модели OSI>

Это определено в п. 3.3.2. Может применяться только значение EQUALS (РАВНО).

• * Слокальный указатель задания модели OSI>

Это определено в п. 3.3.2. Может применяться только значение EQUALS (РАВНО).

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

гост ? м.од-ts о iw

Это определено в п. 3.4.2. Операциями являются значения EQUALS (РАВНО) и SET-TO (УСТАНОВИТЬ В). Значение SET-TO (УСТАНОВИТЬ В) требует санкционирования для параметра <идентификация> системы предъявления задания модели OSI.

• * <спецификации вторичных мониторов>

Оии определены в п. 3.4.2. Операциями являются значения EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА), SET-TO (УСТАНОВИТЬ В), REMOVE (УДАЛИТЬ) и ADD (ДОБАВИТЬ). В случае спецификаций работы уведомления разрешенными операциями являются только EQUALS (РАВНО) и LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА).

• * <санкционирование>

Этот параметр определен в 3.4.2 (при.этом все параметры <сек-ретные данные> в полях <поле доступа> появляются как значение NULL (НОЛЬ) в параметрах <заголовок>). Операциями являются EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА) и ADD (ДОБАВИТЬ). (Параметр <доступ>, содержащий проверяемый индекс, не может появиться в операции ADD (ДОБАВИТЬ).

• * <разрешения>

Этот параметр определен в п. 3.4.2. Операциями являются EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА), ADD (ДОБАВИТЬ) и REMOVE (УДАЛИТЬ). Операция REMOVE (УДАЛИТЬ) требует санкционирования на удаляемый предмет.

• * <счета>

Этот параметр определен в п. 3.4.2 (при этом все параметры <секретные данные> в полях <гюле доступа> появляются как значение NULL (НОЛЬ) в параметрах <заголовок>). Операциями являются EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА) и ADD (ДОБАВИТЬ). (Параметр <доступ>, содержащий проверяемый индекс, не может появиться в операции ADD (ДОБАВИТЬ).

• * <параметры защиты>

Это определено в п. 3.4.2. Может применяться только значение EQUALS (РАВНО).

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

Этот список определен- в п. 3.4.3 для первого заголовка. В заголовке для проформы это поле имеет ряд компонентов имен подзаданий, по одному компоненту для каждого имени проформы, используемого для доступа к ней. Первым компонентом является имя проформы верхнего уровня примитива запроса J-INITIATE, послед-

С. 106 ГОСТ Р 34.1983—93

ней — имя этой проформы. Значением параметра Сопределяющее целое число> является ноль, если спецификация подзадания все еще находится в формате проформы. Может применяться только EQUALS (РАВНО) и FIRST-OF-LIST-IS (ПЕРВЫЙ ИЗ СПИСКА).

<промежуточные системы>

Это поле определено в п. 3.4.3. Операциями являются EQUALS (РАВНО), SET-TO (УСТАНОВКА В), FIRST-OF-LIST-IS (ПЕРВЫЙ ИЗ СПИСКА), LAST-OF-LIST-IS (ПОСЛЕДНИЙ ИЗ СПИСКА).

<целевая система>

Это поле определено в п. 3.4.3. Операциями являются EQUALS (РАВНО) и SET-TO (УСТАНОВКА В).

<срочность>

Это поле определено в п. 3.4.3.L Операциями являются EQUALS (РАВНО), SET-TO (УСТАНОВКА В). Операция SET-TO (УСТАНОВКА В) требует санкционированного параметра <иден-тификация>, равного идентификации системы предъявления задания модели OSI.

<задержки>

Это поле определено в п. 3.4.3.2. Операциями являются EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА), SET-TO (УСТАНОВКА В), REMOVE (УДАЛЕНИЕ), ADD (ДОБАВЛЕНИЕ). Операция REMOVE (УДАЛЕНИЕ) требует санкции для параметра <идентификация>, появляющегося в элементе, указанном параметром <элемент задержки>, или для его параметра <санкция>, или для системы, указанной параметром <открытая система>, поименованной в одной из систем, указанной параметром <целевая система> или <промежуточная систе-ма>.

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

Это поле определено в п. 3.4.3.3. Операцией является только EQUALS (РАВНО).

<списки пи>

Этот список содержит все параметры Сидентификация пи>, появляющиеся в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров Сидентификация пи>. Операциями являются EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА), SET-TO (УСТАНОВКА В).

Ссписки указателей пи>

Этот список содержит все параметры Суказатель пи докумен-та>, появляющиеся в параметре <блок документа> в специфика-

ции подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров <указатель пи документа>. Отметим, что пЬле <пароль> всегда имеет значение NULL (НОЛЬ). Операциями являются EQUALS (РАВНО), LIST-CONTAINS (СОДЕРЖИМОЕ СПИСКА), SET-TO (УСТАНОВКА В).

<списки исходных агентств>

Этот список содержит все параметры <идентификация исходного агентства>, расположенные в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров < идентификация исходного агентства>. Операциями являются EQUALS (РАВНО), LISTCONTAINS (СОДЕРЖИМОЕ СПИСКА), SET-TO (УСТАНОВКА В)..

Ссписки указателей исходных агентств>

Этот список содержит все параметры Суказатель источника до-кумента> и Сконструкция источника документа^*, расположенные в полях Сблок документа> в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество элементов в списке. Отметим, что поле <пароль> всегда имеет значение NULL (НОЛЬ). Операциями являются EQUALS (РАВНО), LISTCONTAINS (СОДЕРЖИМОЕ СПИСКА), SET-TO (УСТАНОВКА В).

Сдействие при ошибке>

Это поле определено в п. 3.4.3.4. Операциями являются EQUALS (РАВНО) и SET-TO (УСТАНОВКА В).

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

Это поле определяется в п. 3.4.1. Допустимы только операции EQUALS (РАВНО), GT (БОЛЬШЕ ЧЕМ), GE (БОЛЬШЕ ИЛИ РАВНО), LT (МЕНЬШЕ ЧЕМ), LE (МЕНЬШЕ ИЛИ РАВНО). * Собщий объем>

Это поле определено в п. 3.4.1. Оно равно нулю, если только не ожидается передача спецификации работы. Допустимы только операции EQUALS (РАВНО), GT (БОЛЬШЕ ЧЕМ), GE (БОЛЬШЕ ИЛИ РАВНО), LT (МЕНЬШЕ ЧЕМ), LE (МЕНЬШЕ ИЛИ РАВНО).

• 3.4.7. Записи управления передачей

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

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

с. 1н гост р

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

<запнсь управления передачей>:: =

<установить системой = N>

<штамп времени> (см. п. 3.3.2)

<получятель = Ы>

<управляющая спецификация> <управляющая спецификация>:: =

(UNCONTROLLED (НЕУПРАВЛЯЕМЫЙ) |

<выбор>)

<выбор>:: = [<селектор>]*Е (см. п. 34.4.2.1)

Первоначально все записи управления передачей, хранящиеся открытой системой, устанавливаются в значение UNCONTROLLED (НЕУПРАВЛЯЕМЫЙ). В этом случае открытая система будет делать попытки передачи с согласованностью действий, определенной локально. Она может принять любой алгоритм для выбора спецификаций работы при передаче. (Алгоритмы будут обычно использовать некоторые комбинации типа «Первым обслуживается самый ранний запрос», «Первым обслуживается самый малый запрос» и «Первым обслуживается запрос с наивысшим параметром <срочность>»).

Если значением этого параметра является UNCONTROLLED (НЕУПРАВЛЯЕМЫЙ)., то параметры <установка системой> и <штамп времени> не записываются. Параметр <штамп време-ни> показывает время выполнения операции SET (УСТАНОВКА).

Если значением этого параметра не является UNCONTROLLED (НЕУПРАВЛЯЕМЫЙ), то параметр <выбор> используется не только для определения таких спецификаций работ, которые могут вызывать осуществление попыток передачи, но также для управления степенью согласованности действий. Если список параметра <выбор> является пустым, только спецификация работы по манипулированию передачей вызывает передачи. Передачи всегда разрешаются, но они не позволяют реализовать уровень параллельности выполнения действий, устанавливаемый параметром <выбор>, превышающий одно действие.

Если одновременно выполняется N передач для системы, указанной параметром <получатель>, то новая попытка передачи не начинает выполняться для спецификации работы до тех пор, пока список, указанный параметром <выборка>, не будет содержать, по крайней мере, N4-1 параметров <селектор> и (N-f-l)-fi оператор <селектор> выберет эту спецификацию работы.

Примечание. Это означает, что каждый селектор разрешает передачу не больше одной спецификации работы за один промежуток времени. В параметре <выбор> может быть несколько идентичных параметров <селектор>. Там, где более одной спецификации работы соответствуют параметру Сселек-тор^>, выбор спецификации работы для передачи является локальным делом реализации (см. также п. 3.4.3.1).

3.5. Документы службы ПОЗ

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

Документы могут формировать часть спецификации работы и параметры примитивов J-GIVE и J-DISPOSE.

• 3.5.1. Документ отображения уведомления службы ПОЗ Сдокумент отображения уведомления службы JTM>:: =

[<отображение уведомления службы JTM>]*L Сотображение уведомления службы JTM>:: =

<система монитора задания модели OSI = N>

<штамп времени> (см. п. 3.3.2)

[<уведомление>]*Ь (см. п. 3.3.2)

Когда эти документы сформированы службой ПОЗ, они содержат только один параметр ^отображение уведомления службы JTM>. Объединение этих документов составляет список отображений уведомлений службы ПОЗ.

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

Когда такие документы производятся пунктом монитора для использования примитива J-DISPOSE, чтобы разместить уведомление, указанное параметром Суведомление> в соответствии с параметром <дата размещениям», параметр <штамп времени> содержит время', указывающее, когда документ был создай пунктом монитора, и в подзадании типа REPORT-MOVEMENT (ПЕРЕМЕЩЕНИЕ УВЕДОМЛЕНИЯ) имеется только один параметр Сотображение уведомления службы JTM>, содержащий все параметры Суведомленйе>, которые были представлены.

Этот Тип документа указывается значением описателя объекта ASN. I ■(Abstract Syntax Notation One — Абстрактно-синтаксическая нотация версий 1 (АСН. 1)) (см. ГОСТ 34.973) параметра «документ отображения уведомления службы ПОЗ» и значением OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) нотации АСН. 1, которое указано в стандарте ИСО 8832.

• 3.5.2. Документ отображения работы, служба ПОЗ

<документ отображения работы>:: = [Сотображение работы>]*Ь

Сотображение работы>:: =

Ссистема отображения = М>

Сштамп времени> (см. п. 3.3.2)

[Сотображение спецификации работы>]*Ь

Сотображение спецификации работы>:: =

(Сполное отображение> |

С короткое отображение>)

Сполное отображением: =

Ссписок заголовков> (см. п. 3.4.6)

[Ссостояние системы назначения>]*С

Ссостояние системы назначения>:: =

Ссистема назначения> Ссостояние>

Сштамп времени> (см. п. 3.3.2) [CTeKCT=S>]*L

Сдиагностическое сообщение элемента CCR>

Ссистема назначения>:: = (Сполучатель=М> | С исходное агентство > | Спи агентство>)

С исходное агентство>:: =

(Симя источника = 5> |

Симя файлохранилища = N>) (см. п. 3.4.4.1.3)

Спи агентство>:: =

(Симя пи=Б> |

Симя файлохранилища=Ы>) (см. п. 3.4.4.1.1) Ссостояние>:: =

(IN-PROGRESS (ВЫПОЛНЯЕТСЯ) | ACCEPTED (ПРИНЯТО) | WAITING (ОЖИДАНИЕ))

Скороткое отображение>:: =

Сидентификация подзадания> (см. п. 3.3.2) [Ссостояние системы назначения>]*С

Поле Сштамп времени> в параметре Сотображение работы> представляет время, когда было произведено отображение.

Поле Ссписок заголовков> в параметре Сполное отображе-ние> содержит заголовки, указанные параметром Сзаголовок> для выбранного подзадания и для всех проформ, содержащихся в нем.

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

Параметр Сдиагностическое сообщение элемента CCR> содержит последнее принятое диагностическое сообщение «повторить позже» и отсутствует, если только значение параметра Ссостоя-ние> не является WAITING (ОЖИДАНИЕ).

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

Значение IN-PROGRESS (ВЫПОЛНЯЕТСЯ) означает, что в настоящее время выполняется элементарное действие. Поставщик услуг службы ПОЗ формирует текст, указанный параметром Стекст>, который содержит читабельную нестандартизованную информацию.

Значение ACCEPTED (ПРИНЯТО) означает, что агентством было выдано сообщение о совершении операций по приему информации. Список текстов получается при помощи примитива J-STATUS, который возвращает читабельную нестандартизованную информацию.

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

Объединение этих документов создает новый список отображений работы.

Тип этого документа указывается значением описателя объекта АСН. 1 (см. ГОСТ 34.973) параметра

«документ отображения работы службы ПОЗ»

и значением OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) нотации АСН. 1, которое указывается в стандарте ИСО 8832.

• 3.5.3. Документ отображения записи TCR службы ПОЗ Сдокумент отображения передачи>:: =

[Сотображение передачи>]*Ь Сотображение передачи>:: =

Ссистема oтoбpaжeния = N>

Сштамп времеян> (см. п. 3.3.2)

[Сзапцсь управления передачей>]*Ь (см. п. 3.4.7)

Значение параметра Сштамп времени> представляет время, в-которое производилось отображение.

Объединение этих документов создает новый список параметров Сотображение передач>.

Тип этого документа указывается значением описателя объекта АСН. 1 (см. ГОСТ 34.973) параметра

«документ отображения записи 1сг службы ПОЗ>

и значением OBJECT HDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) нотации АСН. 1, которое указывается в расширенной спецификации протокола службы ПОЗ.

3.6. Параметры сервисных примитивов службы ПОЗ

3.6 А.Примитивы запроса и подтверждения /-INITIATE

Примитив запроса J-INITIATE содержит следующие ноля спецификации работы:

< идентификация инициирования> (см. п. 3.3.2)

Симя задания модели OSI> (см. п. 3.3.2)

^спецификация вторичного монитора>]*Ь (см. п. 3.4.2)

Ссавкционирование> (см. п. 3.4.2)

<разрешения> (см. п. 3.4.2)

Ссчета> (см. п. 3.4.2)

Спараметры защиты> (см. п. 3.4.2)

Сспецификация подзадания> (см. п. 3.4.1)

Ссписок проформ> (см. п. 3.4.1)

Ссписок документов > (см. п. 3.4.1)

Эти поля полностью определяют работу, которая должна быть выполнена.

Примитив подтверждения J-INITIATE содержит только один параметр

Слокальный указатель задания модели OSI = S>

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

Уровень совершения операций и параметры элемента СПиВ индикатора кода диагностического сообщения (представленный примитивом J-BEGIN) «выбираются при помощи введения примитива запроса J-INITIATE.

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

• 3.6.2. Сервисные примитивы J-D1SPOSE

З.6.2.1. Примитив индикации J-DISPOSE.

Примитив индикации J-DISPOSE вводится системой, указанной параметром <целевая система> в спецификации работы, в принимающее или исполняющее агентство, указанное полем <имя nn = S> для формата <пи службы JTM>, и в локальное принимающее агентство, осуществляющее доступ к службе ПДУФ для формата <принимающее агентство службы FTAM>.

Примитив индикации J-D1SPOSE содержит следующие параметры:

<идентификатор активности поставщика = S>

<санкция пользователя>

<счет пользователя>

Сдополнительное санкционирование> (см. п. 3.4.4.1.1)

(<имя файлохранилища = М> |

<параметр агентства>) (см. п. 3.4.4.1.1)

<указатель пи документа> (см. п. 3.4.4.1.2)

<ошибки>

<вводимый документ>

<ошибки>:: =

[Сдиагностическая информация>]*Ь (см. п. 3.3.3) <санкция пользователя^: =

(NOT-KNOWN (НЕИЗВЕСТНЫЙ) |

<идентификация> | (см. п. 3.3.2)

<элемент санкционирования^*) (см. п. 3.4.2.1) <счет пользователя^: =

(NOT-KNOWN (НЕИЗВЕСТНЫЙ) |

<идентификация> | (см. п. 3.3.2)

<элемент счета>) (см. п. 3.4.2.1)

<вводимый документ>:: =

<тип AOKyMeHTa = ND>

<документ=И>

Параметр < идентификатор активности поставщика> представляет локальную информацию, необходимую при идентификации активности для последующих групп примитивов, используемых агентством (например, таких, как J-END-SIGNAL, J-MESSAGE и т. д.). Его формат не стандартизован.

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

Параметры Ссанкция пользователя> и Сечет пользоватсля> получаются из параметров сэлемент санкционирования> и <эле-мент счета>. Они проверяются поставщиком услуг службы ПОЗ, если только обеспечивается параметр Сидентификация>, в противном случае обеспечивается полный параметр Сэлемент санкци-онирования> или Сэлемент счета>. Выбор, какой из параметров Сэлемент санкционирования> использовать для примитива J-DISPOSE, выполняется локальной директивной функцией, использующей имя принимающего или исполняющего агентства и санкционированное имя идентификации пользователя в параметре Сэлемент санкционирования^ Значение NOT-KNOWN (НЕИЗВЕСТНЫЙ) указывает, что не может быть найден соответствующий элемент санкционирования, и часто является причиной отказа агентства от совершения операций.

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

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

Группа примитива J-D1SPOSE также вводится в принимающее агентство, указанное в параметре Свводимые данные> (если этот параметр имеется) для монитора задания модели ВОС, при каждом уведомлении, которое поступает в монитор задания модели ВОС.

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

Параметр Сошибки> содержит список параметров Сдиагнос-тическая информациях формируемый из параметров Сидентификация исходного агентства> и < информация об ошибке> для любого параметра Суказатель единого документа> со значением FAILED (ОТКАЗАНО) параметра Ссостояние> (см. п. 3.4:4.1.3). Параметры Сошибки> (если эти параметры имеются) передаются в принимающее агентство вместе с параметром Свводимый до-кумент>. Размещение параметра Соши6ки> не стандартизовано.

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

Примечание. Необходимо, чтобы реализующие системы устанавливали типы документов, которые они- обеспечивают (для примитивов J-GIVE, J-DISPOSE и передачи). Предполагается, что реализующие системы, которые могут считаться универсальными, должны обеспечивать, по меньшей Мере, первые три типа документов, определенных в приложении В.

Размещение уведомлений в Принимающие агентства выполняется с помощью примитивов J-DISPOSE после преобразования параметра <уведомление> в параметр Соображение уведомления службы JTM>.

• 3.6.2.2. Примитив ответа J-DISPOSE.

Примитив ответа J-DISPQSE содержит единственный параметр

<идентификатор активности агентства = 5>

Он представляет локальную информацию, необходимую для идентификации активности для последующих групп примитивов, вводимых поставщиком услуг службы JTM (J-KILL, J-STATUS и т. д.). Его формат не стандартизован.

• 3.6.3. Сервисные примитивы J-GIVE

3.6;3.1. Примитив индикации J-GIVE.

Примитив индикации J-GIVE вводится в исходное или исполняющее агентство в результате обработки параметра Суказатель единого документа> или в результате обработки параметров Сконструкция документа исходного агентства> н Ссписок имен>, следующих за примитивом J-ENQUIRE. Следует обратиться к пп. 3.4.4.1.3 и 3.4.4.1.4 для более подробной информации об этих полях.

Примитив индикации J-GIVE вводится системой, указанной параметром

Соткрытая система выполнения действия = 1Ч>,

в исходное или исполняющее агентство, идентифицированное параметром Симя исходного агентства = S> для формата Спи службы JTM.>, и в локальное исходное агентство, осуществляющее доступ к службе FTAM для формата С исходное агентство службы FTAM>.

Примитив индикации J-GIVE содержит следующее параметры:

Ссанкция пользователя> (см. п. 3.6.2)

Сечет пользователя> (cm.il 3.6.2)

С дополнительное санкционирование> (см. п. 3.4.4.1.1)

Суказатель источника документа> (см. п. 3.4.4.1.3)

(Симя файлохранилища = N> |

Спараметр агентства = 5>) (см. п. 3.4.4.1.3)

Стип документа = ND>

Сгруппа документам* Сгруппа документа>:: =

(PERMANENT (ПОСТОЯННАЯ) |

<группа конца активности> |

Сгруппа проформы>) Сгруппа конца активности>:: =

С идентификатор активности агентства > (см. п. 3.6.2) Сгруппа проформы>:: =

С идентификатор активности агентства > (см. п. 3.6.2)

Симя проформы = Б>

Все параметры и их смысл определены в предыдущих разделах, кроме параметра Сгруппа документа^*. Этот параметр будет иметь значение PERMANENT (ПОСТОЯННЫЙ) до тех пор, пока примитив J-GIVE не будет введен в исполняющее агентство со значением Сгруппа конца активности> или со значением Сгруппа про-формы>. В этом случае это означает, что примитив индикации J-G1VE для документа является доступным в конце активности или получается с помощью порождения поименованной проформы, указанной параметром <проформа>, соответственно.

Если параметр Симя исходного агентства> указывает на исполняющее агентство, то активность, к которой относится примитив J-GIVE,¹ идентифицируется параметром С идентификатор активности агентства>. Из множества документов, к которым должен осуществляться доступ, те, которые становятся доступными в конце активности, имеют параметр Сгруппы конца активности>, а те, которые доступны, когда вводится примитив J-SPAWN, имеют параметр Сгруппа проформы> в примитиве индикации J-GIVE. В дальнейшем параметр Симя проформы> будет таким, который появился в примитиве J-SPAWN.

• 3.6.3.2. Примитив ответа J-GIVE.

Примитив ответа J-GIVE содержит единственный параметр Сдокумент>. Документ, указанный параметром <документ> имеет тип, указанный параметром Стип документа> в примитиве индикации J-GIVE. Отметим, что если соответствующий документ не может быть найден, примитив запроса J-REFUSE вводится вместо примитива ответа J-GIVE, и диагностика С-СЕРВИСНЫй ПРИже если при последнем доступе указывается значение операции MOVE (ПЕРЕМЕЩЕНИЕ). Исходный документ удаляется только тогда, когда все группы примитивов J-GIVE совершили операции или возвращены в первоначальное состояние, по меньшей мере, с одним совершением операций по отношению к значению операции MOVE.

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

• 3.6.4. Примитивы индикации и ответа /‘ENQUIRE

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

Исходное или исполняющее агентство, в которое этот примитив вводится, получает его также как и примитив индикации J-GIVE. Он содержит следующие параметры:

Ссанкция пользователя> (с.м. п. 3.6.2)

<счет пользователя> (см. п. 3.6.2)

«^дополнительное санкционирование> (см. п. 3.4.4.1.1) Спараметр агентства = 5> (см. п. 3.4.4.1.1)

<конструкция документа исходного агентства > (см. п. 3.4.4.1.4) Сселектор документа = S> (см. п. 3.4.4.1.4)

<тип документа == ND >

Сгруппа документа> (см. п. 3.6.3.1)

Примитив ответа J-ENQUIRE содержит только параметр [<список имен>]*С.

Примитив J-ENQUIRE используется для получения имен всех документов, чьи имена, указанные в списке <список имен>, начинаются с последовательностей, указанных параметром <список частичных имен> в параметре Сконструкция документа исходного агентствах и к которым возможен доступ при помощи примитива J-GIVE, используя указанные параметры (см. п. 3.4.4.1.4).

Возвращенный параметр <список имен> представляет собой суффиксы, которые должны быть добавлены к параметру <список частичных имен> при введении примитивов J-GIVE.

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

С. 118 ГОСТ Р 34.1983—93

• 3.6.5. Примитив запроса J-MESSAGE

Примитив запроса J-MESSAGE содержит параметры:

<идентификатор активности поставтцика>

<сообщеНие>

<сообгцеиие>:: =

[<TeKCT = S>]*L

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

Параметр <уровень совершения операций> устанавливается в значение PROVIDER-ACCEPTANCE (ПРИНЯТИЕ ПОСТАВЩИ-КОМ), и элементарное действие всегда выполняется до совершения операций. Индикатор кода диагностического сообщения идентичен индикатору в соответствующем примитиве J-DJSPOSE, а параметр <сообщенис> соответствует наборам символов, требуемым индикатором кода диагностического сообщения. Каждая строка параметра <текст> в параметре'<сообщение> ограничивается по длине до 40 символов.

• 3.6.6. Примитив запроса J-SPAWN

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

< идентификатор активности поставщика>

<имя проформы«=5>

После соответствующего примитива индикации J-READY любые документы, которые должны использоваться при порождении, могут быть удалены (выбор при помощи примитива J-GIVE завершается).

Параметр Суровень совершения операций> может принять некоторое определенное значение. Элементарное действие может быть отвергнуто с помощью¹ примитива J-REFUSE.

• 3.6.7. Примитив запроса J-END-S1GNAL

Примитив запроса J-END-SIGNAL неявно ссылается на более ранний примитив J-DISPOSE, который задал уровень совершения операций ACCEPTANCE (ПРИНЯТИЕ). Этот примитив содержит только параметр

«^идентификатор активности поставщика>

Если включается только одна активность, то она вызывает то, что все проформы верхнего уровня, отмеченные для порождения с условием. COMPLETION (ЗАВЕРШЕНИЕ) или CONDITIONAL (УСЛОВНЫЙ), обязательно порождаются в порядке их появления в списке, указанном параметром <список проформ>. (см. также п. 3.4.5.2). Если включено больше одной активности, то порождение завершается только в том случае, если завершаются все группы примитивов J-END-SIGNAL.

Уровень совершения операций равен I и элементарное действие всегда протекает до совершения операций.

• 3.6.8. Примитивы индикации и ответа J-STATUS

Примитив индикации J-STATUS вводится поставщиком услуг службы ПОЗ в принимающее или исполняющее агентство, которое сообщило о совершении операций уровня ACCEPTANCE (ПРИНЯТИЕ) примитива J-DISPOSE, но еще не был введен примитив запроса J-ENDSIGNAL. Он содержит только параметр <идентифи-катор активности агентства>. Примитив ответа содержит единственный параметр

<сообщение о состояпли>, где <сообп1снис о состоянии> =

[<TeKCT=S>]fL

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

Это элементарное действие всегда выполняется до совершения операций. Набор символов в сообщении о состоянии соответствует требованиям индикатора кода диагностического сообщения. Каждая строка параметра <текст> ограничена по длине до 40 символов.

• 3.6.9. Примитивы индикации J-HOLD, J-RELEASE, J-KILL, J-STOP

Эти примитивы содержат только параметр <идентификатор активности агентства>.

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

С. 120 ГОСТ Р 34.1983—93

са J-MESSAGE,-J-SPAWN или J-END-SIGNAL нс вводятся до тех пор, пока не будет принят примитив индикации J-RELEASE.

Примитив индикации J-RELEASE разрешает введение примитивов запроса J-MESSAGE, J-SPAWN и J-END-SIGNAL и используется для отмены примитива J-HOLD.

Примитив индикации J-K1LL требует, чтобы принимающее или исполняющее агентство завершило активность, начатую примитивом J-DISPOSE, и сформировало и ввело примитив запроса J-END-SIGNAL. Примитив J-END-SIGNAL не может обеспечить никаких документов. (Поставщик услуг службы ПОЗ не вводит группы примитивов J-ENQUIRE или J-GIVE).

Примитив индикации J-STOP имеет такое же действие, как примитив J-KILL, но документы будут доступны в результате выполнения примитива J-END-SIGNAL. (Поставщик услуг службы ПОЗ вводит группы примитивов J-ENQUIRE и J-GIVE). Управляемый логический объект не вводит примитив J-REFUSE для этих элементарных действий, но управляющий логический объект может потребовать возвратиться в первоначальное состояние.

• 3.6.10. Краткая сводка

Краткая сводка сервисных примитивов службы ПОЗ представлена в табл. 3. Указания по их использованию представлены в табл. 2.

Группа примитивов ^-INITIATE может вызывать в последствии, что сервисные примитивы будут введены как прямой результат выполнения первого подзадания. Если первое подзадание порождает дальнейшие подзадания либо при помощи примитива J-SPAWN, либо при помощи примитива J-END-SIGNAL, либо при завершении примитива J-DISPOSE, либо после манипулирования, то в последствии могут возникнуть группы примитивов. Группы примитивов, вызванные первоначальными группами примитивов J-1NITIATE, могут возникнуть одновременно с такой группой примитивов или могут существовать после нее, в зависимости от уровня совершения операций. Так как проформа может содержать любой тип подзадания (кроме REPORT-MOVEMENT (ПЕРЕМЕЩЕНИЕ УВЕДОМЛЕНИЯ), то любой тип группы примитивов J-IN1TIATE может развиться до всех форм сервисного примитива, в зависимости от его параметров. Кроме этого, уведомления о сообщениях, включая уведомления, вызываемые группой примитивов J-MESSAGE, могут произвести примитив J-DISPOSE. В табл. 2 приведены элементы примитивов, потенциально используемых при обработке одного подзадания.

Продолжение табл. 3

Продолжение табл. 3

РАЗДЕЛ 4. БАЗИСНЫЙ КЛАСС

• 4.1. Группы примитивов й типы документов для базисного класса

• 4.1.1. Группы сервисных примитивов

Можно использовать следующие группы сервисных примитивов:

J-INITIATE-WORK

J-INITIATE-WORK-MAN

J-DISPOSE

J-GIVE

J-END-S1GNAL

J-STATUS

J-KILL

J-STOP

J-MESSAGE

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

а) J-INITIATE-WORK;

б) J-INITIATE-WORK-MAN;

в) J-DISPOSE (к принимающему или исполняющему, агентству) с уровнем совершения операций COMPLETION (ЗАВЕРШЕНИЕ) в примитиве J-READY;

г) J-G1VE (для группы конца активности);

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

J-END-SIGNAL

J-STATUS

J-MESSAGE

J-KILL

J-STOP

Система базисного класса не обеспечивает значение COMPLETION (ЗАВЕРШЕНИЕ) для уровня совершения операций в примитивах C-BEGIN или J-BEGIN. Она, однако, может возвратить такое значение или принять такое значение в примитиве C-READY или J-READY.

• 4.1.2. Типы документов

Системам базисного класса нет необходимости обеспечивать полную классификацию типов документов. Стандарт ИСО 8832 определяет три типа документов, обозначаемых значениями описателя объекта АСН. 1 (см. ГОСТ 34.973) :

«Простой текстовый документ»;

«Простой документ для печати»;

«Простой документ в двоичном формате».

Для краткости эти типы документов указывают в настоящем разделе только как «текст» (1), «печать» (2) и «двоичный» (3), соответственно.

Кроме этого, в базисном классе используются следующие типы документов (см. п. 3.5):

«Документ отображения работы службы ПОЗ;

«Документ отображения уведомления службы ПОЗ.

Для краткости эти типы документов указывают в настоящем разделе только как «отображение работы» (4) и «отображение уведомления» (5) (см. также п. 4.2.1).

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

в примитиве J-INITIATE-WORK

текст (1) печать <2) в проформе в примитиве J-INITIATE-WORK печать (2)

в проформе в примитиве J-INITIATE.-WORK-MAN отображение работы (4) (только кратко)

в примитиве J-GIVE печать (2) в примитиве J-DISPOSE текст (1) печать (2) отображение уведомления (5) отображение работы (4) (только кратко)

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

• 4.2. Концептуальные структуры данных для базисного класса

В данном разделе описаны подмножества структур данных (определенных в пп. 3.3, 3.4 и 3.5), которые используются в базисном классе. Я. 4.3 описывает дополнительные ограничения базисного класса, накладываемые на параметры сервисных примитивов.

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

• 4.2.1. Уведомления

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

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

<уведомление>:: =

<имя уведомителя>

<штамп времени>

<идентификация подзадания>

<идентификация события>

Спараметры события> -

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

<идентификация события>:: =

(NORMAL-TERMINATION (НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ) |

MANIPULATION-TERMINATION (ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ) | _

ABNORMAL-TERMINATION (АВАРИЙНОЕ ЗАВЕРШЕНИЕ) |

USER-MESSAGE (СООБЩЕНИЕ ПОЛЬЗОВАТЕЛЯ))

Другие события не распознаются в базисном классе. Уведомления о других событиях не обрабатываются пунктами монитора базисного класса. Запросы (в параметре <селектор уведомлений>) на уведомления о других событиях вызывают формирование спецификации работы, которая должна быть отвергнута системой базисного класса.

Обеспечиваемыми значениями параметра <параметры собы-тий> являются: <число порождений>, <текст> и Сдиагности-ческос сообщением

• 4.2.1.1. Диагностическая информация.

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

Поля <детали источника> и <детали пи> не относятся к активности службы ПДУФ, а параметр «^диагностическое сообщение элемента CCR> не содержит параметра <результат службы FTAM>.

• 4.2.1.2. Информация учета.

Информация учета не формируется системами базисного класса. Если информация учета передается к таким системам в примитивах C-READY или C-REFUSE, она игнорируется.

• 4.2.2. Спецификации работы.

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

Сспецификация работы>:: =

<параметры задания модели OSI>

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

Ссписок проформ > Слокальные поля> < список доку ментов >

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

Сспецификация подзадания>:: =

Спараметры подзадания модели OSI>

Спараметры действия службы JTM> Сдействие при ошибке>

С действие при ошибке>:: =

TERMINATE (ЗАВЕРШИТЬ)

Ссписок проформ>;: = [Спроформа>1*Ь

Ссписок документов>::==

[Сдокумент>]*Ь

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

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

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

• 4.2.2.1. Параметры задания модели ВОС.

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

<параметры задания модели OSI>:: =

<снстема предъявления задания модели OSI>

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

<время инициирования>

<имя задания модели OSI>

<локальный указатель задания модели OSI>

<проверочная трасса>

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

<санкционирование>

<разрешения>

<параметры элемента CCR>

Отметим, что параметры <спецификация вторичного монитора^ <счет> и <параметры защиты> не представлены..

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

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

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

Параметр -Сспецификация первичного монитора> не содержит никакого параметра <промежуточная система>, а параметр <ин-струкция по размещению> не имеет значения KEEP (СОХРАНИТЬ).

Параметр <селектор уведомлений> содержит только следующие категории событий:

NORMAL-TERMINATION (НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ)

MANIPULATION-TERMINATION (ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ)

ABNORMAL-TERMINATION (АВАРИЙНОЕ ЗАВЕРШЕНИЕ) USER-MESSAGE (СООБЩЕНИЕ ПОЛЬЗОВАТЕЛЯ)

• 4.2.2.2. Параметры подзадания модели ВОС.

Спараметры под за далия модели OSI>:: =

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

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

• < срочность >

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

Параметр Ссписок целевых систем> содержит только параметр Сцелевая система> для какой-либо спецификации работы, передаваемой в систему базисного класса или формируемой там с помощью порождения или при помощи примитива J-INITIАТЕ. Параметр Сзадержки> также отсутствует в таких подзаданиях.

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

Параметр <тип подзадания> имеет одно из следующих значений:

REPORT-MOVEMENT (ПЕРЕМЕЩЕНИЕ УВЕДОМЛЕНИЯ) DOCUMENT-MOVEMENT (ПЕРЕМЕЩЕНИЕ ДОКУМЕНТА) WORK-MANIPULATION (МАНИПУЛИРОВАНИЕ РАБОТОЙ)

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

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

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

Имеется один параметр <перемещение документа> и один параметр С идентификация пи>. Параметр <блок документа> представляет собой параметр <единый формат>.

Параметр <идентификация пи> не имеет формата <ни службы FTAM>. Он не имеет параметра «^дополнительное санкционирование^ параметр Спараметр агентства> имеет значение NULL (НОЛЬ), а параметр <префикс пи> является пустым.

Параметр «С указатель пи документа> не имеет формата Списать данные службы ЕТАМ>, а параметр Спараметр доступа пи> имеет значение NORMAL (НОРМАЛЬНОЕ).

Имеется один параметр Суказатель документа^*, который при достижении целевой системы базисного класса имеет значение

9 Зак. 815

С. 130 ГОСТ Р 34.1983—93

EMBEDDED (ВЛОЖЕННЫЙ) или содержит один параметр <указатель единого документа> со значением параметра <состо-яние> FAILED (ОТКАЗАНО).

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

Если параметр Соперации по перемещению документа> имеется в подзадании верхнего уровня, произведенного в системе базисного класса с помощью порождения, то может присутствовать параметр Суказатель единого документа> с состоянием NOT-AT-TEMPTED (НЕТ ПОПЫТКИ). Если система, указанная параметром Соткрытая система выполнения действия>, является локальной системой, параметр <идентификация исходного агентства> имеет либо значение PROVIDER (ПОСТАВЩИК), либо значение параметра Сисходное агентство службы JTM>, который представляет собой исполняющее агентство, и здесь имеется параметр <па-раметр агентства> со значением NULL (НОЛЬ) и параметр <па-раметр доступа к исходному агентству> со значением MOVE (ПЕРЕМЕЩЕНИЕ).

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

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

Параметр <операции спецификации работы> содержит строго два параметра <операция работы>. Первый параметр <опера-ция работы> имеет значение SELECT <селектор> (ВЫБРАТЬ <селектор>) (см. ниже).

Второй параметр имеет одно из следующих значений:

KILL (УНИЧТОЖИТЬ)

STOP (ОСТАНОВ)

DISPLAY <имя документа> BRIEF (ОТОБРАЗИТЬ <имя документа> КОРОТКОЕ).

Параметр <селектор> содержит три параметра <тест поля>, составленные из параметров <оператор AND (И)> для получения параметра <тест заголовка^*. Тогда параметр <селектор> будет иметь значение

FIRST-HEADER-IS (ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ)

<тест заголовка>

Три параметра <тест поля> содержат тесты на пригодность трех полей

OSI-JOB-SUBMISSION-SYSTEM (СИСТЕМА ПРЕДЪЯВЛЕНИЯ ЗАДАНИЯ МОДЕЛИ OSI)

OSI-JOB-NAME (ИМЯ ЗАДАНИЯ МОДЕЛИ OSI) SUB-JOB-TYPE (ТИП ПОДЗАДАНИЯ)

Использование значения ANY-ITEM (ЛЮБОЙ ЭЛЕМЕНТ) не обеспечивается в базисном классе.

В системах базисного класса концептуальная структура данных «список заголовков» содержит, таким образом, только один заголовок и только с этими тремя полями.

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

• 4.2.5. Операции по перемещению уведомлений

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

а) индекс монитора всегда имеет значение «ноль» (только первичные мониторы);

б) параметры <вводимые данные> не имеют значение KEEP

(сохранить):

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

• 4.2.6. Проформы

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

• 4.2.7. Прозрачность проформ

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

Спецификация работы, созданная с помощью порождения (или при помощи примитива J-INITIATE), может (первый случай) или не может (второй случай) иметь такую открытую систему, которая указана параметром Сцелевая система>.

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

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

• 4.2.8. Записи управления передачей

Системы базисного класса не распознают понятие записей управления передачей и не обеспечивают подзадаиия типа TCR-MA-NIPULATION (МАНИПУЛИРОВАНИЕ TCR).

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

• 4.2.9. Документы службы ПОЗ

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

Если система предоставляет обеспечение для формирования примитива J-IN1TIATE-MAN, она обеспечивает прием таких документов и их размещение, используя примитив J4MSPOSE. Если система базисного класса обеспечивает пункт монитора, она способна преобразовать параметр <уведомление> (см. п. 4.2.1) в документ отображения уведомления службы ПОЗ и разместить этот документ, используя примитив J-DISPOSE, в принимающем агентстве.

Документ отображения записи TCR службы ПОЗ не обесценивается.

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

4.3. Параметры группы примитивов «/-INITIATE для базисного класса

В службе базисного класса группа примитивов J-INITIATE имеет подмножество параметров, доступных в расширенной службе JTM. Накладываются следующие ограничения.

Уровень совершения операций имеет только значения PROVIDER-ACCEPTANCE (ПРИНЯТИЕ ПОСТАВЩИКОМ) и AGEN-

гост р Э4лввз*-в$ а ив

CY-ACCEPTANCE (ПРИНЯТИЕ АГЕНТСТВОМ} в примитиве J-BEGIN.

Отсутствуют параметры Спецификация вторичного монито-ра>. Отсутствуют параметры <счет>. Отсутствуют параметры Спараметры зашиты>.

J-INITIATE-WORK подчиняется ограничениям, указанным в п. 4,2, но, кроме этого, дополнительно накладываются следующие ограничения.

• 4.3.1. Параметры верхнего уровня <параметры задания модели OSI> <параметры подзадания модели OSI> <параметры активности службы JTM> <действие по ошибке>

Это значение TERMINATE (ЗАВЕРШЕНИЕ)

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

Единственная проформа или нет проформ. (Единственная проформа не имеет вложенных проформ).

Список документов >

Единственный текстовый (1) документ или документ вывода на печать (2) для примитива^ J-INITIATE-WORK. Нет документов для примитива J-INITIATE-WORKMAN. Если документ является выводом на печать (2), то проформы отсутствуют.

• 4.3.2. Параметры задания модели ВОС

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

Любое значение

<имя задания модели OSI> Любое значение

Санные санкционирования>

Параметры <элемент санкциоинрования> и <элемент разрешения^ предоставляющие идентификацию пользователя и пароль для использования в открытой системе Сцелевая система>. Этот параметр используется для санкционированной активности службы ПОЗ, такой как манипулирование или возврат результата. Требуется, чтобы исполняющее агентство повторяло эту же самую информацию в заголовке документа («JCL»), передаваемом в примитиве J-DISPOSE. Могут присутствовать дополнительное санкционирование и элемент разрешения, чтобы обеспечить выполнение действия в целевой системе проформы. Идентификация элемента

С. 134 ГОСТ Р 34.1083—93

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

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

Нет параметров <спецификация вторичного монитора>. Локальная система управления устанавливает параметр ^спецификация первичного монитора> с параметром <селектор уведомлениях указывающим один или несколько типов событий ABNORMAL-TERMINATION (АВАРИЙНОЕ ЗАВЕРШЕНИЕ)» USERMESSAGE (СООБЩЕНИЕ ПОЛЬЗОВАТЕЛЯ)» NORMAL-TERMINATION (НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ) и MANIPULATION-TERMINATION (ЗАВЕРШЕНИЕ МАНИПУЛИРОВАНИЯ), и с параметром <вводимые данные> по своему выбору. Значение KEEP (СОХРАНИТЬ) не используется в базисном классе.

• 4.3.3. Параметры подзадания модели ВОС <список целевых систем>

Единственный параметр Сцелевая системах параметр Спро-межуточная система> имеет пустое значение.

<срочность>

Только значение MEDIUM (СРЕДНЯЯ). <задержки>

Параметр <задержки> имеет пустое значение.

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

Только значение DOCUMENT-MOVEMENT (ПЕРЕМЕЩЕНИЕ ДОКУМЕНТА) ИЛИ WORK-MANIPULATION (МАНИПУЛИРОВАНИЕ РАБОТОЙ).

• 4.3.4. Параметры действия службы ПОЗ

Ими являются либо параметр Соперации по перемещению документах либо параметр <операции по манипулированию работой >.

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

Имеется единственный параметр <перемещение документах содержащий параметры <тип документа>

Типом такого документа является либо текст (1)» либо вывод на печать (2).

<агентства пи>

Имеется только один параметр <идентификация пи> формата Спи службы JTMX содержащий параметр <имя пи>.

<имя пи>

Значение имени принимающего агентства (тип документа — вывод на печать (2)) или имени исполняющего агентства (текстовый тип документа (1)) в параметре Сцелевая системах Спараметр агентства>

Значением является NULL (НОЛЬ).

Спрефикс пи>

Значением является NULL (НОЛЬ).

«^дополнительное санкционирование>

Нет.

Сблок документа>

Имеется только один параметр <единый формат>, содержащий параметр <писать данные службы JTM>:

<параметр доступа пи>

Установить значение NORMAL (НОРМАЛЬНОЕ).

Ссписок имен>

Установить имя документа.

Один параметр <указатель документа>

Установить значение EMBEDDED (ВЛОЖЕННЫЙ).

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

Имеются два параметра <операция по манипулированию ра-ботой>. Первый является параметром со значением Соперация выбора>. а второй параметр имеет значение операции KILL (УНИЧТОЖИТЬ), STOP (ОСТАНОВ) или DISPLAY (ОТОБРАЖЕНИЕ). Параметр <селектор> имеет значение

ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ и

СИСТЕМА ПРЕДЪЯВЛЕНИЯ ЗАДАНИЯ OSI РАВНО <имя> и

ИМЯ ЗАДАНИЯ МОДЕЛИ OSI РАВНО <строка>

ТИП ПОДЗАДАНИЯ РАВНО <тип подзадания>.

Операция DISPLAY (ОТОБРАЖЕНИЕ) требует значения BRIEF (КОРОТКИЙ). Значением параметра <имя документа> является строка DISPLAY (ОТОБРАЖЕНИЕ). Параметр <имя> указывает такую открытую систему, в которую был введен примитив J-INITIATE-MAN.

• 4.3.5. Проформы

Единственная проформа, если она представлена, содержит <имя проформы>

Установить значение «OUTPUT» (ВЫВОД).

Основная часть проформы с параметрами:

Сданные управления порождением>

Установить значение COMPLETION (ЗАВЕРШЕНИЕ). Спараметры подзадания модели OSI>

Как в п. 4.3.3, но тип подзадания имеет значение DOCUMENTMOVEMENT (ПЕРЕМЕЩЕНИЕ ДОКУМЕНТА).

Спараметры действия службы JTM>

См. ниже.

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

Проформы не появляются в проформах в примитиве J-INITIA-ТЕ базисного класса.

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

Любой.

Система предъявления задания модели ВОС с минимальным согласованием возможна при установке этого поля в значение «вывод на печать» (2) (для примитива J-INITIATE-WORK) и в значение «отображение работы» (4) (для примитива J-INITIATE-WORK-MAN), при этом не требуется обеспечивать установку любого другого значения. Для системы с минимальным согласованием, принимающей спецификации работы, не требуется обеспечение какого-либо значения, отличного от перечисленных выше.

<пи агентство>

Имеется один параметр <идентификация пи> параметра <формат пи службы JTM>:

С имя пи>

Соответствующее имя принимающего агентства в целевой системе проформы.

<параметр агентства>

Этот параметр имеет значение NULL (НОЛЬ). Спрефикс пи>

Этот параметр имеет значение’NULL (НОЛЬ).

Сблок документа>

Этот параметр имеет значение Сединый формат>, содержащий:

С параметр доступ а пи> Установить значение NORMAL (НОРМАЛЬНЫЙ).

Ссписок имен> Единственное имя.

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

Значение равно начальному параметру Сцелевая система>. С идентификация источника >

Это значение PROVIDER (ПОСТАВЩИК) в проформе при манипулировании, в противном случае это значение параметра С исходное агентство службы JTM>;

Симя источника>

ГОСТ Р М.1ЛЭ-» б. W

Значение равно значению начального параметра <имя пи>

< параметр агеитетва>

Этот параметр имеет значение NULL (НОЛЬ).

<указатель источника документа >

Этот параметр имеет значение <читать данные службы JTM>:

<параметр доступа к исходному агентству>

Этот параметр имеет значение MOVE (ПЕРЕМЕЩЕНИЕ). Ссписок имем>

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

Свложенное диагностическое сообщение>

Этот параметр имеет значение EMBED (ВЛОЖЕННЫЙ).

• 4.3.6. Краткое изложение информации, содержащейся в примитиве запроса J-INITIATE базисного класса

• 4.3.6.1. Примитив J-INITIATE-WORK-

В этом примитиве поставщику услуг службы ПОЗ передается следующая информация:

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

б) имя задания модели ВОС;

в) имя целевой системы;

г) имя принимающего или исполняющего агентства в целевой системе;

Д) идентификация пользователя и пароль для использования в целевой системе;

е) текстовый документ (1) или документ на печать (2) для передачи в исполняющее или принимающее агентство (соответственно) и имена этих документов;

ж) имя целевой системы проформы (если используется исполняющее агентство);

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

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

к) имя принимающего агентства в целевой системе проформы для вывода итогового документа на печать (2);

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

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

• 4.3.6.2. Примитив J-INITIATE-WORK-MAN.

В этом примитиве поставщику услуг службы ПОЗ передается следующая информация:

G. 138 ГОСТ P 34.1883—88

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

б) имя задания модели ВОС для манипулирования;

в) имя задания модели ВОС для задания модели ВОС, над которым должно производиться манипулирование, и тип его подзадания;

г) имя целевой системы;

д) идентификация пользователя и пароль для использования в целевой системе;

е) является ли манипулирование запросом на выполнение операции DISPLAY BRIEF (КОРОТКОЕ ОТОБРАЖЕНИЕ), STOP (ОСТАНОВ) или KILL (УНИЧТОЖИТЬ) для задания модели ВОС, над которым должно быть выполнено манипулирование;

ж) имя целевой системы проформы;

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

и) имя принимающего агентства для документа «отображение работы» (4) в целевой системе проформы;

к) имя для документа «отображение работы» (4) при передаче его в принимающее агентство в целевой системе проформы.

• 4.4. Другие группы примитивов в базисном классе

• 4.4.1. Примитив J-DISPOSE

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

Отсутствуют параметры «^дополнительное санкционирование^ Сечет пользователя^*, а параметр Спараметр агентства> имеет значение NULL (НОЛЬ). Параметр Сдиагностическая информа-ция> не содержит никакого • параметра Срезультат службы FTAM>.

Параметр Свводимый документ> является типом либо «отображение работы» (4) (короткое), либо «отображение уведомления» (5), либо «текст» (1) (для исполняющего агентства), либо «вывод на печать» (2) (для принимающего агентства).

• 4.4.2. Примитив J-GIVE

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

Отсутствуют параметры Сдополнительное санкционирование^ Сечет пользователя^*, а параметр Спараметр агентства> имеет значение NULL (НОЛЬ). Параметр Сгруппа документа> явля-. ется значением параметра Сгруппа конца активности>, а параметр Стип документа> имеет значение «вывод на печать» (2).

• 4.4.3. Другие группы

Остальные группы примитивов базисного класса (J-MESSAGE,

J-END-SIGNAL, J-STATUS, J-KILL, J-STOP) содержат полную классификацию параметров, определенных в пп. 3.6.5, 3.6.7, 3.6.8 и 3.6.9.

• 4.5. Краткое описание примитивов и параметров базисного класса

Краткое описание приведено в табл. 4.

Таблица 4

Краткое описание базисного класса службы ПОЗ

ПРИЛОЖЕНИЕ А Обязательное

СОГЛАШЕНИЯ ПО УСЛУГАМ СЛУЖБЫ ПОЗ

А.1. Введение

Стандарт ИСО/ТО 8509 ограничивается в области действия для двухсторонних операций, используемых на уровнях: сетевом, транспортном, сеансовом н на уровне представления. Это приложение моделируется по стандарту ИСО/ТО 8509 с минимальными изменениями в нем и определяет соглашения по услугам, используемым в службе ПОЗ.

А.2. Назначение

Это приложение устанавливает определения терминов и соглашений при определении услуг* обеспечиваемых службой ПОЗ.

А.З. Ссылки

ГОСТ 28904 (ИСО 7498) «Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель».

А.4. Определения

А.4.1. Настоящее приложение разработано на основе ГОСТ 28906, в нем применены следующие термины и их определения:

а) (N) — услуга;

б) (N) — средство;

в) . (N) — уровень.

А.4.2. В настоящем приложении также применены следующие определения:

А.4.2.1. Пользователь услуги (service-ueer) — абстрактное отображение логического объекта в одной системе, которая использует услугу; любой пользователь услуги может инициировать услугу или может ответить на инициирование от поставщика услуг в качестве другого пользователя или пользователей услуг.

А.42.2. Поставщик услуг (service-provider) — абстрактный механизм, который моделирует поведение множества логических объектов, обеспечивающих услугу, с точки зрения пользователя услуги.

А.4.2.3. Услуга уровня (layer-service) — услуга, обеспечиваемая уровнем эталонной модели.

А.4.2.4. Сервисный примитив; примитив (service primitive; primitive) — абстрактный, независимый от реализации элемент взаимодействия между пользователем услуги и поставщиком.

А.4.2.5. Запрос (примитив) (reguest (primitive)) — примитив, введенный пользователем услуги, чтобы вызвать процедуру (для подтверждаемой или неподтверждаемой услуги) с помощью поставщика услуг.

А.4.2.6. Индикация (мримятив) (indication (primitive)) — принятие, введенный постажккком услуг, чтобы вызвать некоторую процедуру (для подтверждаемой или неподтверждаемой услуги) пользователем услуги.

А.4.2.7. Ответ (примитив) (response (primitive)) — примитив, введенный пользователем услуги, чтобы завершить процедуры, связанные с подтверждаемой услугой.

А.4.2.8. Подтверждение (примитив) (confirm (primitive)) — примитив, введенный поставщиком услуг, чтобы завершить процедуры, связанные с подтверждаемой услугой.

А.4.2.9. Пункт доступа к сервисному элементу (service element access point) — концептуальный пункт, в котором имеют место взаимодействия между поставщиком услуг службы ПОЗ и агентством службы ПОЗ.

А.5. Модель службы ПОЗ

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

а) пользователи услуг службы ПОЗ;

б) поставщик услуг службы ПОЗ.

Модель службы

Агентства ■ ......... • • • »..... ■ииип

Черт. 2

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

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

А.в. Сервисные примитивы

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

а) сервисные примитивы являются концептуальными и не относятся непосредственно к элементам протокола и не рассматриваются как обращения макрокоманд метода доступа к услуге;

б) имеются другие эквивалентные наборы сервисных примитивов, которые могут описывать такую услугу;

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

А.6.1. Типы услуг

Различают два типа услуг:

а) неподтверждаемая услуга, включающая в себя:

• 1) либо один примитив запроса (см. п. А.4.2.5) и один или несколько примитивов индикации (см. п. А.4.2.6) в различных пунктах доступа к сервисному элементу;

• 2) либо один или несколько примитивов индикации в различных пунктах доступа к сервисному элементу;

б) подтверждаемая услуга, включающая в себя:

• 1) одни примитив запроса (см. п. А.4.2.5);

• 2) один или несколько примитивов индикации (см. п. А.42.6) н один или несколько примитивов ответа (см. п. А.4.2.2) — оба в различных пунктах^доступа к сервисному элементу из указанного выше перечисления 1);

• 3) один примитив подтверждения (см. А.4.2.8) в том же пункте доступа к сервисному элементу, как представлено в вышеуказанном перечислении 1).

А.6.2. Свойства примитивов

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

Сервисный примитив направляется:

а) либо от пользователя услуги к поставщику услуг;

б) либо от поставщика услуг к пользователю услуги.

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

А.6.3. Имена примитивов

Имя каждого сервисного примитива содержит три элемента:

а) начальное имя (или начальные), указывающее услугу (см. п. А.8.1);

б) общее имя, которое указывает группу примитивов (см. п. А.8.2);

в) специфическое имя, которое указывает тип примитива (см? п. А.8.3).

А.6.4. Группы примитивов

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

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

J-INITIATE группа совершения операций J-DISPOSE группа совершения операций

А.7. Временные диаграммы

Временные диаграммы указывают:

а) последовательность взаимодействий с пользователем услуги;

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

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

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

G. 144 roa Р 34ЛШ-ез

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

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

А.7.1. Примеры неподтверждаемых услуг

Возможны все последовательности, показанные на черт. 3.

Н«ЮЯТМрма|ММЫ« услуги

Запрос

Пользователь 2 Пользователь 3

Черт, 3

А.7.2. Примеры подтверждаемых услуг

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

АЛ Соглашения ори лоимемованми сервисных примитивов

А.8.1. Инициалы

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

F — услуга службы FTAM (ПДУФ);

J — услуги службы JTM (ПОЗ);

V — услуга службы VT (Virtual Terminal — виртуальный терминал);

С — услуга элемента CCR (СПкВ);

А — услуги других прикладных систем;

р — услуга уровня представления;

S — услуга сеансового уровня;

Т — услуга транспортного уровня;

N — услуга сетевого уровня;

DL — услуга звена данных

Ph — услуга физического уровня.

Примечание. Использование инициала N для обозначения услуги сетевого уровня не должно смешиваться с использованием символа (N) для обозначения конкретного, но ■неопределенного уровня модели.

Черт. 4

А.8.2. Общее имя

Одно слово или слово, написанное через дефис (обычно содержащее инфинитивную форму глагола), используется для общего имени, например INITIATE, DISPOSE, END-SIGNAL.

А.8.3. Специфическое имя

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

а) запрос;

б) индикация ;•

в) ответ;

г) подтверждение;

д) группа совершения операций.

С 146 ГОСТ Р $4.1983—93

А.8.4. Представление

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

Инициал и общее имя разделяются дефисом. Общие имена и специфические имена разделяются пробелами.

А.8.5. Примеры

Далее приведены примеры имен параметров, которые используют эти соглашения:

а) J-INITIATE запрос;

б) J-K1LL индикация;

в) J-DISPOSE группа совершения операций.

ПРИЛОЖЕНИЕ Б Обязательное

РЕЕСТРЫ ТИПОВ ДОКУМЕНТОВ

Б.1. Введение

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

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

Б.2. Назначение элемента

Назначение элемента состоит в обеспечении:

а) идентификации типа документа;

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

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

г) определения правил сцепления для типа документа.

Б.З. Идентификация

Тип документа идентифицируется значением OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) нотации АСН. 1 и описателем объекта нотации АСН. 1, назначаемыми в соответствии с правилами ГОСТ 34.973.

Б;4. Семантика документа

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

Типы документов с повышенно определенными семантиками могут формировать специальный «тип» документов с меньшим определением. В этом случае

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

Абстрактный синтаксис типов данных, обеспечивающих передачу семантик типов документов, определяется и называется в соответствии с требованиями ГОСТ 34.971 для названных абстрактных синтаксисов.

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

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

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

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

Синтаксис передачи для типа документа получает имя в соответствии с требованиями ГОСТ 34.971 для поимеиования синтаксисов передачи.

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

Б.6. Отношение синтаксиса и семантик

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

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

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

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

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

С. 148 ГОСТ Р 34Л983-93

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

Б.7. Синтаксические соглашения

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

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

Б.8. Содержимое реестра

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

Б.8.1. Идентификатор типа документа

Данный идентификатор представляет собой значение OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) нотации АСН. 1 и значение OBJECT DESCRIPTOR (ОПИСАТЕЛЬ ОБЪЕКТА) нотации АСН. 1.

Б.8.2. Семантики документов

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

Б.8.3. Синтаксисы документов

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

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

Б.8.4. Имена синтаксисов

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

Б.8.5. Сцепление

Оператор, с помощью которого типы документов могут быть включены в операцию сцепления — «А сцепить с В, чтобы получить С», а также определение операции в каждом случае.

Примечание. Наиболее распространен случай, когда документы А, В и С имеют один и тот же тип.

Б.8.6. Дополнительная информация

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

ПРИЛОЖЕНИЕ В Справочное

КОНСУЛЬТАТИВНЫЙ МАТЕРИАЛ

В. 1. Введение

Работа по передаче заданий и манипулированию заданиями была первоначально предназначена для обеспечения удаленной независимой обработки. Однако такая работа не вписывается в какой-либо способ стандартизованного языка «JCL» и не моделируется ни в какую деталь, которая назначает «обработку».

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

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

Служба JTM имеет дело с так называемыми «заданиями» модели OSI (ВОС). Их не следует путать с традиционными «заданиями», обрабатываемыми в одной машине.

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

Обработка, которая должна быть выполнена, не является объектом интересов службы JTM. Ее забота полностью относится к документам, которые она передает, и должным образом к передаче дальнейших выходных документов. Обработка может быть произведена традиционным способом «выполнение задания» (при котором один из документов, передаваемых службой JTM, должен быть в формате языка «JCL») или некоторым прикладным специфическим процессом, таким как процесс обработки заказов и распределения товаров. Обработка может быть даже полностью ручной при выдаче сообщения человеком службе JTM.-что выходные документы доступны и что работа задания модели OST может быть осуществлена.

В.2. Архитектура

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

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

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

В.2.1. Использование элемента CCR

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

В.2.2. Агентства службы JTM

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

В.2.2.1. Исходные агентства

«Исходное агентство» службы JTM становится доступным с помощью поставщика услуг службы JTM посредством сервисного примитива J-GIVE. Он вводится (как результат запросов в спецификации работы), чтобы запросить поименованный документ из исходного агентства. Исходное агентство обычно моделирует условное локальное файлохранилище, но оно также может моделировать некоторую работающую программу, оператора, которого запросили загрузить магнитную ленту, или обработчика службы FTAM, получающего документ удаленным способом. При этом нет ограничений, накладываемых службой JTM на открытые системы, если примитивы J-G1VE могут быть введены. Открытая система А может ввести примитив J-INITIATE, предназначающийся для обработки некоторых документов в открытой системе В, но примитивы J-GIVE, чтобы получить начальные документы, могут быть введены в открытой системе А, открытой системе В или в полностью стдельных открытых системах С, D, Е,... Протокол службы JTM упорядочивает необходимые запросы и документы, которые должны быть переданы между системами.

В.2.2.2. Принимающее агентство

«Принимающее агентство» службы JTM становится доступным с помощью поставщика услуг службы JTM посредством сервисного примитива J-DISPOSE. Он вводится, чтобы запросить агентство разместить документ, представляемый услугой (обычно полученный с помощью более раннего примитива J-GIVE) Эго размещение может (в зависимости от агентства) быть в .файле, на печатной строке, на графопостроителе, в качестве короткого сообщения в «почтовый ящик» пользователя, в качестве сообщения оператору, сигналом в работающую программу и так далее. Так же, как и для примитива J-GIVE не существует ограничений (объект для санкционирования, приведенный ниже) на то, где именно может выполняться примитив J-DISPOSE.

В.2.2.3. Исполняющее агентство

«Исполняющее агентство службы JTM также становится доступным при помощи сервисного примитива J-DISPOSE. Различие между ним и принимающим агентством состоит в том, что исполняющее агентство имеет возможность формировать новые документы при поступлении (используя примитив J-GIVE) как часть активности, стимулированной примитивом J-DISPOSE. Оно формирует элемент «обработки» внутри модели службы JTM.

В.2.3. Уровень совершения операций

Служба JTM использует так называемый механизм «уровень совершения операций» в примитивах элемента CCR. Элементарное действие, содержащее примитив J-DISPOSE для принимающего или исполняющего агентства, может:

либо завершиться с уровней совершения операций COMPLETION (ЗАВЕРШЕНИЕ); в этом случае все запрошенные активности (обработка документа или печать документа) завершаются до выдачи сообщения о совершении операций;

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

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

В.2.4. Размещение новых документов

Документы, сформированные исполняющим агентством, будут должным образом передаваться в другие принимающие или исполняющие агентства с помощью последующих примитивов J-DISPOSE. Таким образом служба JTM обеспечивает произвольную (неограниченную, потенциально бесконечную) последовательность активностей J-GIVE/J-DISPOSE, J-GIVE/J-DISPOSE (см. черт. 5).

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

В.2.5. Обеспечение неавтономной обработки

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

В 2.6. Последовательность примитивов

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

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

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

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

В.3.2. Ответственность уведомляющей службы

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

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

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

ВЛ. Манипулирование

После введения примитива J-IN1T1ATE возможно продолжение выполнения работы без дальнейшего взаимодействия с человеком. При этом дальнейшее взаимодействие с человеком будет иметь место для того, чтобы:

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

опросить пункты-монитора, которые сохраняют уведомления, как описано в п. В.3.1;

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

Такне взаимодействия также выполняются инициирующим агентством (любым инициирующим агентством). Агентство, кроме того, обеспечивает информацию для спецификации работы, ио требуемой работой теперь является одна из перечисленных выше операций. Кроме того, агентство осуществляет выбор установки «автономной» активности или (более типично для таких случаев) требование уровня совершения операций COMPLETION (ЗАВЕРШЕНИЕ) в примитиве J-INTTIATE.-

В.5. Примитивы J-1NITIATE

Сервисный примитив, предъявляющий обычную спецификацию работы, называется J-INITIATE-WORK- Примитив, запрашивающий отображение или модификацию спецификаций работы, называется J-1NIT1ATE-WORK-MAN. («MAN» означает MANipulation (манипулирование). Примитив, с помощью которого выполняется опрос пунктов мониторов, называется J-INITIATE-REPORT-MAN. Примитив, выполняющий управление передачей, называется J-INITIA-TE-TCR-MAN (<TCR> означает Transfer Control Record» — запись управления передачей) описывается в п. В,11.6.

Во всех случаях использования примитива J-IN1TIATE запрошенная актив’ ность описывается при помощи спецификации работы (какого-либо типа). Все типы спецификации работы содержат ряд глобальных полей, относящихся к санкционированию, идентификации и защите информации. Они формируются из параметров примитива J-INITIATE, обеспечиваемых информацией, поставляемой поставщиком услуг службы JTM. для формирования, так называемых, параметров «параметры задания модели OSI». Эти параметры содержатся в протоколе для всех передач службы JTM, связанных с этой спецификацией работы (включая перемещение уведомления), и служат для координации выполнения всей активности. Эти поля спецификации работы описываются в п. В.9 после представления некоторых концепций.

В.6. Поименевание

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

В.7. Аутентификация

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

В.7.1. Секретная информация

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

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

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

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

В.7.2. Защита с помощью доверенной третьей стороны

Второй механизм защиты заключается в том, чтобы аутентифицировать источник взаимодействия (т. е. объявить имя открытой системы) при появлении, а затем «доверить» известным открытым системам, которые уже были аутентифицированы. Это «доверие» дает возможность получателю принимать операторы от отправителя таким образом, что идентификации пользователя, представленные в соединении, уже были аутентифицированы — что служба JTM называет как «уже проверенный признак». Служба JTM распознает три уровня аутентификации вызывающей системы: эти уровни и природа прикладной системы определяют, должно ли применяться такое «доверие» (аутентификация осуществляется по имени работающих открытых систем, которые участвуют в реализации службы JTM). Этими уровнями являются:

UNKNOWN (НЕИЗВЕСТНАЯ);

KNOWN (ИЗВЕСТНАЯ);

AUTHENTICATED (АУТЕНТИФИЦИРОВАННАЯ).

Открытая система с уровнем UNKNOWN (НЕИЗВЕСТНАЯ) является системой, где при выполнении соединения вызывающему известным является только собственный. оператор вызова. В некоторых случаях (внутри единой монолитной зоны зашиты информации или при низкой защите информации, как, например, требование вывода на печатающее устройство) это может быть достаточным. Открытая система с уровнем «KNOW’N» (ИЗВЕСТНАЯ) является системой, для которой сеть сама обеспечивает адекватный уровень защиты информации для прикладной системы и обеспечивает аутентификационный сетевой адрес, который может быть использован для проверки правильности имени вызываемой открытой системы. Это обычный уровень аутентификации, применяемый в настоящее время к основной массе банковских коммерческих трафиков. Открытая система с уровнем «AUTHENTICATED» (АУТЕНТИФИЦИРОВАННАЯ) является системой, для которой применялись методы криптографического кодирования, чтобы убедиться, что соединение является защищенным от вмешательства для данной открытой системы. Определенные протоколы нижнего уровня, которые должны использоваться для получения этого самого высокого уровня аутентификации, находятся вне области применения службы JTM и только еще ведутся работьь по обеспечению зашиты информации в модели OSI.

В.7.3. Расширение до многосторонней операции

Третий механизм, используемый службой JTM, заключается в основном в том, что он вызывает создание «проверочной трассы». Это-список имен открытых систем, каждая из которых отмечена как AUTHENTICATED (АУТЕНТИФИЦИРОВАННАЯ), KNOWN (ИЗВЕСТНАЯ) или UNKNOWN (НЕИЗВЕСТНАЯ). Если ответственность за выполнение (части) спецификации работы службы JTM передается из одной открытой системы (скажем, А) в другую (скажем, В), открытая система А. добавляет свое имя в конец проверочной трассы с отметкой UNKNOWN (НЕИЗВЕСТНАЯ). При получении проверочной трассы открытая система В может изменить этот признак на AUTHENTICATED (АУТЕНТИФИЦИРОВАННАЯ) или KNOWN (ИЗВЕСТНАЯ). Э-ia проверочная трасса представляет сущность всей зашиты службой JTM информации от «маскарада». Все признаки «уже проверено» в идентификациях. пользователей определяют элемент в проверочной трассе, о котором известно, что проверка уже была выполнена. Обеспечиваемая область опознает и «доверяет» всем именам в этой проверочной трассе, возвращаемой в этот пункт (с допустимым уровнем аутентификации в каждом пункте), затем допускается включение признака «уже проверено» в идентификации пользователя.

При обычной операции ответвленная система может «доверить» главной системе (но нс наоборот). Ответвленная система может проверить (локально) идентификацию пользователя во время выполнения примитива J-fNlTIATE и вставить признаки «уже проверено». Когда несколько позднее главная система передает ответственность за оставшуюся часть спецификации работы обратно для выполнения примитива J-DISPOSE, идентификация пользователя с признаком «уже проверено» доступна для санкции введенной активности (в п. В.20 дана иллюстрация этих механизмов).

В.7.4. Подлинность

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

В.8. Терминология службы JTM

Служба JTM использует термин «задание модели OSI» для полной активности, указанной примитивом запроса J-INITIATE.

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

Открытая система, в которой для определенного задания модели OS1 появляется примитив J-INITIATE, называется «система предъявления задания модели OSI».

Термин «манипулирование» охватывает как «модификацию спецификации работы» (или удаление уведомлений), так и «отображение» спецификации работы или уведомлений.

Семантика работы, которая должна выполняться службой JTM (включая порождение новой работы из проформы), называется «спецификацией работы». Выполнение обшей работы называется заданием модели OSI, разбиваемым на подзадания модели OS1. Блок PDU (Protokol Data Unit-протокольный блок данных) службы JTM, содержащий детали спецификации работы или части ее (для того, чтобы передать ответственность за нее другой открытой системе), называется элементом передачи.

В.9. Параметры задания модели OSI

Так называемые «параметры задания модели OSI» описываются в следующих параграфах.

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

Параметр «дата и время предъявления» представляет собой время введения примитива запроса J-INITIATE и обеспечивается поставщиком услуг службы JTM.

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

Параметр «проверочная трасса» был описан, в п. В.7.3, он формирует базис механизма защиты информации службы JTM.

Параметр «монитор задания модели OSI» содержит спецификацию так называемого «первичного монитора», обеспечиваемую поставщиком услуг службы JTM в инициированной открытой системе. (Изменение такой спецификации позднее требует большего санкционирования, чем изменения в так называемых «вторичных мониторах»). Агентством при введении примитива J-INITIATE либо не обеспечивается, либо обеспечиваются одна или несколько спецификаций вторичных мониторов. Каждая спецификация монитора дает категории уведомляющих служб, которые требуются, и параметр «имя открытой системы» (пункт монитора), в которую должны быть посланы уведомления о каких-либо результатах работы. Спецификация также указывает, должны ли быть сохранены уведомления пунктом монитора (см. п. В.3.1) или, кроме этого, предоставляет детали принимающего агентства, в которое должен быть введен примитив J-DISPOSE.

Поле «параметры защиты» обеспечиваются при введении примитива J-INITIATE и используются для определения уровня защиты информации, требуемой при соединениях службы JTM относительно этой спецификации работы. Значения этих параметров в настоящее время не определены, так как ожидается завершение работы по «Защите модели OSI» и описание значений соответствующего параметра либо в описании услуг уровня представления, либо через описание элемента CASE (Common Application Service Element-общий элемент услуги прикладного уровня). Возможными значениями являются:

защита информации не требуется;

требуется служба обнаружения несанкционированного вмешательства; требуется защита службы от разрушения.

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

Поле «список санкционирования», содержит набор идентификаций пользователя (или идентификаций системы управления — другая концепция службы JTM- см. n. В.10), которые могут. потребоваться для санкционирования активности. Каждый элемент в таком -списке также содержит поле «поле доступа» для аутентификации идентификации. При введении примитива J-INITIATE это поле может содержать только пароль, но поставщиком услуг во время инициирования могут быть добавлены элементы с признаком «уже проверено», а также когда проверяется пароль. Служба JTM также допускает, что дополнительные элементы санкционирования должны обеспечиваться при введении примитива J-INITIATE, если в спецификации работы формируются указатели для документов, которые должны быть получены от исходных агентств или которые должны посылаться к принимающим агентствам.

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

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

В. 10. Идентификация управляющей системы

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

ВЛ!. Активность службы JTM (подзадания)

Теперь может быть описана активность, которая может потребоваться в спецификации работы. Она состоит нз древовидной структуры активности, называемой «подзаданиями» Древовидная структура активности может быть выполнена как единая древовидная структура элементарного действия элемента CCR или можс1 быть выполнена с каждым ползаданием, формирующим отдельное элементарное действие (в зависимости от требуемого уровня совершения операций).

ВИЛ. Подзадания по перемещению документов

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

ВЛ 1.1.1. Перемещение указанных поименованных документов

Первая возможность включает инициирующее агентство, чтобы: указать одну открытую систему (называемую «целевая система»), которая должна вводить одни или несколько примитивов J-DISPOSE в принимающее или исполняющее агентство;-

указать агентства (со всеми необходимыми параметрами идентификации, санкционирования и учета) для каждого примитива J-DISPOSE; (агентство может выполнить локальное действие или может иснользовать службу FTAM для удаленного действия);

указать (как определено ниже) документы, которые должны быть посланы каждому агентству с примитивом J-DISPOSE, и имена тех документов в принимающем агентстве.

Один и тот же документ может быть послан в нескольких примитивах J-DISPOSE (средства дублирования службы JTM).

Каждый документ указывается как множество частей документа (средство сцепления службы JTM). Каждая часть документа или обеспечивается с примитивом J-INITIATE или идентифицируется с помощью:

указания для каждой части документа открытой системы (открытая система выполнения действия), которая должна собрать часть документа, вводя примитив J-GIVE в те агентства, которые могут допустить этот примитив (локально или с помощью службы FTAM);

указания агентства (со всеми необходимыми параметрами идентификации, санкционирования и учета) для примитива J-G1VE;

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

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

Элемент протокола службы JTM (содержащий семантику спецификации работы) лучше моделируется как «выделенная часть». Документы дробятся на «выделенные части» (получаемые примитивом J-GIVE), которые перемещаются (возможно через промежуточные системы) по направлению к целевой системе. В целевой системе документы для этого подзадания удаляются и посылаются из нее, используя примитив J-DISPOSE. (Некоторые документы, необходимые для более поздних подзаданий, могут сохраняться).

B.1L1.2. Перемещение групп, документов

Вторая возможность включает инициирующее агентство, чтобы:

указать, что целевая система должна вводить примитив J-DISPOSE (к единственному агентству) для каждой группы документов;

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

Эта форма подзадания особенно полезна или для перемещения всех файлов, указанных в одном и том же подсправочнике, или для сбора всей выводимой информации из задания, когда не известны точные имена файлов/документов. Поставщик услуг службы JTM узнает имена текущих документов, используя примитив J-ENQUIRE для исходного агентства. Затем, чтобы получить документы, следует серия примитивов J-GIVE. Часть имени документа в исходном агентстве используется при формировании имени документа для принимающего агентства.

В. 11.2. Завершение подзадания и порождение проформы

Подзадание готово для завершения, когда все примитивы J-DISPOSE, определенные в этом подзадании, указали готовность или с помощью сообщения о совершении операций с уровнем совершения операций COMPLETION (ЗА-

ВЕРШЕНИЕ), или с помощью более позднего примитива запроса J-END-SIG-NAL из принимающего или исполняющего агентства. В этот момент одно или несколько новых подзаданий начинается поставщиком услуг службы JTM. Эти подзадания формируются или как часть элементарного действия примитива J-DISPOSE, то есть, как элементарное действие более раннего подзадания, или как часть элементарного действия примитива J-END-SIGNAL, то есть новое элементарное действие. Эти новые подзадання были определены в начальной спецификации работы, созданной примитивом J-INITIATE. Это делается с помощью подпараметров в -примитиве J-INIT1ATE, которые имеют название «проформа». Каждая проформа содержит параметр «имя проформы» и дальнейшую спецификацию подзадания перемещения документа, как описано выше.

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

Когда начинается работа в определенном проформой подзадании, проформа предлагает «породить» подзадание. Каждая проформа порождает в конце выполнения подзадания новую активность, которая продолжается независимо (и обычно параллельно) от активности, порожденной другими проформами. Не предпринимается действие для получения документов, указанных внутренними проформамй, до тех пор, пока они не породят подзаданне. При этом «выделенная часть» службы JTM может содержать такие документы, если они были обеспечены примитивом J-INITIATE.

Обсуждение до сих пор концентрировалось на том, что называется «порождение конца активности». Кроме того, возможно', что исполняющее агентство «до завершения своей работы» может ввести примитив J-SPAWN,' чтобы породить из поименованной проформы для распределения некоторых \ документов, которые уже являются доступными. Такое действие называется «порождение запроса». Третье дополнительное действие называется «порождение принятия», предпринимаемое поставщиком услуг службы JTM, когда все примитивы J-DISPOSE предоставили агентству уровень совершения операций ACCEPTANCE (ПРИНЯТИЕ) (или более высокий).

В. 11.3. Обеспечение ДЛя непрерывной активности

Имеются два дополнительных средства, которые обеспечивают бесконечную (рекурсивную) последовательность выполнения активности службы JTM. Первое средство представляет собой механизм, посредством которого проформа, когда она порождает подзадание, может определить, что полная копня родительской проформы (или одной из ее «родственных») должна формировать проформу в новом подзадании. Это называется «наследование». Вторым средством является, так называемый, «список задержки».

Список задержки для каждого подзадания может присутствовать в проформе во время введения примитива J-INITIATE, или, в более общем случае, может производиться манипулированием или поставщиком услуг при возникновении ошибок. Список задержки либо не содержит, либо содержит один или несколько элементов «элемент задержки». Наличие элемента задержки вызывает задержку выполнения подзадания поставщиком услуг службы JTM (когда ответственность за него достигает названную открытую систему). Элемент задержки содержит:

необязательный элемент разрешения для его освобождения при помощи манипулирования;

местоположение, где должна быть применена задержка (обычно или в области, где произведено порождение, блокируя примитивы J-GIVE и передачи, или область целевой системы, блокирующая примитивы J-DISPOSE);

необязательную читабельную причину для задержки;

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

В.И.4. Подзадання манипулирования работой

Примитив J-INITIATE-WORK-MAN указывает начальное лодзадание для манипулирования (отображения или модификации) другими спецификациями работы. Эта спецификация работы манипулирования направляется в указанную целевую открытую систему и содержит последовательность операций, которые должны бысть 'Выполнены поставщиком услуг службы JTM в той открытой системе.

Этими операциями являются:

SELECT (ВЫБРАТЬ) — либо не выбирать ни одну, либо выбрать одну или несколько спецификаций работы, за которые та открытая система является'ответственной; выбор определяется общим логическим выражением, включая тесты почти на любое поле в спецификации работы;

KILL (УНИЧТОЖИТЬ); выбранные спецификации работы удаляются; любая соответствующая активность в принимающих или исполняющих агентствах завершается при помощи примитива J-KILL, а спецификация работы сбрасы¹-вается;

STOP (ОСТАНОВ); выбранные спецификации работы не выполняются, но любые соответствующие принимающие и исполняющие агентства посылают сигнал J-STOP; предполагается, что агентства должны «немедленно» завершить свою работу (возможно обеспечивая вывод информации); детали зависят от реализации;

MODIFY (МОДИФИЦИРОВАТЬ); указанные поля в выбранной спецификации работы изменяются или дополняются; количество полей, которые могут быть модифицированы, является более ограниченным, чем количество полей, доступных для выбора;

DISPLAY (ОТОБРАЗИТЬ); выбранные спецификации работы должны быть отображены при создании форматированного определенного службой JTM документа; документ «собирается» поставщиком услуг службы JTM включением одной или нескольких проформ (обычный тип перемещения документа) в спецификацию работы манипулирования.

В.11.5. Спецификация работы по манипулированию уведомлением

Спецификация работы, формируемая по примитиву J-INITIATE-REPORT-MAN, указывает целевую систему, которая является пунктом монитора, и запрашивает или отображение (в документе, собранном проформами) или удаление уведомлений, которые были собраны. Кроме того, к активности применяются механизмы санкционирования. (Черт. 6 показывает некоторые аспекты активности службы JTM).

В.11.6. Спецификации работы по манипулированию управлением передачей

Спецификация работы, формируемая по примитиву J-INITIATE-TCR-MAN, обеспечивает управление (субъекта к санкционированию) со стороны любой открытой системы так называемыми записями управления передачей, задержанными какой-либо другой открытой системой.

В. 11.6.1. Модель записи TCR

Модель службы JTM, в основе которой лежит управление передачей, приведена в последующих параграфах.

Активность службы JTM

1 - система предъявления задании модели OSI; 2 - спецификация работы- уведомление; 3 - системы монитора задания OS1;

4 — спецификация работы; 5 — спецификация работы- манипулирование монитора; 6 — спецификация работы, ответ; 7 — системы обработки подзадания; 8 — спецификация роботы: манипулирование; 9 — системы предъявления манипулирования

Черт. 6

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

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

попросить открытую систему А не пытаться делать что-либо, что может запросить определенное устройство в открытой системе В, так как оно неисправно;

попросить открытую систему А не пытаться выполнить более (скажем) трех одновременных передач открытой системе В до тех пор, пока одна из них имеет высокий приоритет (другой параметр примитива J-I NITI АТЕ), или является передачей уведомления или манипулированием.

Эти требования поддерживаются наличием в системе А концептуальной структуры данных, называемой записью управления передачей (TCR-Transfer Control Record), управляющей передачами к открытой системе В. Если эта запись TCR не устанавливается, действия открытой системы А не ограничиваются и зависят от реализации. Если эта запись устанавливается, то запись либо не содержит, либо содержит один или несколько селекторов. Эти селекторы точно такие же, которые использовались в операции SELECT (ВЫБРАТЬ) манипулирования работой, чтобы выбрать одну или несколько спецификаций работы, используя многообразие полей в них. (Также обеспечивается выбор, использующий время ожидания, и объем передаваемой информации).

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

В.11.6.2. Операции записи TCR

Спецификация работы, формируемая по предъявлению примитива J-INITI-ATE-TCR-MAN, указывает целевую систему и запись управления передачей к той системе, которой нужно выполнить манипулирование. Запись может быть помещена (операция «SET (УСТАНОВИТЬ)»), или отображена (операция «DISPLAY (ОТОБРАЗИТЬ)») в документе при сборке его проформой.

Третья доступная операция называется «CHECK (ПРОВЕРИТЬ)». Она может быть использована, в представленном выше примере системой А, в качестве запроса системе В после аварии системы А. Операция содержит запись TCR, которую система Л в настоящий момент собирается использовать для управления передачами к системе В, а по существу говорит «Я пока вне полномочий — если она» не больше соответствующей записи, вы лучше измените ее». (Это является видом повторной синхронизации очень высокого уровня).

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

Примером третьей стороны, устанавливающей запись управления передачей, является система, в которой центр административного управления системы Л помещает записи управления передачей в спул главной системы В (действуя, как промежуточная система службы JTM) для управления передачами к простому устройству управления печатью системы С. Запись TCR содержит поле «УСТАНОВИТЬ СИСТЕМОЙ» с именем системы «А» и, следовательно, любая последующая операция манипулирования «CHECK (ПРОВЕРИТЬ)» посылается из системы В в систему А, несмотря на тот факт, что это является передачами к устройству системы С, которое должно быть управляемым (см. черт. 7).

В этом примере центр административного управления системы А будет обеспечивать службу JTM базисного класса, расширенную, по меньшей мере, добавлением до функции операций манипулирования записью TCR: спул главной системы «В» будет обеспечиваться службой JTM базисного класса, расширенной, по меньшей мере, добавлением до функции записи TCR; устройство управления печатью системы С будет обеспечиваться только службой JTM базисного класса.

В. 11.6.3. Обратные передачи

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

С. 164 ГОСТ Р 34.1983—93

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

Пример манипулирования записями TCR третий стороной

Черт. 7

В.11.7. Иллюстрация

Черт. 8 иЛлюстрнрует простое использование службы JTM, эквивалентной нестандартной операции службы RJE (Remote Job Entry — удаленный ввод заданий) (небольшое подмножество возможности службы JTM).

В.12. Действия при ошибках

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

Первое действие применяется только к ошибкам, являющимся результатом попытки выполнить примитив J-GIVE (например «файл не существует», «неудовлетворительное санкционирование» и так далее). Если запрашивается такое действие, диагностическое сообщение элемента CCR из примитива J-GIVE вкладывается в спецификацию работы вместо документа и со временем будет

Иллюстрация использования слум-б'! J ГМ для традиционной

активности эвммня

/ — инициирующее агентство; 2 — операторы языка JCL+данные; 3 — предъявление; 4 — создание спецификации работы: 5 — очередь сиецнфнкаомй работы (на передачу); 6— передача спецификаций работы; 7 —• очередь спецификаций работы (на выполнение)! 8 — освободить; 9 — задержать; 10 — очередь задержанных соедвфихацнй работы; 11 — об* работка спецификации работы; 12 манипулирование спецнфмкацней работы ■ оврос; /3 — проформы; 14 — исполняющее агентство; IS — выходные данные; 16 — пурпур»нового подэадання; 17 — очередь спецификаций работы (на вывод); 18 — размещение документа;

19 ■— «ринвмеюшее агентство передано в принимающее и исполняющее агентство в примитиве J-DISPOSE. Основное элементарное действие, выдавшее примитив J-GIVE, продолжается нормально с примитивом C-READY, но включается предупреждающее уведомление элемента CCR. Уведомление службы JTM также может быть произведено, если была запрошена эта категория уведомляющей службы.

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

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

В. 13. Документы

Стандарты службы JTM главным образом относятся к перемещению документов. Термин «документ» вообще может широко определяться как содержимое файла или части файла — структурированная информация, отличающаяся какими-либо концепциями поименования, структурой доступа или другими атрибутами, относящимися к доступу.

Служба JTM распознает три типа документов (структурированная информация), которые полностью определяются службой JTM (семантика и синтаксис передачи). Это — отображения уведомлений службы JTM, отображения работы службы JTM. и отображения записи TCR службы JTM.

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

Наконец, служба JTM может запросить и содержать любые документы, которые:

имеют реестровое имя (тип документа);

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

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

Другим важным свойством службы JTM является распознавание реализации «обеспечение хранения». Реализация службы JTM предоставляет реализацию «обеспечение хранения» для типа документа, если примитив J-GIVE, следующий за примитивом J-DISPOSE для любого специфического документа этого типа, имеет результатом идентичное значение, которое должно быть возвращено. В общем, реализации, не содержащие возможность обеспечения хранения, например для документов типа BINARY (ДВОИЧНЫЙ), могут излишне расширять битовую строку до размера, кратного восьми битам.

ВЛ4. Промежуточные системы службы JTM

В общем случае подзадание начинается при введении примитива J-INITIA-ТЕ или при порождении, и ответственность за соответствующую спецификацию работы передается непосредственно из области инициирующего или порождающего агентства в область целевой системы с помощью протокола службы JTM. Эта простая ситуация неадекватна в следующих четырех случаях: обе системы непостоянно подключаются к сетям и никогда не подключены одновременно;

обе системы работают в очень различных временных зонах и никогда не работают одновременно;

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

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

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

Черт. 9 нллюст^фует обработку подзадания при передаче его к своей целевой системе через единственную промежуточную систему. Документы собираются с помощью примитива J-G1VE во всех трех системах.

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

В. 15. Протоколы доступа к агентству

В начальных стандартах службы JTM система «открытая система выполнения действия» получает документы при помощи использования сервисного примитива J-GIVE (который может вызвать использование службы FTAM). Целевая открытая система размещает документы с помощью использования примитива J-DISPOSE (который может вызвать использование службы FTAM).

В стадии изучения находятся вопросы обеспечения очень простого протокола для поддержания связи между удаленным агентством и поставщиком услуг службы JTM (отображая соответствующие сервисные примитивы службы JTM). Такое расширение службы JTM будет включать простые «периферийные дисковые устройства» для работы (используя стандартные протоколы) через локальную сеть к «замкнутой системе» без периферии, но действующие как поставщик услуг службы JTM. Они также будут обеспечивать примитивы J-ENQU-IRE, J-HOLD, J-END-SIGNAL .и так далее, которые не обеспечиваются службой FTAM..

ВЛ 6. Временные соотношения в сервисных примитивах

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

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

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

межта €СЯ> или подразумевается необходимость поставщика услуг данные (в жрямитнве ответ* J-4HVE) до их доставки (в примитиве J-DJSPO6E).

Обработка подзадания в промежуточных системах службы JTM

и документ п.

/ _ система предъявления задания модели OSI; 7 — иии» цннруюшее атекгетио; 3 - ксвжвое жеетство; 4 _т адиои» запроса J-IN1TIATE; 5 -

ТЕ- а — примитив индикации J-OTVE; 7 — примитив ответа J43IVE; 9 ~ поставим»* услуг службы JTM; 9 — ирвмежуточ-мая система; 10 — целевая ометема; // — нринммамва агеат-ство; 12 — примитив индикации J-DISPOSE; 13 — примитив ответа J-DJSPOSE; /< — спецификация работы Черт. 9

Обработка под задания с поздним соединением

/ — система предъявления задания; 2 — инициирующее агентство; 3 — примитив за-пплгя J-1N1TIATE’ 4 — примитив подтверждения J-INIT1ATE; 5 — поставщик услуг служим ттм- 6 — виртуальное файлохранилище службы FTAM; 7 — промежуточная система; S - операция чтения службы РТАМ: 9 -целевая система: 10 - обработчик службы FTA VI в качестве исходного агентства службы JTM; П ~ примитивы индикации J-GIVE; 12 — примитивы ответов J-GIVE; 13 — (локальное) исходное агентство; 14 — (локальное) нпннммаюшее агентство; 1S — примитив индикации J DISPOSE; 16 — примитив ответа J^PDISPOs“ 17 -спецификация работы; 18 - примитив индикации J-GIVE; 19 - прими-’ тив ответа J-GIVE

С. 170 ГОСТ Р млеет—93

Обработка подзадания с оанням соединением

/ — системе предъявления задания модели OS1; 2 ~ инициирующее агентство: 3 — примитив запроса J-INITIATE: 4 — примитив подтверждения J-INIT1ATE; 5 — поставщик услуг службы JTM: б — (локальное! исходное агентство: 7 — примитив индикации .I-GIVE; 8 — примитив ответа J-GIVE; 9 — спецификация работы: 10 — обработчик службы FTAM в качестве исходного агентства службы JTM: 11 — примитив индикации J-G1VE; 12 — примитивы ответов J-GIVE: 13 — операция чтения службы FTAM: 14 —• промежуточная система: 15 — виртуальное файлохранилище службы FTAM: 16 — целевая система; 17 — (локальное) принимающее агентство; 18 — примитив индикации J-DISPQSE;

19 — примитив ответа J-DISPOSE

Пример потока обработки для уровня совершения операций COMPLETION (ЗАВЕРШЕНИЕ)

1 — система I; 2 — система предъявления задания модели OS1; 3 — примитив запроса J-1NIT1ATE-WORK; 4 — примитив подтверждения J-INITIATE-WORK; 5 — инициирующее агентство: 6 — поставщик услуг службы JTM; 7 — спецификация работы; 8 — система 2; 9 — примитив индикации J-O1VE; 10 — примитив ответа J-GIVE; 11 — исходное агентство; 12 — система 3; 13 — исполняющее агентство; 14 — примитив индикации J-DISPOSE; 15 — примитив ответа J DISPOSE; 16 — порождение; 17 — система 4; 18 — принимающее

агентство

Пример лоспедоогвльмости примитивов ллл уровня совершения оперший COMPLETION (ЗАВЕРШЕНИЕ)

зап - запрос, жд - индикация.

отв - ответ.

подт -подтверяшение*

Подэаданне службы JTM может включать (например) группы примитивов J-INITIATE, J-DlSPdSE н две группы примитивов J-GIVE в четырех различных пунктах доступа к услуге.

Даже в случае совершения операций с уровнем COMPLETION (ЗАВЕРШЕНИЕ) возможны значительные расхождения во временной последовательности элементов групп примитивов в различных пунктах доступа к услуге. Черт. 13 иллюстрирует возможные последовательности примитивов с помощью диаграммы временной последовательности (см. приложение А) для потока обработки, показанного на черт. 12.

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

Более интересное взаимодействие по временной последовательности имеет место, когда принимающее агентство предоставляет документ, и более или менее одновременно нсяолмяющее агентство тоже предоставляет документ для обработки, которая вызывает то, что исполняющее агентство (не видимое для .модели OSI) принимает документ, вводимый принимающим агентством для размещения. Отметим, чтр на этой стадии поставщик услуг не может принимать другие группы примитивов J-DISPOSE. Правила для параллельного выполнения действий элемента CCR требуют, чтобы документ, передаваемый принимающему агентству, был доступен исполняющему агентству, где он обрабатывался как часть того же самого элементарного действия. Этот случай может быть важным, если один документ (скажем, дайные) посылается в распространенное файлохранилище, а другой в это время (операторы языка JCL) передается к разделителю задания.

ВЛ7. Подмножества.■ соответствие

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

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

Спецификация работы базисного класса и соответствующий элемент протокола являются определенным подмножеством общего случая. Расширенная реализация и реализация базисного класса будут взаимодействовать в том случае, если только примитив J-INITIATE гарантирует, что достаточно ограниченные подзадания передаются в реализацию базисного класса (см. п. B.I&).

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

Вторая форма подмножества содержится в природе поддержания агентства, обеспечиваемого реализацией. Определенная реализация может обеспечиваться для работы только в качестве кнмцияруюшего агентства. Это называется «обеспечение для предъявления задания модели OSI службы JTM». Другая реализация может обеспечиваться для работы только определенного устройства в качестве пункта монитора службы JTM. Следующая реализация может обеспечивать использование одного (но, возможно, не всех) из своих печатающих устройств в качестве принимающего агентства службы JTM. Некоторая реализация может обеспечивать все сервисные примитивы службы JTM. при помощи вызовов подпрограмм из программы пользователя на языке FORTRAN (но возможно не из программ на языке COBOL). Это будет называться «обеспечение службы JTM на языке хуг». Последний пример является примером обеспечения возможности человека принять сообщение о документах для обработки и сигнализировать о завершении обработки — «Обеспечение службы JTM для обработки человеком».

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

В.18. Взаимодействие реализаций базисного класса и расширенных реализаций

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

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

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

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

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

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

В.19. Протокол службы JTM

Спецификация протокола службы JTM состоит из следующих трех основных частей:

определение абстрактного синтаксиса передачи (использующий нотацию АСН. 1) структуры данных, используемой для передачи спецификации работы, при которой получатель информации вместе с проформами н документами в на,-стоящий момент находится в «выделенной части»;

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

Оазисного классе

Элемент передачи выходит за пределы базисного класса

А — спецификаций подзадання базисного класса с единственной проформой: В — спецификация подзадання со списком проформ; С — может указывать подзадания базисного класса или может иметь рас* ширенную функциональность Черт, 14

Таблица В.1

Комбинации функциональности базисного класса и расширенной функциональности

Базисный элемент передачи может быть обработан получателем информации базисного класса.

Расширенный элемент передачи требует, чтобы принимающая система имела расширенную функциональность __________________________________

С. 176 ГОСТ Р 34.1933-93

детальные процедурные операторы по действиям» которые должны быть приняты реализацией службы JTM, когда вводится примитив запроса J-INITIATE, или при приеме вышеописанной структуры данных; эти действия включают в себя введение (как Часть элементарного действия элемента CCR) примитива J-GIVE и (или) примитива J-DISPOSE, порождение, формирование уведомлений и так далее;

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

В базисном классе последняя спецификация включает введение единственного примитива P-DATA в элементах CCR элемента СДБЕ (в зависимости от элемента CASE). Каждый документ представляет собой значение отдельных данных в единственном примитиве P-DATA. Использование основной части средств передачи (включающее общее средство контрольной точки) вместо элементарного примитива P-DATA является частью расширенной функциональности, которая указывается в спецификации радЩиремноГо Цротокола. Начальные стандарты службы JTM требуют, чтобы отправители и Получатели информации обеспечивали передачу с помощью непосредственного или элементарного использования примитива P-DA.TA.

В.20. Примеры механизма санкционирования

Обсудим следующий пример. Пользователь В области А предъявляет спецификацию работы, сосдержашую одну проформу, чтобы выполнить задание в области В и возвратить выходные данные в область А. Пользователь имеет следующие имена пользователей, распределенных ему: в области А — имя пользователя USERA, пароль PASSA; в области В — имя пользователя USERB, пароль PASSB. Имеются четыре случая, которые должны быть обсуждены в отношении того, какая область какой доверяет. Могут быть следующие варианты:

СЛУЧАЙ А: область А доверяет области ^!В, а область В доверяет области А;

СЛУЧАЙ В: область А доверяет области В, а область В не доверяет области А;

СЛУЧАЙ С: область А не доверяет области В, а область В доверяет области А;

СЛУЧАЙ D: о&ласть А не доверяет области В, а область В не доверяет области А.

В.20.1. Определение д о*в ер ия

Если спецификация работы появляется в области В, проверочная трдоса будет ’Иметь единственный элемент, а именно элемент области А; Значением состояния будет «UNKNOWN (НЕИЗВЕСТНЫЙ)»; область В использует знание имеющихся сетей и* (или) техники кодирования, чтобы (возможно) перевести это полученное значение в значение «KNOWN (ИЗВЕСТНЫЙ) илн AUTHENTICATED (А^ЕНТИФИЦИРОВАННЫЙ)». Область В имеет список областей, которым она будет «доверять, если, принято значение AUTHENTICATED (АУТЕНТИФИЦИРОВАННЫЙ)», или «доверять, если принято значение -KNOWN (ИЗВЕСТНЫЙ^, или «доверять, даже если принято значение UNKNOWN (НЕИЗВЕСТНЫЙ)». Это зависит от того, доверяет ли область В области А. Списки формируются (человеком) административной управляющей системой.

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

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

В.20.2. Необходимые списки санкционирования

В.20.2.1. Случай А (обе области доверяют друг другу)

Если пользователь обеспечивает санкционирование для задачи службы JTM, он ке обеспечивает никакого оароля, Элементы санкционирования с ^проверенными индексами» I добавляются поставщиком услуг службы JTM и для своих локальных и для своих удаленных имен пользователей (имя USERA и имя USERB), если спецификация работы предъявляется, предоставляя список санкционирования:

Область A USERA 1

Область В USERB 1

Если спецификация работы появляется в области В, с этих пор область В доверяет (только) области в проверочной трассе, к которой будет допущен элемент санкционирования

Область В USERB 1

как обеспечивающий санкционирование доступа для самой себя; например, область В доверяет области А допустить пользователя, который присутствует с именем пользователя USERB.

Если (порожденная) спецификация работы, содержащая выходную информацию, появляется в области А, то область А доверяет обеим областям в проверочной трассе и поэтому знае*т, что пользователь с именем USERA был предварительно проверен eio самой ранее во время выполнения задачи службы JTM (после этого можно полагать; что «проверенный индекс» I должен быть правильным). Поэтому она имеет достаточное санкционирование на размещение выходной информации.

В этом примере проверочный индекс принимает только значение 1, так как проверка всех паролей была проведена в системе^предъявления задания модели OSI.

В.20.2.2. Случай В (область В не доверчет области А)

Если спецификация работы появляется в области В, с этих пор область В не доверяет области А, и она будет требовать следующий элемент санкционирования

Область В USERB PASSB

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

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

Область A USERA 1

как u c.'iyiac А, прсдстполс1тым выше.

С. 178 ГОСТ Р 34.1983—93

В.20.2.3. Случай С (область А не доверяет области В)

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

Область A USERA PASSA

Область В USERB 1

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

В.20.2.4. Случай D (ни одна область не доверяет другой)

Пользователь предоставляет имена пользователей и пароли для обеих областей А и В, с этих пор ни одна область не доверяет «маскарадуэ другой области.

В.20.3. Общие пункты

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

В.20.4. Иллюстрация

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

Таблица В.2

Значение списка санкционирования и проверочная трасса в примере

ПРИЛОЖЕНИЕ Г

Справочное

термины

F.l. Account identification (идентификация счета) — данные, которые могут использоваться в соответствующем контексте, Фгобы идентифицировать счет, который должен быть занесен в дебет с какими-либо расходами, за которые взимается плата.

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

Г.2. Activity (in an agency) (активность в атентстве) — работа, выполняемая каким-либо агентством, инициируемым сервисным примитивом, введенным в это агентство поставщиком услуг службы JTM; завершение этой активности указывается сервисным примитивом, введенным этим агентством поставщику услуг службы JTM.

Г.З. Agency (агентство) — абстрактное описание таких функций среды локальной системы, которые необходимы для обеспечения услуги службы JTM.

Г.4. Authenticated identification (аутентифицируемая идентификация) — данные, которые известны, чтобы правильно мдейтифицнровать пользователя или систему управления, по запросам которых должна выполняться работа либо с помощью использования проверки пароля, либо с помощью использования механизма проверки.

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

Г.6. Execution agency (исполняющее агентство) — любая часть открытой системы, которая первоначально действует как принимающее агентство для документов, но которая впоследствии действует как исходное агентство для соответствующих документов, сформированных в результате обработки более ранних документов.

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

Г.8. Identification authority management identification (идентификация системы управления идентификационными санкциями) — имя идентификационной санкции, которая, если она аутентифицирована, санкционирует активности службы JTM, имеющие отношение к управлению активностью, инициируемой идентификациями пользователя, вводимыми при помощи такой санкции.

Г.9. Initial work specification (начальная спецификация работы) — спецификация работы, созданная инициирующим агентством в результате введения сервисного примитива инициирования.

Г. 10. Initiating identification (идентификация инициирования) — идентификация, обеспечиваемая поставщиком услуг службы JTM во время предъявления задания, чтобы идентифицировать инициатора задания модели OS1.

Г.1Initiation agency (инициирующее агентство) — такое агентство, которое вызывает создание спецификации работы.

Г. 1'21 JTM report (‘уведомление службы JTM) — закодированная информация, регистрирующая обработку или отказ задания модели O&I, сформированная поставщиком услуг службы JTM, возможно как результат взаимодействия с агентством.

Г. 13. Level of commitment (уровень совершения операций) — параметр, который определяет, должны ли- завершаться операции, затребованные в элементарном действии, во время выполнения элементарного действия, либо операции должны-отмечаться (как сохраняемые данные) для более позднего выполнения.

Г. 14. No-retry diagnostic (диагностическое сообщение «Не повторять») — информация, передаваемая услугой элемента CCR при отказе совершения операции, когда действие не может быть завершено, а позже повторная попытка не предполагается.

Г. 15. Open system management identification (идентификация системы управления открытыми системами) — имя открытой системы, которая, если она аутентифицирована, санкционирует активности службы JTM или расходы, отнесенные к системе управления этой открытой системы.

Г. 16. OSI job (задание модели 051) общая работа во всех открытых системах, являющаяся непосредственно или косвенно результатом обработки начальной спецификации работы.

Г.17. OSI job local reference (локальный указатель задания модели OSI) — указатель для задания модели 051, который является уникальным внутри системы предъявления задания модели OSI, назначаемый этой открытой системой.

TJB. OSI job monitors (мониторы задания модели OSI) — открытые системы, в которые посылаются уведомления службы JTM об определенном задании модели OSI.

Г.19. OST job name (имя задания модели OST) — последовательность знаков, предоставляемая инициирующим агентством во время предъявления задания модели 0S1.

Т.20. OSI job submission (предъявление задания модели OSI) — использование сервисного примитива инициирования инициирующим агентством для создания начальной спецификации работы.

Г.21. OSI job submission system (система предъявления задания модели OSI) — открытая система, в которой имеет место предъявление задания модели OSI.

Г.22. OST subjob (subjob) (подзадаиие модели OSI (подзаданне)) — общая работа, являющаяся результатом обработки единственной спецификации, включая порождение дополнительных спецификаций работы, но исключая работу, заключающуюся в обработке этих дополнительных спецификаций работы.

Г.23. Proforma (проформа) часть специфика пни работы, которая указывает дополнительную работу и используется для формирования новой спецификация работы как части выполнения предшествующей работы.

Г.24. Report manipulation operations (операции манипулирования уведомлениями) — операции, запрашивающие удаление или отображение уведомлений, сохраненных открытой системой, назначенной некоторой спецификацией работы в качестве пункта монитора.

Г.25. Report manipulation work specification (спецификация работы манипулирования уведомлениями) — спецификация работы, содержащая операции манипулирования уведомлениями.

Г.26. Report work specification (спецификация работы уведомления) — тип спецификации работы, созданной поставщиком услуг службы JTM для перемещения уведомлений службы JTM; целевая открытая система для таких спецификаций работы представляет собой открытую систему Мониторов задания модели OSI.

Г.27. Retry-later diagnostic (диагностическое сообщение «Повторить позже» )— информация, передаваемая услугой элемента CCR при отказе совершения операции, когда действие не может быть завершено по причинам, которые могут быть кратковременными,

Г.28. Selector (селектор) — данные, которые используются для указания либо не выбирать, либо выбрать одну или несколько спецификаций работы.

Г.29. Sink agency (принимающее агентство) —¹ некоторая часть открытой системы, в которую документы в результате обработки спецификации работы могут быть переданы поставщиком услуг службы JTM.

Г.30. Source agenc}' (исходное агентство) — некоторая часть открытой системы, которая может представить документы в результате обработки спецификации работы, если они запрашиваются поставщиком услуг службы JTM.

Г.31. Spawning (порождение) — процесс получения данных из проформы и использования их для формирования новой спецификации работы.

Г.32. Spawning control data (данные управления порождением) — данные, содержащиеся в проформе, которая управляет состояниями, при которых имеет место порождение из этой проформы.

Г.ЗЗ. Top level proforma (проформа верхнего уровня) — проформа, которая не содержится внутри никакой другой проформ^-

Г.34. Transfer control record (запись управления передачей) — концептуальная структура данных, сохраненная открытой системой, для управления передачей спецификаций работы и введения сервисных примитивов.

Г.35. Transfer manipulation operations (операции манипулирования передачей) — операции, запрашивающие записи управления передачей для установки, отображения или проверки.

Г.36. Transfer manipulation work specification (спецификация работы манипулирования передачей) — спецификация работы манипулирования, содержащая операции манипулирования передачей.

Г.37. Update (корректировка) — данные, которые используются для модификации выбранной спецификации работы или проформы.

Г.38. User identification' (идентификация пользователя) — данные, которые могут использоваться в определенном контексте, чтобы идентифицировать пользователя, от имени которого должна запрашиваться работа.

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

Г.40, Work manipulation operations (операции манипулирования работой) — операции, которые выбирают одну или несколько спецификаций работы или проформ и запрашивают отображение, уничтожение, остановку или модификацию.

Г.41. Work manipulation work specification (спецификация работы манипулирования работой) — спецификация работы, содержащая операции манипулирования работой.

Г.42. Work specification (спецификация работы) — концептуальная структура данных, используемая поставщиком услуг службы JTM, указывающая определенным способом работу, которая должна быть выполнена.

ГОСТ Р 34.1 МЗ-83 С. 183

Г.43. Work specification identifier (Идентификатор спецификации работы) — уникальный указатель для спецификации работы, который содержит имя системы предъявления задания модели OSI, идентификацию н^ицдирующего пользователя, локальный указатель задания модели OSI я имц задания модели OSI; если спецификация работы была создана порождением, иАентйфикатЬр также содержит одно или несколько проформы.

Г.44. Work spetiflcatfon transfer (передача спецификации работы) — элементарное действие, с помощью которого¹ спецификация работы -создается в принимающей открытой системе и разрушается в посылающей открытой системе.

G 184 ГОСТ Г ЗИИ Ш-93

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

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

• 2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 03³03.93 Л 62

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

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

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

  Обозначение отечественного НТД, на который дана ссылка	Обозначение соответствующего международного стандарта	Номер пункта, подпункта, приложения
  ГОСТ 34 9711—91	ИСО 8822—88	1.2, приложение Б
  ГОСТ 34.973—91	ИСО 8824—87	1.2, 3.2.3.3, 3.3.2, 3.5.1, 3.5.2, 3.5.3, 4.1.2, приложение Б
  ГОСТ Р 34.1980.3—92	ИСО 8571/3-88	1.2, 2.1.2, 2.1.4, 3.3.3, 34.4.1
  ГОСТ 27463—87	ИСО 646—83	1.2, 2.1.8.4, 3.2.3.2
  ГОСТ 27466—87	ИСО 2022—86	1-.2, 3.2 3.2
  ГОСТ 28906—91	ИСО 7498—84	1.1, 1.21, 2.1, приложс-
  —	ИСО 2375—853	ние А
  —	ИСО/ТО 8509-873	1 2, 2.1.8.4
  —	ИСО 8832—893	Приложение А, 1.2 1.2, 2.1.15.5, 3.5.1, 3.5.2,
  	ИСО 9804—903	4.К2, приложение Б 1.2, 1.3.1

СОДЕРЖАНИЕ

Видение

Раздел 1. Общее описание

• 1.1. Назначение

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

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

• 1.3.1. Определения-услуг элемента СПиВ........ .

• 1.3.2. Определения услуг службы ПОЗ

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

• 1.5. Соглашения

Раздел 2. Обзор

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

• 2.1.1. Обзор....................

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

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

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

• 2.1.5. Задания модели ВОС

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

2.J.7. Уведомляющая служба и функция монитора

• 2.1.8. Совершение, параллельность и восстановление

• 2.1.9. Управление передачей

• 2.1.10. Манипулирование уведомлениями

• 2.1.11. Манипулирование работой

• 2.1.12. Манипулирование передачей

• 2.1.13. Санкционирование и учет

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

• 2.1.15. Ответственность уведомляющей службы

• 2.1.16. Документы

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

• 2.2. Обзор услуг

• 2.3. Базисные и расширенные реализации

• 2.4. Модель для сервисной спецификации

Раздел 3. Определение Примитивов ...

• 3.1. Сервисные примитивы службы ПОЗ

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

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

• 3.1.3. Параметры примитивов,, относящихся к элементу СПиВ . .

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

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

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

данных.............,

• 3.2.1. Базисные типы данных

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

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

  • 3.3. События службы ПОЗ и параметры уведомлений

    • 3.3.1. Категории'Событий

    • 3.3.2. Уведомления

    • 3.3.3. Параметр «Диагностическая информация»

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

    • 3.4.1. Спецификации работы

    • 3.4.2. Параметры задания модели ВОС

    • 3.4.3. Параметры подзадания модели ВОС

    • 3.4.4. Параметры действия службы ПОЗ

    • 3.4.5. Проформы

    • 3.4.6. Списки заголовков

3.4.7 Записи управления передачей

• 3.5. Документы службы ПОЗ

  • 3.5.1. Документ отображения уведомления службы ПОЗ .... 109

  • 3.5.2. Документ отображения работы службы ПОЗ

  • 3.5.3. Документ отображения записи TCR службы ПОЗ , . . . 111

• 3.6. Параметры сервисных примитивов службы ПОЗ

  • 3.6.1. Примитивы запроса и подтверждения J-INITIATE .... 112

  • 3.6.2. Сервисные примитивы J-DISPOSE

  • 3.6.3. Сервисные примитивы J-GIVE

  • 3.6.4. Примитивы индикации и ответа J-ENQUIRE

  • 3.6.5. Примитив запроса J-MESSAGE

  • 3.6.6. Примитив запроса J-SPAWN

  • 3.6.7. Примитив запроса J-END-SIGNAL

  • 3.6.8. Примитивы индикации и ответа J-STATUS

  • 3.6.9. Примитивы индикации J-HOLD, J-RELEASE, J-KILL,

J-STOP

• 3.6.10. Краткая сводка

Раздел 4. Базисный класс

О. Группы примитивов и типы документов для базисного класса . . )24

• 4.1.1. Группы сервисных примитивов

• 4.1.2. Типы документов............... • ■ 124

• 4.2. Концептуальные структуры данных для базисного класса . . . 125

• 4.2.1. Уведомления..................,

• 4.2.2. Спецификация работы............, . . 126

• 4.2.3. Операции по перемещению документа

• 4.2.4. Операции по манипулированию работой

• 4.2.5. Операции по перемещению уведомлений

• 4.2.6. Проформы

• 4.2.7. Прозрачность проформ

• 4.2.8. Записи управления передачей

• 4.2.9. Документы службы ПОЗ.....: ........ 132

• 4.3. Параметры группы примитивов J-1NITIATE для базисного

класса . .

• 4.3.1. Параметры верхнего уровня*

• 4.3.2. Параметры задания модели ВОС

• 4.3.3. Параметры подзадания модели ВОС

• 4.3.4. Параметры действия службы ПОЗ

• 4.3.5. Проформы

• 4.3.6. Краткое изложение информации, содержащейся в примитиве

запроса J-INITIATE базисного класса

• 4.4. Другие группы примитивов в базисном классе

• 4.4.1. Примитив J-DISPOSE

• 4.4.2. Примитив J-GIVE

• 4.4.3. Другие группы

• 4.5. Краткое описание примитивов и параметров базисного класса. . 139

Приложение А. Соглашения по услугам службы ПОЗ

А.К Введение

А.2. Назначение.................. . . 141

А.З. Ссылки

А.4. Определения.....• . • « • 141

А.5, Модель службы ПОЗ ......

А.6. Сервисные примитивы................

А.7. Временные диаграммы......_..........

• A. 8. Соглашения при поименовании сервисных примитивов ....

Приложение Б. Реестры типов документов......■......

Б.1. Введение.....................

Б.2. Назначение элемента •..................

Б.З. Идентификация...................

Б,4. Семантика документа................

Б.5. Синтаксис передачи.................

Б.6. Отношение синтаксиса и семантик............

Б.7. Синтаксические соглашения..............

Б.8. Содержимое реестра.................

Приложение В. Консультативный материал...........

• B. 1. Введение.....................

В.2. Архитектура....................

В.З. Уведомляющая служба................

В.4. Манипулирование..................

В.5. Примитивы J-INITIATE.......'.........

В.6. Поименование....................

В.7. Аутентификация...................

В.8. Терминология службы JTM..............

В.9. Параметры задания модели OSI............

В. 10. Идентификация управляющей системы..........

ВЛ. Активность службы JTM (подзадания).........

В.12. Действие при ошибках................

В.13. Документы....................

В.14. Промежуточные системы службы JTM..........

В. 15. Протоколы доступа к агентству............

В. 16. Временные соотношения в сервисных примитивах.....

В.17. Подмножества и соответствие.............

В.18. Взаимодействие реализаций базисного класса и расширенных

Редактор Т. С. Щеко

Технический редактор В. Н. Прусакова Корректор И. И. Гаврищук

Сдано в набор 32.04.93. Подл, в печ. 29.06.93. Усл. печ. л. 10.92. Усл. кр.-отт, 11.05. Уч.-изд. л. 12.95. Тнр. 419 экз. С 297.

Ордена «Знак Почета» Издательство стандартов. 107076, Москва, Колодезный лер.. 14. Калужская типография стандартов, ул. Московская. 256. Зак. 815

¹

До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 «Информационная технология».

²

До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 «Информационная технология».

³

До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 «Информационная технология».