Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

105 страниц

700.00 ₽

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

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

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

Стандарт требует от пользователя ПОЗ:

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

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

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

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

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

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

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

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

Оглавление

Предисловие

Раздел 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.1.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 Документ «отображение-отчета» ПОЗ

      3.5.2 Документ «отображение-работы» ПОЗ

      3.5.3 Документ «отображение-ЗУП» ПОЗ

   3.6 Параметры сервисных примитивов ПОЗ

      3.6.1  Примитивы запроса и подтверждения J-INITIATE

      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. Базовый класс

   4.1  Группы примитивов и типы документов для базового класса

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

      4.1.2 Типы документов

   4.2 Концептуальные структуры данных для базового класса

      4.2.1 Отчеты

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

      4.2.3 Операции перемещения документов

      4.2.4 Операции выполнения работы

      4.2.5 Операции перемещения отчетов

      4.2.6 Проформы

      4.2.7 Прозрачность проформ

      4.2.8 Записи управления передачей

      4.2.9 Документы ПОЗ

   4.3  Параметры группы примитивов J-INITIATE для базового класса

      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 Сводный перечень примитивов и параметров базового класса

Приложение А. Соглашения по услугам ПОЗ

   А.1 Введение

   А.2 Назначение

   А.3 Ссылки

   А.4 Определения

   А.5 Модель ПОЗ

   А.6 Сервисные примитивы

   А.7 Временные диаграммы

   А.8 Соглашения по наименованиям сервисных примитивов

Приложение В. Регистры типов документов

   В.1 Введение

   В.2 Назначение элемента

   В.3 Идентификация

   В.4 Семантика документов

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

   В.6 Взаимоотношения синтаксиса и семантики

   В.7 Синтаксические соглашения

   В.8 Содержимое регистра

Приложение С. Консультативный материал

   С.1 Введение

   С.2 Архитектура

   С.3 Служба отчетности

   С.4 Обработка

   С.5 Примитивы J-INITIATE

   С.6 Присвоение имен

   С.7 Аутентификация

   С.8 Терминология ПОЗ

   С.9 Параметры заданий ВОС

   С.10 Идентификация систем административного управления

   С.11 Активность ПОЗ (подзадания)

   С.12 Действия при ошибках

   С.13 Документы

   С.14 Ретрансляционные системы ПОЗ

   С.15 Протоколы доступа к агентству

   С.16 Временные соотношения между сервисными примитивами

   С.17 Подмножества и соответствие

   С.18 Взаимодействие базовых и расширенных реализаций

   С.19 Протокол ПОЗ

   С.20 Примеры механизма назначения полномочий

Приложение D. Словарь терминов

Показать даты введения Admin

Страница 1

ГОСТ Р ИСО/МЭК 8831-99 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология Взаимосвязь открытых систем

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

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

БЗ 1-98/83


ГОССТАНДАРТ РОССИИ Москва

Страница 2

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

Предисловие

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

митета Российской Федерации по связи и информатизации

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

2    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постаноатением Госстандарта России от 25 марта

1999 г. №92

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

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

©ИНК Издательство стандартов, 1999

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

II

Страница 3

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

Содержание

Предисловие..................................................................................11

Напел 1. Обшее описание....................................................................1

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

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

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

1.3.1    Определения услуг СГ113.........„......................................2

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

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

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

Раздел 2. Обзор..............................................................................5

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

2.1.1    Обзор............................................................................5

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

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

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

2.1.5    Задания ВОС......................................................................7

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

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

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

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

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

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

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

2.1.13    Нол I юмочия и учет..............................................................15

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

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

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

2.1.17    Промежуточные системы 1103..................................................18

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

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

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

Раздел 3. Определение примитивов..........................................................21

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

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

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

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

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

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

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

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

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

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

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

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

3.3.2    Огчеты............................................................................29

3.3.3    Параметр «диагностическая информация»......................................31

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

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

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

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

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

3.4.5    Проформы........................................................................50

3.4.6    Списки заголовков........................................51

Ш

Страница 4

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

3.4.7 Записи управления передачей....................................................53

3.5    Документы ПОЗ......................................................................54

3.5.1    Документ «отображение-отчета» ПОЗ............................................54

3.5.2    Документ «отображение-работы* ПОЗ............................................54

3.5.3    Документ «отображение~ЗУП» ПОЗ..............................................55

3.6    Параметры сервисных примитивов ПОЗ..............................................55

3.6.1    Примитивы запроса и подтверждения J-INITIATE..............................55

3.6.2    Сервисные примитивы J-DISPOSE..............................................56

3.6.3    Сервисные примитивы J-GIVE..................................................57

3.6.4    Примитивы индикации и ответа J-ENQUIRE....................................58

3.6.5    Примитив запроса J-MESSAGE..................................................58

3.6.6    Примитив запроса J-SPAWN....................................................59

3.6.7    Примитив запроса J-END-S1GNAL..............................................59

3.6.8    Примитивы индикации и ответа J-STATUS......................................59

3.6.9    Примитивы индикации J-HOLD. J-RELEASE. J-KILL. J-STOP................59

3.6.10    Краткое описание..............................................................60

Раздел 4. Базовый класс....................................................................62

4.1    Группы примитивов и типы документов для базового класса........................62

4.1.1    Группы сервисных примитивов..................................................62

4.1.2    Типы документов................................................................62

4.2    Концептуальные структуры данных для базового класса..............................63

4.2.1    Отчеты............................................................................63

4.2.2    Спецификации рабогы.......................................64

4.2.3    Операции перемещения документов..............................................65

4.2.4    Операции выполнения работы.............................................65

4.2.5    Операции перемещения отчетов..................................................66

4.2.6    Проформы........................................................................66

4.2.7    Прозрачность проформ..........................................................66

4.2.8    Записи управления передачей ..................................................66

4.2.9    Документы ПОЗ..................................................................66

4.3    Параметры группы примщгивов J-1N1TIATE для базового класса....................67

4.3.1    Параметры верхнего уровня......................................................67

4.3.2    Параметры задания ВОС..........................................................67

4.3.3    Параметры подзадання ВОС......................................................67

4.3.4    Параметры действия ПОЗ........................................................67

4.3.5    Проформы........................................................................68

4.3.6    Краткое описание информации, содержащейся в примитиве запроса J-INITIATE

базового класса..................................................................69

4.4    Другие группы примитивов в базовом классе ........................................69

4.4.1    Примитив J-DISPOSE............................................................69

4.4.2    Примитив J-GIVE................................................................69

4.4.3    Другие группы примитивов......................................................69

4.5    Сводный перечень примитивов и параметров базового класса........................69

Приложение А. Соглашения по услугам ПОЗ................................................71

А.1 Введение..............................................................................71

А2 Назначение..........................................................................71

АЗ Ссылки................................................................................71

А4 Определения..........................................................................71

А5 Модель ПОЗ....................................................................71

А6 Сервисные примитивы..............................................................71

A.7    Временные диаграммы................................................................72

Л.8 Соглашения по наименованиям сервисных примитивов..............................74

Приложение В. Регистры типов документов................................................75

B.I    Введение..............................................................................75

В.2 Назначение элемента................................................................75

IV

Страница 5

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

В.З Идентификация......................................................................75

В.4 Семантика докумешов................................................................75

В.5 Синтаксис передачи..................................................................75

В.6 Взаимоотношения синтаксиса и семаюики..........................................76

В.7 Синтаксические соглашения..........................................................76

B.8    Содержимое регистра................................................................76

Приложение С. Консультативный материал..................................................77

C.!    Введение..............................................................................77

С.2 Архитектура..........................................................................77

С.З Служба отчетности..................................................................79

С.4 Обработка............................................................................79

С.5 Примитивы J-1NIT1ATE..............................................................79

С.6 Присвоение имен....................................................................80

С.7 Аутентификация......................................................................80

С.8 Терминология ПОЗ..................................................................81

С.9 Параметры заданий ВОС..............................................................81

С. 10 Идентификация систем административного управления............................82

C.1I Активность ПОЗ (подзадания)......................................................82

С. 12 Действия при ошибках..............................................................87

С. 13 Документы..........................................................................87

С. 14 Ретрансляционные системы ПОЗ....................................................87

С. 15 Протоколы доступа к агентству.................................91

С.16 Временные соотношения между сервисными примитивами........................91

С. 17 Подмножества и соответствие......................................................91

С. 18 Взаимодействие базовых и расширенных реализаций..............................94

С. 19 Протокол ПОЗ......................................................................95

С.20 Примеры механизма назначения полномочий......................................95

Приложение D. Словарь терминов..........................................................97

V

Страница 6

ГОСТ Р ИСО/МЭК 8831-99 ГОСУДАРСТВЕННЫЙ С ТА НДАРГ РОСС ИЙ С К О Й Ф Е Д Е Р А Ц И И

И нформанионная технология Взаимосвязь открытых систем

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

Information technology. Open Systems Interconnection.

Job transfer and manipulation concepts and services

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

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

1.1    Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I

I имя

Страница 7

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

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

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

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

ИСО 2375—851 Обработка данных и процедуры регистрации выходной последовательности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2

1

Оригиналы и проекты ИС'О/МЭК — во ВНИМКИ Госстандарта России.

Страница 8

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

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

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

1.3.2.4    Задания ВОС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3.2.7    Упрощение пе/нгдачами

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

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

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

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

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

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

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

3

1-Г

Страница 9

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3.2.11.5    Идентификация СЛУ открытыми системами — имя открытой системы, которая, если она аутентифицирована, предоставляет полномочия активностям 1103 или подсчитывает расходы, затраченные на административное управление этой открытой системой.

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

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

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

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

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

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

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

1.4    Сокращения

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

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

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

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

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

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

4

Страница 10

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

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

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

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

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

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

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

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

1.5 Соглашения

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

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

2.! Обзор и общее описание

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

2.1.1    Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S

I 3- I04H

Страница 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6

Страница 12

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

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

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

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

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

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

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

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

2.1.5    Задания ВОС

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

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

2.1.6.1    Нормаш/ая (Сработка

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

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

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

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

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

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

Если при обработке СР были сформированы и новые СР, то после обработки эти новые СР

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

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

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

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

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

7

I у

Страница 13

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

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

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

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

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

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

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

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

попытку;

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

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

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

попытку;

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

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

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

попытку.

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

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

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

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

Страница 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I») модификация подзадаиия с помощью управляющего запроса:

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

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

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

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

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

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

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

9

Страница 15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10

Страница 16

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

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

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

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

2.1.8.2.3 Уровень исполнения «приемлемый для поставили к а» (у р о в е н ь I)

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

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

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

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

2.1.8.3    Тай м-а у т ы

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

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

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

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

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

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

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

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

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

II

Страница 17

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

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

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

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

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

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

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

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

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

2.1.8.5.1 У р очень и с и о л н е н и я

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

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

2.1.8.5.2    Параметр *д и а «> н о с т и к а»

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

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

b)    кода диагностики 1103;

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

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

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

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

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

II р и м с ч а и и я

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

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

2.1.8.5.3    Парам е т р *у н е т»

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

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

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

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

12

Страница 18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.8.6.2    Параметр «учет»

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

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

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

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

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

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

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

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

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

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

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

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

Страница 19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14

Страница 20

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

2.1.11.1 Селекторы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15

Страница 21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16

Страница 22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17

Страница 23

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

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

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

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

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

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

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

2.1.16    Документы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страница 24

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страница 25

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

1) концепция «удержание* не обеспечивается:

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

1)    J-INITIATE-TCR-MAN

2)    J-INITIATE-REPORT-MAN

3)    J-ENQUIRE

4)    J-HOLD

5)    J-RELEASE

6)    J-SPAWN

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

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

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

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

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

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

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

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

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

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

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

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

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

20

Страница 26

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21

2 ■■ 1 . имя

Страница 27

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

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

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

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

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

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

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

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

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

a)    примитив запроса J-BEGIN, за которым следует

b)    один из:

1)    примитивы запроса и подтверждения J-1N1TIATE-W0RK;

2)    примитивы запроса и подтверждения J-INU IATE-WORK-MAN;

3)    примитивы запроса и подтверждения J-IN1T1ATE-RJEPORT-MAN;

4)    примитивы запроса и подтверждения J-1N1T1ATE-TCR-MAN,

5)    примитив запроса J-MESSAGE:

6)    примитив запроса J-SPAWN, после которого может следовать факультативная последовательность совокупности результатов, указанная в 3.1.2.3;

7)    примитив запроса J-END-SIGNAL, после которого может следовать факультативная последовательность совокупности результатов, указанная в 3.1.2.3, за которой следует

c)    один из:

1)    примитив индикации J-READY:

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

d)    один из:

1)    примитивы запроса и подтверждения J-COMMIT;

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

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

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

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

a)    примитив индикации J-BEGIN. за которым следует

b)    один из:

1)    примитивы индикации и ответа J-DISPOSE, за которыми может следовать факультативная последовательность совокупности результатов, указанная в 3.1.2.3:

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

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

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

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

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

22

Страница 28

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

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

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

c)    один из:

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

2)    примитивы запроса и подтверждения J-ROLLBACK, за которыми только в случае примитива запроса J-READY следует

d)    олин из:

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

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

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

3.1.2.3    Последовательность совокупности pejy.ibmamoe

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

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

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

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

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

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

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

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

3.1.3.2    Примитивы ответа и подтверждения J-BEGIN Параметр «данные пользователя» не используется.

3.1.3.3    Примитивы зап/юса и индикации J-PREPARE Параметр «данные пользователя» не используется.

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

a)    уровень исполнения операций (см. 2.I.8.5.1),

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

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

3.1.3.5    Примитивы запроса и индикации J-СОММЕГ Параметр «данные полыователя* не используется.

3.1.3.6    Примитивы ответа и подтверждения J-COMMIT Параметр «данные пользователя* не используется.

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

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

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

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

3.1.3.8    Примитивы ответа и подтверждения J-ROLLBACK Параметр «данные полыователя» не используется.

3.1.3.9    Примитивы запроса и индикации J-RECOVER Параметр «данные пользователя» не используется.

3.1.3.10    Примитивы ответа и подтверждения J-RECOVER Параметр «данные полыователя» не используется.

23

Страница 29

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

3.! .4 Последовательность групп сервисных примитивов Примитивы следующей группы могут выдаваться в любое время:

J-INITIATE-NVORK:

J-1N1TIATE-WORK-MAN:

J-IN1TIATE-REPORT-MAN;

J-IN1TIATE-TCR-MAN;

J-DISPOSE;

J-GIVE;

J-ENQUIRE.

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

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

J-MESSAGE;

J-SPAWN.

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

J-MESSAGE;

J-SPAWN;

J-END-SIGNAL.

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

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

J-STATUS;

J-HOLD;

J-RELEASE;

L-KILL:

J-STOP.

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

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

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

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

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

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

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

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

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

24

Страница 30

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

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

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

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

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

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

a)    литералы:

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

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

d)    типы данных «имя»:

e)    типы данных «ссылка*:

О типы данных «документ*.

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

ПЕРЕМЕЩЕНИЕ    ВЫСОКИЙ    СОЗДАНИЕ

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

ными для отметки базовых типов данных в перечислениях Ь) и 0. Например: целочисленный тип    < определяющее целое число = I >

строка    < имя задания В ОС = S >

<    имя источника = S >

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

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

<    тип документа = ND >

ссылка    < параметры защиты = R >

документ    < базовый документ = D >

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

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

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

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

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

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

<    срочность >

<    удержания >

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

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

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

| < базовый докуме1гт = D > |*L;

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

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

25

2 2-10(8

Страница 31

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

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

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

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

<    разрешения > : : = | < элемент разрешения > |4С

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3.3    Типы данных «имя*

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

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

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

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

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

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

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

26

Страница 32

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип собыгии систем

Слисок нелепы к систем

Число

порохле

иий

Темп

Диагнос

тика

Состой иие удержания

Состояние

1Л111ПГЫ

С hi идя

ОСТЛИОПЛ

Учетная

информа

ции

СОЗДАНИЕ

*

«

ПЕРЕДАЧА

*

ПОРОЖДЕНИЕ

*

t

11 НИ ЕМJI ЕМ U И-ДЛЯ-АГЕНТСТВА

Д И А1 НОСТИКА-ОШИБОК

*

НЕ-ВЫПОЛНЯЕТСЯ

*

L О О Ь Ш Е Н И Е -ПОЛЬЗОВАТЕЛЯ

УЧЕТНЫЕ-ДАННЫЕ

•с

НОРМ АЛ ЬНОЕ-ЗА-ВЕРШЕНИЕ

ЗАВЕРШЕН ИЕ-ОБ-РАБОТКИ

t

МОДИФИКАЦИЯ

ЗАВЕРШЕНИЕ-НЕ-

ОБЕСПЕЧЕНО

л

А ВАРИ ИНОЕ-ЗАВЕРШЕНИЕ

»

Щ

*

ПО П ЫТ КА-НА РУШЕН ИЯ

Й

11РЕДУП РЕЖДАЮ-ШЕЕ-УВЕДОМЛЕ-НИЕ

ш

х

2-2'

27

Страница 33

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28

Страница 34

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

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

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

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

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

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

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

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

3.3.2 Отчеты

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

<    отчет > :: = < имя уведомителя = N >

<    отметка времени >

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

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

<    параметры события >

<    отметка времени > : ; = (НУЛЬ | < дата-время = S > )

<    идентифнкаиия-подзадания > : : =

<    система предоставления задания ВОС = N >

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

<    время инициирования >

<    имя задания ВОС = S >

<    локальный указатель задания ВОС = S >

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

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

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

<    идентификация > :; =

( < САУ открытой системы > | < САУ полномочий > | < пользователь > )

<    САУ открытой системы > : : = < имя открытой системы = N >

<    САУ полномочий > : : = < имя уполномоченного = NA >

<    пользователь > : : = < имя уполномоченного = NA >

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

<    время инициации > :; = < отметка времени >

<    список имен подзаданий > : ; = | < компонент имени подзадания > |"L

<    компонент имени подзадания > :: = < имя проформы = S > (см. 3.4.5)

< классификационное целое = I >

29

2 J - ЮМ

Страница 35

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

<    параметры события > : : =

(НУЛЬ | <список целевых систем >) (см. 3.4.3)

(НУЛЬ | < число порождений = 1 >)

(НУЛЬ | | < текст = S >1*L

(НУЛЬ | | < диагностическая информация >|*С (см. 3.3.3)

(НУЛЬ |< защищенные данные >) (см. 3.3.3.1)

(НУЛЬ |< состояние задержки >)

(НУЛЬ |< сигнал останова >)

(НУЛЬ |< учетная информация >) (см. 3.3.3.2),

<    состояние задержки > :: =

(ЗАДЕРЖКА | НЕТ-ЗАДЕРЖКА)

<    сигнал останова > : : =

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30

Страница 36

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

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

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

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

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

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

< диагностическая информация > : : = < детали формирователя >

< отметка времени > (см. 3.3.2)

<диагностика СИВ > (см. ниже)

<    детали формирователя > :: = (< детали исходного агентства > | < детали пи > |

< получатель = N > | ПОСТАВЩИК)

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

<    детали исходного агентства > : : ■=

<    идентификация исходного агентства >(см. 3.4.4.1.3)

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

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

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

Параметр < детали исходного агентства > идентифицирует подчиненный Л О СИВ и некоторые параметры примитива J-GIVE, если он выполнил примитив J-ROLLBACK. 11арах<етр < детали пи > идентифицирует подчиненный ЛОСИ В и некоторые параметры примитива J-D1SPOSE. Параметр

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

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

Параметр < диагностика СИВ > значения ПРЕДУПРЕЖДЕНИЕ встраивается в параметр

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

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

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

<    Диагностика СИВ > :: = (|Предупреждение|*С | |< Повторить позже >|*С 11< Не повторять >|*С)

<    Предупреждение > : : = < формирователь = N >

<    код >

(< причина > | < результат ПДУФ >)

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

<    код >

(< причина > | < результат ПДУФ >)

<    гайм-аут повторения = I >

2-У

Страница 37

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

<    He-повторять >:: =    < формирователь = N >

< код >

(< причина >|< результат ПДУФ >) (см. ниже)

<    результат ПДУФ >:: = < «результат передачи операции писать- или «результат передачи опера

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

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

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

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

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

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

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

<    защищенные данные >: : = < проверочная трасса > (см. 3.4.2)

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

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

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

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

<    учетная информация > : : = |< информация о затратах >1*С

<    информация о затратах > : : = < идентификация >(см. 3.3.2)

<    имя-ресурса = S >

<    единица-затрат = S >

<    затраты = I >

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

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

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

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

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

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

СР.

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

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

Страница 38

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

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

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

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

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

3.4.1 Спецификации работы <спецификация работы >: : = < параметры задания ВОС > (см. 3.4.2)

<    список имен подзаданий > (см. 3.3.2)

(< спецификация ползадания >| НУЛЬ)

<    список проформ >

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

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

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

<    параметры подзадання ВОС > (см. 3.4.3)

<    параметры действия ПОЗ > (см. 3.4.4)

<    действия при ошибке > (см. 3.4.3.4)

<    список проформ > : : = |< проформа >|*L (см. 3.4.5)

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

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

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

<    список документов > :: = |< документ = L) >\*L

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

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

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

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

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

Иоле < действия при ошибке > указывает, сохранять ли СР для модификации или удалить ее. если обнаруживаются ошибки во время обработки или передачи этой СР.

Поля < проформа > определяют дальнейшую работу (при ее наличии), которая должна быть инициирована после обработки поля < параметры действия ПОЗ >. Эта дальнейшая работа определяется последующими полями < параметры подзадання ВОС > и полем < параметры действия ПОЗ > п проформе вместе с параметрами задания ВОС для полного задания ВОС. Каждое поле < проформа > содержит указание о том. когда подзадание. которое оно определяет, должно быть инициировано.

33

Страница 39

ГОСТ Р ИСО/МЭК 8831-99

и может содержать дальнейшие проформы. Количество активностей, которые могут быть описаны вложенными проформами, не ограничено (и не обязательно является конечным числом), поэтому определение полей обязательно должно быть рекурсивным.

Поле < параметры активности агентства > представлено в концептуальной структуре данных, только в том случае, если принимающее или исполняющее агентство находится в состоянии выполнения активности относительно этого поля. Оно идентифицирует активность в агентстве для последующих примитивов J-KILL. J-HOLD, J-RELEASE или J-STATUS. В базовом классе имеется не больше одной активности агентства, связанной с СР.

Форма поля < параметры активности агентства > не определена, поскольку это поле имеет только локальную значимость. Оно используется в промежутке между примитивами J-D1SPOSE и соответствующим примитивом J-END-S1GNAL для идентификации активности в агентстве, связанной с этой СР. Эти поля обеспечиваются агентством в примитиве ответа J-DISPOSE и используются во всех последующих взаимодействиях, относящихся к этой активности. Они отсутствуют в проформах.

Поле < время ожидания = I > содержит время в минутах, истекшее после того, как СР введена в состояние ожидания обработки поставщиком услуг ПОЗ. Она может находиться в состоянии ожидания передачи или выдачи примитивов J-GIVE или J-DISPOSE. Поле является нулевым, если СР не предполагает участия поставщика услуг, как например, если она находится в состоянии удержания или в состоянии ожидания примитива J-END-SIGNAL.

Поле < подсчитанный размер > является нулевым (если только не ожидается передача этой СР в другую открытую систему), если подсчитанный размер измеряется в килооктетах элемента передачи ПОЗ (включая любые вложенные документы), который должен использоваться по базовым правилам кодирования ACH.I для данного элемента передачи и для соответствующей минимальной PC. запросившей синтаксис передачи для этих вложенных документов.

Поля < документ > (при их наличии) формируют часть или все материалы, подлежащие передаче в принимающие или исполняющие агентство во время выполнения данного задания ВОС. На каждое поле < документ > дается ссылка в поле < параметры действия ПОЗ > путем указания его позиции в списке. Значение параметра < тип документа > также записывается в поле < параметры действия 1103 >.

3.4.2 Параметры задания ВОС < параметры задания ВОС =

<    система предоставления задания ВОС = N >

<    идентификация инициирования > (см. 3.3.2)

<    время инициирования > (см. 3.3.2)

<    имя задания ВОС = S > (см. 3.3.2)

<локальный указатель задания ВОС = S> (см. 3.3.2)

<    проверочная трасса > (см. ниже)

<    первичная контролирующая спецификация > (см. ниже)

<    вторичная контролирующая спецификации > (см. ниже)

<    полномочия > (см. ниже)

<    разрешения > (см. ниже)

<    учет > (см. ниже)

<    параметры защиты = R >

<    параметры СИВ > (см. ниже)

Параметр < система предоставления задания ВОС > вводится поставщиком услуг ПОЗ (требуется, чтобы PC ПОЗ была совместима по конфигурации со значением этого параметра). Имя этой открытой системы равняется первому элементу проверочной трассы после успешной передачи.

Параметр < идентификация инициирования > обеспечивается пользователем ПОЗ и может использоваться при выборке СР последующей операцией обработки, и этот параметр присутствует при отображении и в отчетах. Форма этой идентификации определена в 3.3.2. Эта идентификация не является предметом аутентификации.

Параметр < время инициирования > вводится поставщиком услуг ПОЗ для указания времени предоставления.

Параметр < имя задания ВОС > обеспечивается пользователем 1103 для идентификации задания. Параметр < локальный указатель задания ВОС > обеспечивается поставщиком услуг ПОЗ и является недвусмысленным в области действия параметра < система предоставления задания ВОС >.

Страница 40

ГОСТ Р ИСО/МЭК 8831-99

Параметр < проверочная трасса > используется для определения источника обмена данными:

<    проверочная трасса > :: = |< элемент проверки >|*L

Параметр < проверочная трасса > вначале является пустим. Всякий раз. когда СР передается (используя элемент передачи) в другую открытую систему, элемент добавляется в конец параметра

<    проверочная трасса > для идентификации отравителя:

<    элемент проверки >: : =

<    имя открытой системы = N >

(НЕИЗВЕСТНЫЙ | ИЗВЕСТНЫЙ | АУТЕНТИФИЦИРОВАННЫЙ)

Отправитель вводит собственное имя открытой системы с литералом «НЕИЗВЕСТНЫЙ». Если получатель способен проверить это имя, используя механизмы справочника и доверительно отнестись к адресам у вызова более низкого уровня, значение НЕИЗВЕСТНЫЙ заменяется на ИЗВЕСТНЫЙ. Если положительная аутентификация была выполнена более низкими уровнями, значение НЕИЗВЕСТНЫЙ заменяется на АУТЕНТИФИЦИРОВАННЫЙ.

Примечания

(.Архитектура защити В ОС пока находится в палии разработки, но способна обеспечить услуги аутентификации на более низких уровнях.

2 Административное управление сетей общего пользования обычно обеспечивает некоторую гарантию точности адресов вызова, достаточную для нормальной коммерческой работы, и категорию ИЗВЕСТНЫЙ. Для локальных сетей такая гарантия может отсутствовать.

Использование проверочной трассы при установлении полномочия см. в 3.4.2.1.

Параметр < первичная контролирующая спецификация > вводится поставщиком услуг ПОЗ. Параметры < вторичная контролирующая спецификация > (при их наличии) получаются из примитива J-1N1TIATE.

<    первичная контролирующая спецификация > :: =

< контролирующая спецификация >

<    вторичная контролирующая спецификация > : : =

|< контролирующая спецификация >|»L

<    контролирующая спецификация > : : =

<    спецификация монитора > (см. 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-INIT1ATE, но поставщик услуг ПОЗ может время от времени добавлять дополнительные элементы, получаемые из уже существующих элементов (см. 3.4.2.1). В базовом классе параметр < учет > является пустым.

<    11 ара метры зашиты > определяют использование со стороны ПОЗ механизмов зашиты ннже-расположенного уровня при передаче СР. Он определяет также действие, выполняемое ПОЗ при повторном отклонении услуги. В данном издании настоящего стандарта он имеет только значение «НЕТ*, указывающее, что на более низких уровнях механизмы защиты для предотвращения раскрытия. обнаружения вмешательства не используются или используются только защищенные маршруты.

Примечание — Посте завершения разработки архитектуры защиты ВОС данный раздел предполагается дополнить.

Поле < параметры СИВ > используется, если СР защищена, в конце элементарного действия, и сохраняется поставщиком услуг ПОЗ. В первох< элементарном действии задания ВОС параметры СИВ в примитиве J-BEG IN определяются инициирующим агентством. Значение параметров «указатель кода диагностики», используемых поставщиком услуг ПОЗ для последующих элементарных действий, такое же. как и их значение в группе исполнения J-INITIATE. Поле < параметры СИВ > показывает это значение. (Следует заметить, что оно никогда не передается явно в элементе передачи, передаваемом при помощи примитива С-BEG IN).

35

Страница 41

ГОСТ Р ИСО/МЭК 8831-99

<    параметры СИВ > : : = < указатель кода диагностики = R >

Указатель кода диагностики управляет набором знаков (и, следовательно, языком, используемом в диагностике) СИВ (и. следовательно, в ПОЗ). Необходимо также, чтобы нестандарта зова н-ные текстовые сообщения (см. 3.3.2) соответствовали наборам знаков, указанным в этом параметре.

3.4.2.1 Полномочия и учет

<    элемент полномочий > : : = < идентификация > (см. 3.3.2)

<    поле проверки >

<    элемент учета > :: =    <    идентификация > (см. 3.3.2)

<    поле проверки >

<    элемент разрешения > : : = < идентификация > (см. 3.3.2)

<    поле проверки > : : =    (< индекс проверки = I > | < секретные данные >)

<    секретные данные > : : = (НЕ УСТАНОВЛЕН | < графический пароль = S >|

< двоичный пароль = OS >)

Каждый параметр < элемент полномочий > идентифицирует или пользователя (используюше-го параметр < имя уполномоченного > и одну из введенных им идентификаций), или САУ открытой системы, или идентификационное полномочие (используя имя открытой системы или имя уполномоченного).

Открытая система в общем случае требует наличия известной ей аутентификационной идентификации для полномочия некоторой активности. Такая идентификация получается при использовании элемента полномочий, возможно, вместе с проверочной трассой.

Идентификация с параметром < секретные данные > аутентифицируется (для использования указанной открытой системой в указанное время), если открытая система может иметь доступ к необходимой базе данных, чтобы проверить параметр < секретные данные >, и если проверка была успешной.

Идентификация с доступом < индекс проверки = 1 > аутентифицируется, если все поля

<    элемент проверки >. начиная от места, указанного индексом проверки, и кончая концом проверочной трассы (включительно), имеют удовлетворительную аутентификацию (НЕИЗВЕСТНЫЙ, ИЗВЕСТНЫЙ. АУТЕНТИФИЦИРОВАННЫЙ) и известны той открытой системе, которая доверяет ей. Эта форма поля проверки представляет собой защиту открытой системой, указанной индексом проверки, параметр < идентификация > которой был аутентифицирован ею.

Примечание—В случае, если результаты выполнения выдаются в систему предоставления задания ВОС. открытая система, указанная индексом проверки, может быть гой же самой, что и открытая система, отыскивающая в настоящий момент аутентификационный идентификатор.

Примитив J-IN1TIATE может обеспечивать элементы полномочий только с полями проверки, содержащими параметр < секретные данные >. Поставщик услуг ПОЗ добавляет элементы полномочий множества < индексов проверки > в следующих случаях:

a)    всякий раз, когда проверяется поле < секретные данные >;

b)    если во время выдачи примитива J-INITIATE аутентифицированный параметр < идентификация > инициатора становится известен поставщику услуг ПОЗ при помощи локальной функции САУ:

c)    если в открытой системе имеются таблицы, показывающие, что идентификации, введенные одним полномочием, совпадают с идентификациями, введенными другим полномочием.

Параметр < идентификация инициирования > представляет собой требуемую идентификацию инициирующего ЛО. которая обеспечивается в примитиве J-1N1T1ATE. PC ПОЗ не обязательно должна обладать способностью обнаруживать маскирование такого значения, используя локальные механизмы. С отчетами о попытке нарушения защиты передается также проверочная трасса.

Форма поля < пользователь > параметра < идентификация > является самой общей. Формы параметров < полномочие > и < открытая система > используются для идентификации активности САУ (для полномочий или учета). Форма параметра < полномочие > допускает любую активность ПОЗ. которая может быть разрешена для любой идентификации пользователя, введенной этим полномочием. Форма параметра < открытая система > полномочия необходима для обработки ЗУП, отображения или обработки СР отчетов. Она также обеспечивает право обрабатывать любую СР, которая включает такую открытую систему.

Параметр < элемент учета > используется (таким же способом, как и параметр < элемент полномочий >, чтобы обеспечить аутентифицированный учет для оплаты затрат. В подмножестве

36

Страница 42

ГОСТ Р ИСО/МЭК 8831-99

базового класса параметры < элемент учета > не присутствуют; идентификация учета при необходимости выбирается из идентификаций, обеспечиваемых для полномочия.

Каждый параметр < элемент разрешения > позволяет другим подзадания м выполнения работы вносить изменения в СР. содержащие элемент, предусмотренный только для того, чтобы подзааа-иие обработки содержало допустимый < элемент полномочия > для параметра < иде>гтификапия >, предоставленный в параметре < элемент разрешения >. или. в случае параметра < пользователь > — для своей соответствующей САУ.

3.4.2.2    Селекторы отчетов

<    селектор отчета > : : = |< идентификация события >|*С

<    идентификация события > : : =

(НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ | ЗАВЕРШЕНИЕ-ОБРАБОТКИ |

АВАРИЙНОЕ ЗАВЕРШЕНИЕ | СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ |

СОЗДАНИЕ | ПЕРЕДАЧА | ПОРОЖДЕНИЕ! ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА! МОДИФИКАЦИЯ |ДИАГНОСТИКА-ОШИБОК | НЕ-ВЫПОЛНЯЕТСЯ | УЧЕГНЫЕ-ДАННЫЕ [ НЕ-ОБЕСПЕЧЕНО-ЗАВЕРШЕНИЕ J ПОПЫТКА-НАРУШЕН И Я | ПРЕДУПРЕЖДАЮЩЕЕ-УВЕДОМЛ ЕНИЕ)

Параметр < селектор отчета > требует, чтобы поставщик услуг ПОЗ формировал отчет для всех категорий событий, указанных в совокупности. Отчеты никогда не формируются при событиях, относящихся к формированию, передаче, обработке или размещению отчетов.

3.4.2.3    Спецификации монитора

<    спенификаиия монитора > :: =

|< промежуточная система = N >|*L (см. 3.4.3)

<    системное имя монитора = N >

<    инструкции по размещению >

<    инструкции по размещению > : : = (СОХРАНИТЬ | < данные размещения >)

<    данные размещения > : : = < идентификация пи > (см. 3.4.4.1.1)

< указатель ни документа > (см. 3.4.4.1.2)

Подполя параметра < данные размещения > идентичны подполям параметра < параметры действия ПОЗ > для СР перемещения документов, за исключением того, что параметр < идентификация пи > должен указывать принимающее агентспю. Область разрешенных значений определена в 3.4.4.1.

Параметр < системное имя монитора > указывает открытую систему, в которую должны быть доставлены отчеты. Если значением параметра < инструкции размещения > является СОХРАНИТЬ, открытая система сохраняет отчеты (вместе с соответствующими параметрами задания ВОС) до тех пор, пока она не примет подходящую СР управления полномочным отчетом, требующую его отображения или удаления. Если параметр < данные размещения > присутствует, отчет передается в указанное принимающее агентство, используя группу примитивов J-DISPOSE с параметрами, полученными из параметра < данные размещения >.

Примечание — Иосю завершения времени PC может удалить опеты, которые она сохраняла.

3.4.3    Параметры п о д з а д а н и я ВОС

<    параметры подзадания ВОС > : : = < список целевых систем >

<    срочность > (см. 3.4.3.1)

<    удержания > (см. 3.4.3.2)

<    тип подзадания > (см. 3.4.3.3)

<    список целевых систем > :: =    < промежуточные системы >

<    целевая система = N >

<    промежуточные системы > : : =    |< промежуточная система = N >J*L

Параметр < целевая система > указывает открытую систему, которая должна выполнять действия ПОЗ. Параметр < промежуточные системы > указывает открытые системы, в которых должна иметь место промежуточная обработка ПОЗ на пути к целевой системе. Параметр < промежуточная система > удаляется из верхней части этого списка отправителем во время передачи СР и, таким образом, при достижении целевой системы параметр < промежуточные системы > является пустым.

Параметр < срочность > используется открытыми системами, чтобы содействовать определению последовательности выполнения различных подзаданий ВОС.

37

Страница 43

ГОСТ Р ИСО/МЭК 8831-99

Иоле < удержания > предстаааяет собой совокупность параметров < элемент удержания > и указывает, должна ли обрабатываться концептуальная структура данных, определяющая под задание. Задание ВОС может обрабатываться до завершения, только при отсутствии препятствующих его выполнению параметров < элемент удержания >. Если параметр < элемент удержания > препятствует выполнению элементарного действия в пункте, необходимом для указанного уровня исполнения. элементарное действие возвращается в исходное состояние поставщиком услуг 1103 с диагностикой HE-ПОВТОРЯТЬ. Последующая обработка может удалить или добавить < элемент удержания > к СР или к ее проформам.

Параметр < тип подзадания > определяет природу подзадания и форму параметра < параметры действия П03>.

3.4.3.1    Срочность

<    срочность >:: = (ВЫСОКАЯ | СРЕДНЯЯ | НИЗКАЯ)

Это поле предоставляет информацию от формирователя СР или проформы в открытые системы. выполняющие работу. Она может быть использована в качестве входной информации при планировании какой-либо активности, необходимой для выполнения задания ВОС. Использование этого поля не стандартизовано. При отсутствии какой-либо другой входной информации в процесс планирования подзадание со срочностью ВЫСОКАЯ выполняется перед подзаданием со срочностью СРЕДНЯЯ или НИЗКАЯ (а со значением СРЕДНЯЯ - перед подзаданием со срочностью НИЗКАЯ).

3.4.3.2    Удержания

<    удержания > : : = |< элемент удержания >|*С

<    элемент удержания > : : =

<    местоположение удержания = N >

(< причина = S > | < диагностическая информация > ) (см. 3.3.3)

<    разрешение освобождения >

<    время освобождения >

<    разрешение освобождения > : : = (< идентификация > | НУЛЬ) (см. 3.3.2)

<    время освобождения >:: = (< дата-время = S > | (см. 3.3.2)

< время-суток = S > | < временной интервал = I >)

Параметр < элемент удержания > игнорируется открытой системой, если параметр < местоположение удержания > не содержит имя этой открытой системы. Если параметр < местоположение удержания > в одном или нескольких параметрах < элемент удержания > соответствует имени открытой системы, СР не будет обрабатываться открытой системой (передавать ее. вводить СП. или выполнять порождения из нее). Она может быть передана в пункт, указанный параметром < местоположение удержания > или может быть создана там при помощи порождения или примитива /•INITIATE.

Параметр < элемент удержания > представляется изначально (установлен примитивом J-INITIATE), добавляется позже при помощи выполнения работы или автоматически вводится, если обработка задерживается из-за ошибок (см. 2.1.6.2 и 3.4.3.4).

Если параметр < элемент удержания ;• был введен поставщиком услуг ПОЗ в качестве результата обнаружения ошибки в нем, то параметр < диагностическая информация > содержит детали ошибки, но в нем отсутствует параметр < причина >, а параметр < местоположение удержания > содержит имя открытой системы, вводящей параметр < элемент удержания >.

Если параметр < элемент удержания > был введен при обработке, то параметр < причина > содержит читабельный текст.

Значением параметра «разрешение освобождения® является НУЛЬ, если элемент был введен поставщиком услуг ПОЗ. он может иметь значение параметра < идентификация >, который требует. чтобы подзадание, желающее освободить задержку, содержало элемент полномочий с такой же аутентификационной идентификацией (в дополнение к удовлетворяющему полю < разрешения >). Если значением параметра < разрешение освобождения > является НУЛЬ, то значение поля

<    разрешения > в параметрах задания ВОС управляет освобождением удержания.

Параметр < время освобождения > указывает время, в которое поставщик услуг ПОЗ автоматически удаляет элемент удержания. (Следует заметить, что это вызывает появление события МОДИФИКАЦИЯ). PC может наложить ограничение на период времени, необходимый для своей подготовки к выполнению состояния удержания для СР. Параметр < дата-время > указывает, что элемент

Страница 44

ГОСТ Р ИСО/МЭК 8831-99

удержания должен быть удален в точно указанное абсолютное время. Параметр < время суток > представляется в форме чч. мм и указывает, что элемент удержания должен быть удален, когда это местное время впервые достигает своего значения после порождения подзадания из проформы, или когда СР достигнет заданной открытой системы. Параметр < временной интервал > преобразуется в значение < дата-время > при его наличии в поле < местоположение удержания > в подзадании верхнего уровня (то есть, когда СР достигает < местоположение удержания >). в проформе, содержащей порождение элемента удержания, или когда при выполнении работы элемент удержания добавляется к подзаданию верхнего уровня. Этот параметр указывает удаление элемента удержания, если значение параметра < временной интервал > в минутах преобразовано в значение < дата-время >.

3.4.3.3    Тип подзадания

<    тип подзадания > : : = (ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА | ВЫ ПОЛНЕН НЕ-РАБОТЫ |

ПЕРЕМЕЩЕНИЕ-ОТЧЕТА| ОБРАБОТКА-ЗУП |

У П РАВЛЕН И Е-О'ГЧ ЕГОМ)

Значение этого поля в параметре < параметры подзадания > примитива J-IN1TIATE фиксируется (для каждого примитива J-1NITIATE) относительно значения, соответствующего имени СП. Оно определяет форму параметра < параметры действия 1103 >. Значение этого параметра в проформе не ограничивается примитивом J-INITIATE, используемым для указания задания ВОС, но не может принимать значения ПЕРЕМЕЩЕНИЕ-ОТЧЕТА.

3.4.3.4    Действия при ошибке

<    действия при ошибке > : : =

(УДЕРЖАНИЕ < временной интервал = I > | ЗАВЕРШИТЬ)

Параметр < действия при ошибке > упраатяет действием поставщика услуг ПОЗ в открытой системе, действующего в качестве ГУЛО исполнения операций при обработке СР. Действия описываются ниже.

3.4.3.4.1    И с т о ч и и к и о ш и 6 о к

ГУЛО инициирует одно или несколько ответвлений элементарного действия для:

a)    доступа к исходным агентствам (которые, возможно, используют ИДУФ);

b)    доступа к принимающим агентствам (которые, возможно, используют ПДУФ):

c)    передачи СР (возможно, сформированной в результате порождения).

Одно или несколько этих ответвлений выполнит ь возврат в исходное состояние из управляемого ЛО с диагностикой СИВ. Последующее действие, выполняемое ГУЛО, определяется параметром < действия при ошибке >.

П римечание — Возврат в исходное состояние примитива J-GIVE исходным агентством может привести к ошибке в таком отиетачении элементарного действия в зависимости or установки параметра

<    встроенная диагностика > в нате < указатель источника документа > (см. 3.4.4.1.3).

3.4.3.4.2    Действие УДЕ Р Ж А Н И Е

Значение «УДЕРЖАНИЕ < временной интервал >* вызывает действие, по которому поставщик услуг ПОЗ (при наличии ошибки).

a)    модифицирует параметр < действия по ошибке > в значение ЗАВЕРШИТЬ;

b)    добавляет параметр < элемент удержания > для текущего местоположения с параметром

<    диагностическая информация >, взятого из диагностики СИВ, значение «НУЛЬ < разрешение освобождения >» и параметр < время освобождения >, вычисленный из текущего времени плюс значение параметра < временной интервал >;

c)    формирует любые требующиеся отчеты для события «НЕ-ВЫПОЛНЯЕТСЯ».

3.4.3.4.3    Действие 3 Л В Е Р Ш И Т Ь

Значение ЗАВЕРШИТЬ вызывает действие, по которому поставщик услуг ПОЗ:

a)    удаляет СР;

b)    формирует любые требующиеся отчеты для события «АВАРИЙНОЕ ЗАВЕРШЕНИЕ».

3.4.4    Параметры действия ПОЗ

<    параметры действия ПОЗ > :: =

<    операции перемещения документов > | (см. 3.4.4.1)

<    операции выполнения работы > | (см. 3.4.4.2)

<    операции управления передачами > | (см. 3.4.4.3)

<    операции управления отчетами > | (см. 3.4.4.4)

<    операции перемещения отчетов >) (см. 3.4.4.5)

39

Страница 45

ГОСТ Р ИСО/МЭК 8831-99

Если поле < тип подзадания > имеет значение ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА, то этот параметр содержит < операции перемещения документов >.

Если поле < тип под задан и я > имеет значение ВЫПОЛНЕНИЕ-РАБОТЫ. то этот параметр содержит < операции выполнения работы >.

Если поле <тнп подзадания > имеет значение ОБРЛБОТКЛ-ЗУП. то этот параметр содержит

<    операции управления передачами >.

Если поле < тип подзадания > имеет значение УПРАВЛЕНИЕ-ОТЧЕТОМ, то этот параметр содержит < операции управления отчетами >.

Если поле < тип подзадания > имеет значение ПЕРЕМЕЩЕНИЕ-ОТЧЕТА, то этот параметр содержит < операции перемещения отчета >.

3.4.4.1 Операции перемещения документов

<    операции перемещения документов > : : = |< перемещение документа >|*L

<    перемещение документа > : : = < тип документа = ND >

<    пи агентства >

<    блок документов >

<    пи агентства > : : = |< идентификация пи >|*L (см. 3.4.4.1.1)

Примечания

1    Ike поля < идентификация пи > в списке имеют значение < пи ПОЗ > или < пи ПДУФ >. Произвольное расположение в одном блоке документа не обеспечивается.

2    Если используется параметр < групповая форма >, параметр < идентификация пи > имеет форму < ни ПОЗ >.

<    блок документа >:: ^ (< единичная с|юрма > | (см. 3.4.4.1.2)

(< групповая форма >) (см. 3.4.4.1.2)

Каждый параметр < идентификация пи > идентифицирует принимающее или исполняющее аге)гтство.

По каждому параметру < единичная форма > формируется (с использованием одного или нескольких примитивов J-G1VE) один документ (возможно со встроенной диагностикой - см. 3.4.4.1.3) для размещения целевой системой, возможно, как результат объединения нескольких документов, полученных из исходных агентств. По каждому параметру < групповая форма > либо не формируется, либо формируется один или несколько документов для размещения, каждый с отдельным сочетанием параметров < одна форма >< блок документа >. Все документы, перемещаемые одной операцией < перемещение документа >, имеют один и тот же тип документа. Таким образом, одна операция < перемещение документа > обеспечивает:

a)    перемещение нескольких объединенных документов и возможное дублирование результата (использование параметра < единичная форма >);

b)    перемещение множества документов, возможно, с их дублированием (использование параметра < групповая форма >).

При обработке целевой системой каждой операции < перемещение документа > принимаются все документы, описанные параметром < блок документа >, и передается каждый из них всем аге»гтствам, указанным параметром < пи агентства >, отдельной группой примитивов J-DISPOSE для каждого документа.

В тех случаях, когда документ (для размещения) формируется объединением документов из исходных агентств, каждый документ имеет один и тот же тип. и требуется, чтобы в результате объединения был образован документ того же типа.

Операции < перемещение документа > выполняются целевой системой в порядке поступления всех примитивов индикации J-D1SPOSE для одного параметра до принятия какого-либо примитива индикации J-D1SPOSE для следующей операции. Порядок примитивов индикации J-D1SPOSE при выполнении одной операции < перемещение документа > не определен. Результаты перемещений документов становятся доступны для других элементарных действий только после исполнения. Они становятся доступны в других частях одного и того же элементарного действия во время выдачи примитива индикации J-DISPOSE.

40

Страница 46

ГОСТ Р ИСО/МЭК 8831-99

3.4.4.1.1 Идентификация принимающего и исполняющего агентства

<    идентификация пи > :: = (< пи 1103 > | (< принимающее агентство ПДУФ >)

<    пи 1103 > .: = < имя пи = S >

<    дополнительные полномочия >

<    параметр агентства >

<    метка активности агентства = S >

<    префикс пи >

<    принимающее агентство ПДУФ > : : = < нмя-хранилища-файлов = N >

<    параметр агентства    (НУЛЬ | СОХРАНИТЬ | < формат агентства = S >)

<    префикс пн > .: = |< имя = S >|4L

<    дополнительные полномочия > : : =

(НУЛЬ |< пароль = S >)

(НУЛЬ | < элемент учета >) (см. 3.4.2.1)

(НУЛЬ | < элемент полномочий >) (см. 3.4.2.1)

Имеются две формы параметра . Первая —  используется для принимающих и исполняющих агентств, которые размешают документ локально или удаленно нестандартным способом. Вторая -  - используется для идентификации локального принимающего агентства, которое размещает документ (локально или удаленно), используя ГОСТ Р 34.1980.3.

Параметр < пи ПОЗ > идентифицирует принимающее или исполняющее агентство в области целевой системы, чье имя указывается параметром < имя пи >. Параметр < имя пи > является строкой, определяемой целевой открытой системой для явной идентификации принимающего или исполняющего агентства (внутри такой открытой системы), для которого должен быть выдан примитив J-DISPOSE с целью размещения документа.

Параметр < дополнительные полномочия > обеспечивает факультативный дополнительный пароль, элемент полномочий и элемент учета для доступа к этому принимающему или исполняющему агентству.

< Параметр агентства > передается в примитиве J-DISPOSE и используется (вместе с параметром < тип документа >) принимающим или исполняющим агентством для определения пути, по которому документ должен быть представлен, сохранен или интерпретирован. Если значение параметра СОХРАНИТЬ обеспечивается комбинированным принимающим и исполняющим агентством, агентство запоминает документ таким образом, чтобы любой последующий примитив J-CJ1VE, ссылающийся на такой же параметр < тип документа > и параметр < параметр агентства > вместе с соответствующим параметром < указатель источника документа >, приводил к формированию идентичного документа.

Г1 р и м с ч а н и е — Значение СОХРАНИТЬ не относится к исполняющему агентству.

Если параметр указывает НУЛЬ, документ сохраняется или предоставляется локальным способом. Если параметр указывает < формат агентства >. принимающее или исполняющее агентство использует его для определения способа сохранения материала, представления или интерпретации. Возможные значения строки < формат агентства > не стандартизованы и определяются агентством.

Параметр < метка активности агентства > позволяет определить однозначную логическую связь между примитивом J-DISPOSE, выдаваемым исполняющему агентству и последующим примитивом J-G1VE (из порождаемой проформы), выдаваемым этому агентству. Это необходимо, только в том случае, если одной СР инициируется более одной активности в агентстве.

Их<ена < префикс пи > помещаются в начале списка имен < указатель пи документа > (см. шоке) для каждого документа при формировании параметров, передаваемых в примитиве J-DISPOSE. Этот параметр представляет собой начальную часть поля < список-имен > в примитиве J-DISPOSE, которая должна отличаться для каждого из принимающих и исполняющих агентств в операции

<    перемещение документа >.

< Имя-хранилиша-файлов > в форме < принимающее агентство ПДУФ > идентифицирует (локальное или удаленное) виртуальное хранилище файлов ПДУФ. которое должно принять документ. Вся другая информация по размещению содержится а параметре < указатель пи документа > (см. 3.4.4.1.2).

41

Страница 47

ГОСТ Р ИСО/МЭК 8831-99

3.4.4.1.2 Блок и документа единичной формы

<    единичная форма > : : = < указатель пи документа >

|< указатель документа >|-L

<    указатель пи документа > : : =

(< 1103 писать-данные > | < Г1ДУФ пнсать-данные > )

<    ПОЗ писать-даниые > : : = < параметр доступа пи >

< список-имен >

<    ПДУФ писать-данные > :: =

< «писать спецификацию передачи» как определено в приложении D ГОСТ Р 34.1980.3 >

Примечание — Форма < ПДУФ писать-данные ПДУФ > используется только в том случае, если соответствующие параметры < идентификация пи > имеют форму < принимающее агентство ПДУФ >.

<    параметр доступа пи > : : =

(НОРМАЛЬНЫЙ | НОВЫЙ | СТАРЫЙ | ДОБАВИТЬ В КОНЕЦ (ДОБАВИТЬ )

<    список-имен > : : = 1< имя = S >|4L

<    указатель документа > : : =

(ВЛОЖЕННЫЙ | < указатель единичного документа >) (см. 3.4.4.1.3)

Эта форма параметра < блок документа > указывает, что документы, которые указаны в параметрах < указатель документа >, должны быть объединены (в порядке ссылок в блоке документа) для формирования одного документа при размещении при помощи примитива J-DISPOSE.

<    Параметр доступа пи > указывает требуемое действие агентства относительно существующего материала с таким же именем в принимающем или исполняющем агентстве, в которое он передается.

П ри меч анис — Этот параметр игнорируется исполняющим агентством.

Он передается как поле параметра примитива J-D1SPOSE. Литералы могут иметь следующие значения:

НОРМАЛЬНЫЙ - перезаписать какие-либо старые документы с тем же именем или создать новый документ в принимающем агентстве;

НОВЫЙ — создать новый документ в принимающем агентстве, если возможно, но если старый документ существует с таким же именем, вернуться в исходное состояние с выдачей диагностики;

СТАРЫЙ - перезаписать старый документ с тем же именем, но если старый документ не существует, вернуться в исходное состояние с выдачей диагностики;

ДОБАВИТЬ В КОНЕЦ — добавить в конец какого-либо прежнего документа, но если прежний документ не существует, вернуться в исходное состояние с выдачей диагностики;

ДОБАВИТЬ — добавить в конец какого-либо прежнего документа и. если прежний документ не существует, создать новый документ.

В начало значения < список-имен > добавляется < префикс пи > (см. 3.4.4.1.1) и затем формируется значение < список-имен >, передаваемое в примитиве J-DISPOSE в принимающее или исполняющее агентство для идентификации документа.

Литерал ВЛОЖЕННЫЙ указывает доку мент в < списке документов >. Количество документов в этом списке равно общему количеству имеющихся литералов ВЛОЖЕННЫЙ в СР (включая проформы). Между позициями в < списке документов > и синтаксисом передачи СР имеется определенное соответствие.

Если обеспечивается значение . принимающее агентство использует услуги РОСТ Р 34.1980.3 (ПДУФ) для размещения документа в локальном или удаленном хранилище файлов, как определено в ГОСТ Р 34.1980.3.

Параметр < указатель единичного документа > требует включения документа, который должен быгь получен при помощи примитива J-GIVE или ПДУФ. Это выполняется поставщиком услуг ПОЗ в форме ВЛОЖЕННЫЙ или вводится диагностика ошибок.

3.4.4.\.Ъ Указатели единичного документа и идентификация иеточника

<    указатель единичного документа > : ; =

<    действие открытой системы = N >

<    идентификация исходного агентства >

<    указатель источника документа >

<    встроенная диагностика >

<    состояние >

Страница 48

ГОСТ Р ИСО/МЭК 8831-99

<    идентификация исходного агентства > : : =

(ПОСТАВЩИК | < исходное агентство ПОЗ > | < исходное агентство ПДУФ >)

<    исходное агентство ПОЗ > : : = < имя исходного агентства = S >

<    дополнительные полномочия >

<    параметр агентства > (см. 3.4.4.1.1)

<    исходное агентство ПДУФ > : : = < имя-хранилища файлов = N >

<    указатель источника документа > :: =

(< ПОЗ читать-данные > | < ПДУФ читать-данные >)

<    1103 читать-данные > : : = < параметр доступа к исходному агентству >

< список-имен >

<    ПДУФ читать-данные > :: =

< «Читать спецификацию передачи» как определено в приложении L) ГОСТ Р 34.1980.3 >

Примечание — Фарма < ПДУФ читать-данные ПДУФ > используется только и том случае, если

<    идентификация исходного агентства > имеет форму < исходное агентство ПДУФ >.

<    параметр доступа к исходному агентству > : : =

(ПЕРЕМЕСТИТЬ) КОПИРОВАТЬ)

<    встроенная диагностика > :: = (ВЛОЖИТЬ ОШИБКА)

<    состояние > : : = (НЕТ ПОПЫТКИ | СБОЙ < информация об ошибке >)

<    информация об ошибке > : : = < отметка времени > (см. 3.3.2)

<    диагностика СИВ > (см. 3.3.3)

Параметр < действие открытой системы > указывает имя открытой системы, которая должна ввести примитив индикации J-G1VE (который может включить использование ПДУФ для получения документа). Он указывает открытую систему, создающую СР (порождением или в результате обработки примитива J-IN1T1ATE), целевую систему или одну из промежуточных систем.

Параметр < идентификация исходного агентства > имеет значение ПОСТАВЩИК, только в том случае, если указатель содержится в проформе, которая порождена в результате выполнения работы, управления передачами или отчетами. Он используется, чтобы указать документы, изготовленные поставщиком услуг в результате выполнения команды отображения.

Параметр < идентификация исходного агентства > имеет форму < исходное агентство ПОЗ > для исходных агентств, которые получают документ локально или нестандартным удаленным способа доступа. Форма < исходное агентство ПДУФ > определяет локальное исходное агентство, которое получает документ (локально или удаленно), используя ГОС Т Р 34.1980.3.

Параметр < имя исходного агентства > является строкой, определяемой параметром < открытая система действия > для явной идентификации исходного агентства (внутри такой открытой системы), для которого должен быть введен примитив J-GIVE, чтобы получить документ.

<    Параметр агентства > используется, чтобы определить, каким образом документ был сохранен. Если это поле несовместимо с любой информацией справочника, хранимой исходным агентством, то результатом будет диагностика ошибок (см. также 3.4.4.1.1).

Параметр < дополнительные полномочия > выполняет те же функции, которые служат для доступа к принимающим или исходным агентствам.

<    Параметр доступа к исходному агентству > передается как одно из полей в примитиве J-G1VE: если он имеет значение КОПИРОВАТЬ, исходное агентство не подвергается воздействию активности, если - значение ПЕРЕМЕСТИТЬ, документ помечается для удаления из исходного агентства при исполнении операций и остается неизменным при возврате в исходное состояние. Если этому исходному агентству доступны совмещенные активности (часть одного и того же элементарного действия), документ удаляется (если для какого-либо из них была совершена операция перемещения) при последующем исполнении или при возврате каждого из действий в исходное состояние.

<    Список-имен > передается в примитиве J-GIVE и идентифицирует указанный документ. Он указывает только один документ; если он отсутствует, то агентство, в которое был выдан примитив J-G1VE. возвращается в исходное состояние с диагностикой.

Параметр < имя-храннлиша-файлов > в форме < исходное агентство ПДУФ > идентифицирует (локальное или удаленное) виртуальное хранилище файлов ПДУФ. которое должно обеспечить документ. Вся другая информация, необходимая для получения документа, обеспечивается параметром < ПДУФ читать-данные >.

Страница 49

ГОСТ Р ИСО/МЭК 8831-99

Следует заметить, что при разрешении указателя единичного документа с использованием примитива J-GIVE обеспечивается также < тип документа > операции < перемещение документа >.

Параметр < встроенная диагностика > указывает действие, которое должно быть предпринято системой < открытая система действия >, если примитив J-GIVE подвергается операции возврата с диагностикой или если значением параметра < идентификация исходного агентства > является ПОСТАВЩИК, а указанный документ недоступен.

Значение ВЛОЖИ ТЬ требует, чтобы начальное значение НЕТ ПОПЫТКИ поля < состояние > было изменено на БЕЗУСПЕШНОСТЬ. Поле < отметка времени > содержит время безуспешного выполнения примитива J-GIVE. а диагностика примитива J-ROLLBACK помешается в поле

<    диагностика СИВ >. Обработка указателя документа предшествует предложению исполнения — возврат в исходное состояние из агентства недосту пен ГУЛО. Если основное действие предшествует исполнению, выполняется переход в < состояние >. Если это действие возврашается в первоначальное состояние (по другим причинам), то < состояние > возврашается в первоначальное. Это действие формирует событие ДИАГНОСТИКА, которое может быть выбрано для службы отчетности.

Значение ОШИБКА вызывает установку параметра < состояние > в значение НЕТ ПОПЫТКИ и распространяет возврат и диагностику вверх по дереву элементарных действий к ГУЛО. Последующее действие определяется значением поля < действие при ошибке > для полного ползадания (см. 3.4.3.4).

3.4.4.1.4 Блоки документов групповой формы

<    групповая форма > : : = < действие открытой системы = N >

<    структура пи документа >

<    встроенная диагностика >

<    исходное агентство ПОЗ > (см. 3.4.4.1.3)

<    дополнительные полномочия >

<    структура документа исходного агетгтва >

<    селектор документа >

<    селектор документа > : : = (НУЛЬ | < локальная строка = S >)

<    структура пи документа > : : = < параметр доступа к пи > (см. 3.4.4.1.2)

< частичный список-имен >

<    структура документа исходного агентства > : : =

<    параметр доступа к исходному агетству > (см. 3.4.4.1.3.)

<    частичный список-имен >

<    частичный список-имен > : : = |< имя = S >|* L

Поля < действие открытой системы >, < исходное агентство ПОЗ >, < дополнительные полномочия >, < встроенная диагностика >, < параметр досту па к пи > и < параметр доступа к исходному агентству > определены в 3.4.4.1.2 и 3.4.4.1.3.

Блок документов групповой формы используется для формирования одного или нескольких блоков документов единичной формы, каждый из которых содержит значение ВЛОЖЕННЫЙ параметра < указатель документа >.

Параметр < указатель пи документа > для полей < единичная форма > составляется из полей

<    сруктура пи документа > путем добавлении имен (достаточного количества) в конец списка

<    частичный список-имен >.

Документы принимаются системой < действие открытой системы > из исходного агентства, указанного параметром < идентификация исходного агентства >. Все они имеют один и тот же < тип документа >, указанный для операции < перемещение документа >. Параметр < указатель документа исходного агентства > для примитива J-GIVE для получения каждого документа формируется из полей < структура документа исходного агентства > добавлением имен (достаточного количества) в конец списка < частичный список-имен >. Это достаточное количество обеспечивается примитивом J-ENQUIRE.

Блок документа групповой формы обрабатывается системой < действие открытой системы >, при первой выдаче примитива J-ENQUIRE в исходное агентство путем передачи параметров <тии документа >, < структура документа исходного агентства > и < селектор документа >. Она выдает список суффиксов (список-имен) по одному имя для каждого документа, который должен быть доступен. Каждый из этих суффиксов (список имен) добавляется к списку < частичный список-имен > в параметре < структура пи документа > и < структура документа исходного агентства >. как

44

Страница 50

ГОСТ Р ИСО/МЭК 8831-99

определено выше. Множество списков (список-имен), выдаваемого примитивом J-ENQU1RE, является максимальным набором, для которого в результате выполнения примитивов J-GIVE могут быть сформированы документы в зависимости от использования параметров < селектор документа > и < тип документа >. Семантика параметра < локальная строка > не стандартизована. Значение НУЛЬ для параметра < селектор документа > означает максимальный выбор.

Примечание— В настоящее время Г1ДУФ не обеспечивает средств, необходимых для примитива J-ENQUIRE. поэтому блоки документов групповой формы ограничены локальным доступом.

Исходное агентство может использовать любую или всю приведенную ниже информацию, чтобы определить, какой из документов должен быть выбран:

a)    < частичный список-имен >;

b)    < тип документа >;

c)    < параметр агентства >;

d)    < параметр доступа к исходному агентству >;

e)    < пароль > из параметра < дополнительные полномочия >;

О < селектор документа >.

Разрешение этого указателя имеет особое использование, если совокупность документов впоследствии обрабатывается исполняющим агентством, те имена и количество документов могут быть неизвестны заранее и могут зависеть от степени успешности обработки или от того, прерывалась ли обработка операцией ОС ТАНОВ.

3.4.4.2 Операции выполнений работы

<    операции выполнения работы > : : = |< операция работы >)4 L

<    операция работы > : : =

(< операция выбора > | < операция уничтожения > |

<    операция останова > | < операция отображения работы > |

<    операция модификации > )

<    операция выбора > :: = ВЫБОР < селектор > (см. 3.4.4.2.I)

<    операция уничтожения > : : = УНИЧТОЖЕНИЕ

<    операция останова > : : = ОСТАНОВ

<    операция отображения работы > : : = ОТОБРАЖЕНИЕ < док-имя = S >

(< ПОЛНОЕ | КРАТКОЕ >)

<    операция модификации > : : = МОДИФИКАЦИЯ < обновление > (см. 3.4.4.2.4)

Операции выполнения работы приводит к тому, что целевая открытая система отображает или модифицирует определение СР, за которую она ответственна.

Операции УНИЧТОЖЕНИЕ. ОСТАНОВ и МОДИФИКАЦИЯ могут привести к тому, что поставщик услуг ПОЗ вводит примитивы индикации J-KILL. J-STOP, J-HOLD или J-RELEASE для соответствующих агентств, а операция ОТОБРАЖЕНИЕ приводит к выдаче примитива индикации J-STATUS д-i я соответствующих агентств.

Операция ВЫБОР выбирает одну или несколько СР или проформ для последующих операций. Она выполняет это тестированием значения полей в СР. используя литералы ПОЗ для указания подлежащих тестированию полей. Выбранные СР или проформы используются последующими операциями УНИЧТОЖЕНИЕ. ОСТАНОВ, МОДИФИКАЦИЯ и ОТОБРАЖЕНИЕ. Выбор действует до тех пор. пока не будет введена следующая операция ВЫБОР.

Операция УНИЧТОЖЕНИЕ приводит к появлению события ЗАВЕРШЕНИЕ-ОБРАБОТКИ подзаданий и предотвращает порождение в конце уничтожаемой активности. Она вырабатывает примитив J-K1LL или J-ROLLBACK для любого соответствующего агентства, возвращает в исходное состояние любую активность передачи и уничтожает соответствующую СР.

Операция ОСТАНОВ также приводит к выдаче примитива индикации J-STOP или J-ROLLBACK для соответствующих агентств, но не предотвращает порождение в конце активности и не приводит к завершению СР. Операция ОСТАНОВ возвращает в исходное состояние любую повторную попытку активности. Использование операции ОСТАНОВ указывается в любом сформированном отчете МОДИФИКАЦИЯ.

Операция МОДИФИКАЦИЯ вызывает изменения, которые должны быть выполнены для выбранной СР или проформы. Значение < обновление > вызывает изменения указанных полей; если изменяется поле < задержка >, результатом может быть выдача примитива индикации J-HOLD или J-RELEASE. Изменения в поле «состояние-удержания» отмечаются в любом сформированном отчете МОДИФИКАЦИЯ.

45

3— 1 — 1114»

Страница 51

ГОСТ Р ИСО/МЭК 8831-99

Операция ОТОБРАЖЕНИЕ вызывает копирование данных из выбранной СР или проформы вместе с информацией из примитива J-STATUS, которое должно быть выполнено, как часть документа < документ отображения работы > с именем < имя-док >. Поле < документ отображения работы > определено в 3.5.2.

СР может быть модифицирована только подзаданием выполнения работы, если это подзада-ние содержит < элемент полномочий > для аутентифицированного параметра < идентификация >. по которому допускается модификация данной СР.

Следующие аутентифицированные параметры < идентификация > допускаются для модификации СР:

a)    < идентификация >, который появляется в поле < разрешение > СР;

b)    уполномоченный по идентификации, один из параметров которого < идентификация > имеется в поле < разрешения > СР;

c)    открытая система, имя которой представлено как < целевая система > или < промежуточная система > для СР или ее проформ, или имя которой представлено в параметре < проверочная трасса > этой СР.

Кроме этого, удаление элемента < элемент задержки > или < элемент разрешения > может быть выполнено только при допустимом равенстве поля < идентификация > полю, представленному в < элементе удержания > (при его наличии) или < элементе разрешения >. или относящимся к нему, как указано в подпункте Ь). Если < элемент удержания > не содержит < разрешения освобождения >. то такое дополнительное ограничение не применяется.

После операции «ОТОБРАЖЕНИЕ < имя-док >» документ типа < документ отображения работы > является доступным для сборки при помощи ссылки на параметр < идентификация исходного агентства > со значением ПОСТАВЩИК и на параметр < список-имен >. содержащим только поле < имя-док>. Две операции отображения с одним и тем же значением < имя-док > выполняют оба отображения работы в одном и том же документе. Отображение может быть полным или кратким. как определено в 3.5.2.

3.4.4.2.1 Селекторы

<    селектор > : : = < форма селектора >

< тест заголовка >

<    форма селектора > : : = (СОДЕРЖИГ-ЗАГОЛОВОК | НЕ-СОДЕРЖИТ-ЗАГОЛОВКА |

ПЕРВЫЙ- ЗА РОЛ О ВОК- И М ЕЕ! СЯ | ЗАГОЛ О ВО К - И \1 Е ЕТСЯ)

<    тест заголовка > : : =    (< тест поля > | < предложение НЕТ > |

<    предложение И > | < предложение ИЛИ > |

УСПЕШНО | БЕЗУСПЕШНО)

<    предложение НЕТ    > : : =    НЕТ < тест заголовка    >

<    предложение И > :    : =    И < тест заголовка >    <    тест    заголовка    >

<    предложение ИЛИ    > : :    =    И < тест заголовка >    <    тест    заголовка    >

<    тест поля > : : =    < имя поля >

<    оператор выбора >

<    значение выбора >

Параметр < селектор > содержит серии тестов, применяемых для концептуальной структуры данных, называемых «список заголовков*, который содержит поля, соответствующие СР и ее проформам.

Поля этой структуры данных определены в 3.4.6.

Список заголовков содержит один или несколько заголовков. Каждый заголовок содержит поля, являющиеся глобальными в полном задании ВОС. вместе с полями, которые являются специфичными для подзадания ВОС, как указано СР или одной из ее проформ (на любом уровне вложенности) (см. 3.4.6).

Параметр < тест поля > применяется к поименованному полю в параметре < заголовок > и вызывает формирование значения УСПЕШНО или БЕЗУСПЕШНО. Значение параметров < тест поля > комбинируется операторами И, ИЛИ, НЕТ для получения значения УСПЕШНО или БЕЗУСПЕШНО для теста < тест заголовка >.

Проформа выбирается формой ЗАГОЛОВОК-ИМЕЕТСЯ только в том случае, если < тест заголовка > вызывает формирование значения УСПЕШНО при применении этого теста к заголовку, соответствующему данной проформе.

46

Страница 52

ГОСТ Р ИСО/МЭК 8831-99

Форма СОДЕРЖИТ-ЗАГОЛОВОК выбирает СР. которые содержат, по крайней мере, одну проформу (на любой глубине), соответствующую параметру < заголовок >, для которого успешно выполняется < тест заголовка >. Форма НЕ-СОДЕРЖИТ-ЗАГОЛОВКА вызывает выбор СР, для которых < тест заголовка > выполняется со сбоем для всех значений < заголовок >, соответствующих проформам в нем. Форма ПЕРВЫЙ-ЗАГОЛОВОК-ИМЕЕТСЯ вызывает выбор СР, для которых успешно выполняется < тест заголовка > для заголовка, соответствующего самой СР.

П р и м с ч а н н с - По значению ЗАГОЛОВОК-ИМЕЕТСЯ выбирается (указывается) С'Р или проформа. В последнем случае оно также неявно указывает СР. содержащую проформу, при использовании в ЗУ П. Формы СОДЕРЖИТ-ЗАГОЛОВОК. НЕ-СОДЕРЖИТ-ЗАГОЛОВКА и ПЕРВЫЙ-ЗАГОЛОВОК-ИМЕЕТСЯ всегда выбирают полную СР.

3.4.4.2.2    Операторы выбора

<    оператор выбора > : : =

(РАВНО! СОДЕРЖИМОЕ-СПИСКА |

ПЕРВЫЙ-И 3-СПИСКА-ИМЕЕТСЯ | ПОСЛ ЕДН И Й-И 3-СП ИСКА- И М ЕЕТСЯ |

БОЛЬШЕ ЧЕМ | БОЛЬШЕ ИЛИ РАВНО |

МЕНЬШЕ ЧЕМ | МЕНЬШЕ ИЛИ РАВНО)

Значение БОЛЬШЕ ЧЕМ. БОЛЬШЕ ИЛИ РАВНО. МЕНЬШЕ ЧЕМ и МЕНЬШЕ ИЛИ РАВНО параметра < оператор выбора > используется только с полями, которые являются цельночисленными элементами (ОБЩИЙ-РАЗМЕР и ВРЕМЯ-ОЖИДАНИЯ) (см. 3.4.6).

Значение РАВНО параметра < оператор выбора > может применяться к любому типу поля. Тестирование будет выполняться успешно только в том случае, если значение параметра < значение выбора > равно по типу и по значению этому полю (см. 3.4.4.2.3).

Три других значения параметра < оператор выбора > применяются к спискам: СОДЕРЖИМОЕ-СПИСКА может также применяться к совокупности. Тестирование выполняется успешно только в том случае, если < значение селектора > будет такого же типа, как и элемент поля < заголовок >, и будет соответствовать любому, первому или последнему элементу в списке.

В 3.4.6 определены операторы, которые могут быть применены к каждому полю заголовка.

3.4.4.2.3    Значения выбора

Поле < значение выбора > имеет такой же тип. как поле < заголовок >, соответствующее значению < имя поля >, за исключением операторов «список*, когда его тип является таким же. как и элемент списка полей < заголовок > или совокупности.

Для каждого синтаксического элемента (базового или структурированного типа данных) в поле < заголовок > литерал ЛЮБОЙ-ЭЛЕМЕНТ может использоваться в поле < значение выбора > вместо синтаксического элемента соответствующего типа. Это соответствует любому синтаксическому элементу любого типа.

3.4.4.2.4    О б н о в j е н и я

<    обновление > : : = < имя поля >

<    оператор обновления >

<    значение обновления >

Этот параметр обновляет одно поле выбранной проформы или СР в соответствии с параметрами < оператор обновления > и < значение обновления >. Если была выбрана полная СР. параметр < обновление > применяется к самой СР. относящейся к первому полю < заголовок > в параметре < список заголовков >.

3.4.4.2.5    Операторы обновления

<    оператор обновления > : : = (УСТАНОВИГЬ-В | УДАЛИТЬ I ДОБАВИТЬ)

Значения УДАЛИТЬ и ДОБАВИТЬ применяются только к совокупностям. Значение УСТАНОВИТЬ-В может применяться Д1Я любого типа поля. Операторы, которые могут применяться для каждого поля < заголовок >. приведены в 3.4.6.

3.4.4.2.6    Значения обновлений

Эти значения относятся к тому же типу, что и поле < заголовок >, соответствующее < имени-поля >, за исключением значений УДАЛИТЬ и ДОБАВИТЬ, когда они относятся к тому же типу, что и элемент поля заголовка. Если элемент добавляется к совокупности, которая уже содержит элемент, равный такому значению, совокупность не изменяется.

47

3-1*

Страница 53

ГОСТ Р ИСО/МЭК 8831-99

3.4.4.2.7 И меча полей

<    имя-поля > : : = (ВОС-СИСТЕМЛ-ПРЕДОСТАВЛЕНИЯ-ЗЛДАНИЯ |

ВОС-ИМЯ-ЗАДАНИЯ | ТИП-ПОДЗАДАНИЯ | ИНИЦИАТОР | ВОС-ЛОКАЛЬНЫЙ-УКАЗАТЕЛЬ-ЗАДАНИЯ | ПЕРВИЧНЫЙ-МОНИТОР | ВГОРИЧНЫЕ-МОНИГОРЫ I ПАРАМЕТРЫ-ЗАЩИТЫ | УСТАНОВКА-ПОЛНОМОЧИЙ I УСТАНОВКА-УЧЕТА | УСТАНОВКА-РАЗРЕШЕНИЯ | СПИСОК-ИМЕН-ПОДЗАДАНИЯ | ПРОМЕЖУТОЧНЫЕ СИСТЕМЫ | ЦЕЛЕВАЯ СИСТЕМА |

ПИ-СПИСКИ | ПИ-СПИСКИ-УКАЗАТЕЛЕЙ |

СГ1ИСКИ-ИСХОДНОГО АГЕНТСТВА I

СП ИСКИ-УКАЗАТЕЛЕЙ-ИСХОДНОГО АГЕНТСТВА I СРОЧНОСТЬ | ДЕРЖАНИЯ | ДЕЙСТВИЕ-ПРИ-ОШИБКЕ | ВРЕМЯ-ОЖИДАНИЯ ОБЩИЙ РАЗМЕР)

Тип каждого поля заголовка, соответствующего этим именам полей, значения их содержимого и разрешенные операции приведены в 3.4.6.

3.4.4.3 Операции управления передачами

<    операция управления передачей >:: = (< операция установки > I

<    операция проверки > |

<    операция отображения передачи >)

<    операция установки > : : = УСТАНОВКА

<    установить системой = N >

<    получатель = N >

<управляющая спецификация > (см. 3.4.7)

<    операция проверки > : : = ПРОВЕРКА

<    проверить системой = N > (см. 3.4.2.1)

<    получатель = N >

<    управляющая спецификация > (см. 3.4.7)

<    операция отображения передачи > : : = ОТОБРАЖЕНИЕ

(< пункт назначения > | ВСЕ)

<    имя документа = S >

Операция УСТАНОВКА устанавливает параметр < запись управления передачей > (см. 3.4.7) в указанное значение. Она обычно вызывается САУ той стороны, которая знает, что она явлется постоянным получателем СР некоторой другой стороны, и желает управлять такими передачами. Она выполняет это. установив ЗУП на передающей стороне. СР должна иметь уполномоченного по

<    идентификации > открытой системы, указанной в полях < получатель > и < установить системой >. Поле < установить системой > используется только для того, чтобы определить ту открытую систему, в которую должна быть послана последующая операция ПРОВЕРКА. Поле < установить системой > содержит имя открытой системы. САУ которой была определена так. чтобы конкретный путь передачи был управляемым. Обычно оно должно быть идентично полю < получатель >, но может и отличаться от него. Поле < получатель > содержит имя такой открытой системы, передачи к которой должны быть управляемыми. Эта операция устанаатвает параметр < управляющая спецификация > для управления передачами к системе < получатель >.

Операция ПРОВЕРКА обеспечивает данные (< получатель > и < управляющая спецификация > при использовании в открытой системе, указанной параметром < проверить системой >, и запрашивает открыту ю систему, в которую операция ПРОВЕРКА посылается для того, чтобы создать СР управления передачами, если конкретное значение данных больше не пригодно. Эта операция предохраняет от бесконечно долгого использования несоответствующих ЗУП.

П р и м с ч а н и с - Рекомендуется, чтобы открытые системы посылали запрос на выполнение операции ПРОВЕРКА и открытую систему, указанную параметром < установить системой >, если они были отсоединены от функциональной среды открытых систем на некоторое время.

Операция ПРОВЕРКА требует наличия уполномоченного по < идентификаций > открытой системы, указанной параметром < проверить системой >.

Операция ОТОБРАЖЕНИЕ передачи формирует параметр < документ отображения передачи > (см. 3.5.3), содержащий копию полей < управляющая спецификация > и < установить системой>

48

Страница 54

ГОСТ Р ИСО/МЭК 8831-99

для указанного значения < получатель'?. Использование значения ВСЕ отображает ЗУП для всех элементов < получатель >. не имеющих значения НЕУПРАВЛЯЕМЫЙ (см. 3.4.7).

3.4.4.4 Операции управления отчетами

<    операции управления отчетами > : : =

(< операция удаления > | < операция ПОЗ-отображение-отчета >

<    операция удаления > : : = УДАЛЕНИЕ < выбор отчета >

<    операция ПОЗ-отображение-отчета > : : =

ОТОБРАЖЕНИЕ < выбор отчета >

<    имя документа = S >

<    выбор отчета > : : =

<    ограничение системы предоставления задания >

<    ограничение инициирующего агентства >

<    ограничение указателя >

<    ограничение имени задания >

<    ограничение подзадания >

<    ограничение типа >

<    ограничение события >

<    ограничение времени-инициирования >

<    ограничение системы предоставления задания > : : =

(НУЛЬ I < система предоставления задания ВОС >) (см. 3.4.4.2.7)

<    ограничение инициирующего агентства > : : =

(НУЛЬ | < идентификация инициирования >) (см. 3.4.2.1)

<    ограничение указателя > : : =

(НУЛЬ I < локальный указатель задания ВОС = S >) (см. 3.4.6)

<    ограничение имени задания > : : =

(НУЛЬ | < имя задания ВОС = S >) (см. 3.4.2)

<    ограничение подзадания > : : =

(НУЛЬ | < список-имен-подзаданий >) (см. 3.4.3)

<    ограничение типа > :: = (НУЛЬ | < тип подзадания >) (см. 3.4.3.3)

<    ограничение события > :: = (НУЛЬ | < селектор отчета >) (см. 3.4.2.2)

<    ограничение времени-инициирования? : : = (НУЛЬ I < время >)

<    время > : : = < время начала >

< время завершения >

<    время начала > : : = (НУЛЬ | < дата-время = S >)

<    время завершения > : : = (НУЛЬ | < дата-время = S >)

Параметр < выбор отчета > указывают все имеющиеся отчеты из подзаданий (или порожденных подзаданий):

a)    < система предоставления задания ВОС > (если обеспечивается);

b)    < локальный указатель задания ВОС > (если обеспечивается);

c)    < идентификация инициирования > (если обеспечивается);

d)    < имя задания ВОС > (если обеспечивается);

e)    < имя проформы > и < классифицированное целое число > (если обеспечивается);

О < тип подзадания > (если обеспечивается);

g)    тип события, который указан в параметре < селектор отчетов > (если обеспечивается);

h)    < время инициирования > между < временем начала > и < временем завершения > (если обеспечивается < ограничение времени-инициирования >).

Операция УДАЛЕНИЕ удаляет эти отчеты, операция ОТОБРАЖЕНИЕ отображает их как документ «ПОЗ-отображение-отчета» (см. 3.5.1). Операция УДАЛЕНИЕ требует наличия уполномоченного по < идентификации >, соответствующего параметра < элемент разрешения >, представленного в СР. о которой должен быть выдан отчет. Тип документа «ПОЗ-отображение-отчета* приведен в 3.5.1.

Уведомление, в котором < время начала > равно НУЛЮ, включается параметром < ограничение времени-инициирования > только в том случае, если одно из значений < время начала > и

<    время завершения > равно НУЛЮ.

49

3-2- IIMM

Страница 55

ГОСТ Р ИСО/МЭК 8831-99

3.4.4.5    Операции перемещения отчета

<    операции перемещения отчетов> : : = |< операция отчета >)*С

<    операция отчета > :: = |< индекс монитора = I >)♦€

< отчет > (см. 3.3.2)

Каждый параметр < операция отчета> вызывает обработку одного отчета (при достижении целевой системы), как указано спецификацией монитора, идентифицируемой индексом монитора. Значение «нуль» указывает первичный монитор, а значения «один*, «два» и т. д. — последующие вторичные мониторы в списке вторичных мониторов СР.

3.4.5    Проформы

<    проформа > : : =

<    имя проформы = S >

<    данные управления порождением > (см. 3.4.5.2)

\< обработка запроса порождения >|*С

(< указатель проформы > I (см. 3.4.5.1)

<    спецификация проформы >)

<    число порождений = I >

<    спецификация проформы > : : =

<    спецификация подзадания > (см. 3.4.1)

<    список проформ > (см. 3.4.1)

В базовом классе содержимое поля < список проформ > в параметре < спецификация проформы > полностью прозрачно и на него не налагаются ограничения базового класса.

Поля параметра < проформа > такие же, как и поля проформы верхнего уровня, определенные в 3.4.1. Они определяют параметры для подзадания. которое должно быть создано при порождении проформы.

Поле < имя проформы > однозначно указывает параметр < проформа > в содержимом поля

<    список проформ >. Проформа, указанная параметром < проформа >, содержащая < список проформ >. называется порождающей для данного < списка проформ >. Проформа, указанная параметром < проформа >. которая не содержится ни в какой другой проформе, называется проформой верхнего уровня.

Параметр < число порождений > содержит счетчик СР, порождаемых из этой проформы. Поскольку порождение происходит только в целевой системе, этот параметр неявно обнуляется во время передачи. 'Это используется для формирования параметра < список имен иодзаданнй > при порождении новой СР из проформы.

Строки < обработка запроса порождения > указывает, должна ли проформа порождаться группой СП J-SPAWN. Проформа порождается, если параметр < обработка запроса порождения > примитива запроса J-SPAWN равен одной из строк в комбинации < обработка запроса порождения > проформы. Если комбинация < обработка запроса порождения > пустая или отсутствует, проформа не может быть порождена запросом.

3.4.5.1 Указатели проформы

<    указатель проформы > : : = < имя проформы = S > (см. 3.4.5)

'Это поле используется для указания параметра < спецификация подзадания > в поименованной проформе, указанной параметром < проформа >. Требуется, чтобы эта < проформа > находилась в том же списке < список проформ >, что и порождающая < проформа >; она сама может быть порождающей. Когда происходит порождение, то в проформах верхнего уровня в новой СР параметр < указатель проформы > заменяется параметром < спецификация подзадания > в этой поименованной проформе, указанной параметром < проформа >. (Следует заметить, что сюда может относиться проформа, содержащая параметр < указатель проформы >).

3.4.5.2. Данные управления порождением

<    данные управления порождением > : : =

(ТОЛЬКО ЗАПРОС | ПРИНЯТИЕ I ЗАВЕРШЕНИЕ | УСЛОВНЫЙ)

Это поле указывает, когда должно происходить порождение из проформы, указанной параметром < проформа >.

Если оно имеет значение ТОЛЬКО ЗАПРОС, порождение происходит только при введении группы СП J-SPAWN из активности в исполняющем агентстве, выполняемой порождающим под задан нем.

50

Страница 56

ГОСТ Р ИСО/МЭК 8831-99

Если оно указывает значение ПРИНЯТИЕ, порождение происходит, когда все принимающие и исполняющие агентства порождающего подзадания заданы с уровнем исполнения операций ПРИНЯТИЕ или ЗАВЕРШЕНИЕ.

Если оно указывает значение ЗАВЕРШЕНИЕ, подзадание создается, только в том случае, если все принимающие или исполняющие агентства порождающего подзадання заданы уровнем исполнения операций ЗАВЕРШЕНИЕ или когда введен примитив запроса J-END-SIGNAL.

Если оно указывает значение УСЛОВНЫЙ, подзадание создается как для значения ЗАВЕРШЕНИЕ. но только если по решению указателя исходного агентства последующее порождение собирает, по крайней мере, один документ из исполняющего или исходного агентства в данной открытой системе.

Примечание — Эта возможность предусматривается для обеспечения ситуации, когда обработка может выдать несколько выходных данных для различных адресатов. но также может выдат ь и меньшее количество данных, чем требуется. Использование значения УСЛОВНЫЙ гарантирует, что проформы порождаются только для таких адресатов, ятя которых выходные данные были действительно выработаны.

Все типы порождения могут осуществляться либо как часть начального элементарного действия, либо как часть последующего элементарного действия.

Уровень исполнения для запрошенного порождения указывается в примитиве запроса J-SPAWN. Для всех других порождений используется уровень ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА, если порождение не является частью начального элементарного действия.

Если в результате одного события должны быть порождены несколько проформ (например, по примитиву запроса J-END-SIGNAL), они порождаются в порядке их появления в списке < список проформ >.

Любые примитивы J-GIVE. которые должны быть введены из локальной области в агентство, выполняющее порождение, должны предшествовать предложению исполнения до порождения следующей проформы. (Это гарантирует, что операция ПЕРЕМЕЩЕНИЕ, допускаемая некоторыми проформами для объединения поименованных документов, и последующее порождение проформы со значением УСЛОВНЫЙ для объединения всех оставшихся документов, будет продолжаться правильно).

3.4.6 Списки заголовков

<    список заголовков >: := |< заголовок >|*L

<    заголовок > : : =

<    система предоставления задания ВОС = N >

(см. 3.3.2) (см. 3.3.2) (см. 3.3.2) (см. 3.4.2) (см. 3.4.2) (см. 3.4.2) (см. 3.4.2) (см. 3.4.2) (см. 3.4.2) (см. 3.4.2) (см. 3.4.3) (см. 3.4.3) (см. 3.4.3) (см. 3.4.3.!) (см. 3.4.3.2) (см. 3.4.3.3)

<    идентификация инициирования >

<    имя задания ВОС = S >

<    локальный указатель задания ВОС = S >

<    проверочная трасса >

<    первичная контролирующая спецификация >

<    вторичная контролирующая спецификация >

<    полномочия >

<    разрешения >

<    учет >

<    параметры зашиты = R >

<    список имен подзаданий >

<    промежуточные системы >

<    целевая система = N >

<    срочность >

<    удержания >

<    тип подзадания >

<    списки пи >

<    списки указателей пи >

<    списки исходных агентств >

<    списки указателей исходных агентств >

(см. 3.4.3.4) (см. 3.4.1) (см. 3.4.!)

<    действие при ошибке >

<    время ожидания = 1 >

<    подсчитанный размер = I >

51

3-2*

Страница 57

ГОСТ Р ИСО/МЭК 8831-99

<    списки пи >::=|< идентификация пи >|* L    (см. 3.4.4.1.1)

<    списки указателей пи >:: = (< указатель пн документа >1*L    (см. 3.4.4.1.2)

<    списки исходных агентств > : : =

|< идентификация исходного агентства >J+L    (см. 3.4.4.1.3)

<    списки указателей исходных агентств > :: =

|< указатель источника документов >|*L    (см. 3.4.4.1.3)

Эти поля соответствуют полям в СР или проформе. Изменение полей в списке < список заголовков > изменяет соответствующую СР или проформу.

Первый < заголовок > содержит поля, соответствующие полям < параметры задания ВОС > и

<    спецификация подзадания > в самой СР. Последующие заголовки содержат поля, соответствующие полям < параметры задания ВОС > и < спецификация подзадания > проформы с одним заголовком для каждой проформы (на любой глубине).

Примечание — Порядок последующих заголовков не указывается и не воздействует на результат какой-либо операции.

Значение < пароль > в параметре < указатель пи документа > и значение < секретные данные > в поле < поле доступа > < элемента полномочий > или < элемента учета > всегда появляется как элемент НУЛЬ в поле < заголовок >.

Семантика полей < заголовок > и операции в них определяются ниже. Поля, отмеченные знаком +, имеют одно и то же значение во псех полях < заголовок > соответствующего < списка заголовков >, т. е. они относятся ко всему заданию ВОС. Эти поля могут быть модифицированы при помощи выбора какого-либо заголовка из списка заголовков, и тогда измененные значения появляются во всех заголовках.

♦    < система предоставления задания ВОС > — см. 3.3.2. Может применяться только значение РАВНО.

♦    < идентификации инициирования > — см. 3.3.2. Может применяться только значение РАВНО.

♦    < имя задания ВОС > — см. 3.3.2. Может применяться только значение РАВНО.

♦    < локальный указатель задания ВОС > — см. 3.3.2. Может применяться только значение РАВНО.

♦    < проверочная трасса > - см. 3.4.2. Операции РАВНО. СОДЕРЖИМОЕ-СПИСКА, НЕРВЫ Й - И 3-С Г1И С КА- И М Е ЕТСЯ. П ОСЛ ЕД Н И И - И З-СП И СКА- И М ЕЕТСЯ.

♦    < первичная контролирующая спецификация - см. 3.4.2. Операции РАВНО и УСТАНОВИТЬ-В. Значение УСТАНОВИТЬ-В требует наличия полномочий для параметр;! < идентификация > системы предоставления задания ВОС.

♦    < вторичная контролирующая спецификация > — см. 3.4.2. Операции РАВНО, СОДЕРЖИМОЕ-СПИСКА. УСТАНОВИТЬ-В. УДА1ЕНИЕ и ДОБАВЛЕНИЕ. В случае СР отчетов разрешенными операциями являются только РАВНО и СОДЕРЖИМОЕ-СПИСКА.

♦    < полномочия > — см. 3.4.2. (Следует заметить, что все < секретные данные > в полях < поле доступа > появляются как значение НУЛЬ в полях < заголовок >). Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА и ДОБАВЛЕНИЕ. (Параметр < доступ >, содержащий проверяемый индекс, не может появиться в операции ДОБАВЛЕНИЕ.

♦    < разрешения > — см. 3.4.2. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА, ДОБАВЛЕНИЕ, УДАЛЕНИЕ. Операция УДАЛЕНИЕ требует наличия полномочий на удаление.

♦    < учет > - см. 3.4.2. (Следует заметить, что < секретные данные > в полях < поле доступа > представлены как значение НУЛЬ в полях < заголовок >). Операциями яапяются РАВНО, СОДЕРЖИМОЕ-СПИСКА и ДОБАВЛЕНИЕ. (Параметр < доступ >, содержащий проверяемый индекс, не может иметь место в операции ДОБАВЛЕНИЕ).

♦    < параметры зашиты > — см. 3.4.2. Может применяться только значение РАВНО.

< список имен подзаданнй > — см. 3.4.3 для первого заголовка. В заголовке для проформы это поле имеет ряд компонентов имен подзаданнй, по одному компоненту для каждого имени проформы, используемого для доступа к ней. Первым компонентом является имя проформы верхнего уровня примитива запроса J-1N1T1ATE, последней — имя данной проформы. Значением параметра

<    классификационное целое число > является НУЛЬ, если спецификация подзадания все еше находится в виде проформы. Могут применяться только операции РАВНО и ПЕРВЫЙ-ИЗ-СПИСКА-ИМ ЕЕТСЯ.

Страница 58

ГОСТ Р ИСО/МЭК 8831-99

<    промежуточные системы > — см. 3.4.3. Операциями являются РАВНО. СОДЕРЖИМОЕ-СПИСКА. ПЕРВЫЙ-ИЗ-СПИСКА-ИМЕЕТСЯ. ПОСЛЕДНИЙ-ИЗ-СПИСКА-ИМЕЕТСЯ. УСТАНОВКА-В.

<    целевая система > — см. 3.4.3. Операциями являются РАВНО и УСТАНОВКА-В.

<    срочность > — см. 3.4.3.1. Операциями являются РАВНО и УСТАНОВКА-В. Операция УСТАНОВКА-В требует аутентифицированного параметра < идентификация >, равного системе предоставления задания ВОС.

<    удержания > — см. 3.4.3.2. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА. УС-ТЛНОВКА-В. УДАЛЕНИЕ, ДОБАВЛЕНИЕ. Операция УДАЛЕНИЕ требует наличия уполномоченного для параметра <. идентификация > представленного в < элементе удержания >, или для своего параметра < уполномоченный >, или для параметра < открытая система >. поименованной в одной из систем < целевая система > или < промежуточная система >.

<тип подзадания > — см. 3.4.3.3. Единственная операция — РАВНО.

<    списки пи > — содержит все параметры < идентификация пи >, представленные в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров < идентификация пи >. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА. УСТАНОВКА-В.

<    списки указателей пн > — содержит все ссылки < указатель пи документа >. представленных в параметрах < блок документа > в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров < указатель пи документа >. Следует заметить, что поле < пароль > всегда имеет значение НУЛЬ. Операциями являются РАВНО, СОДЕРЖИМОЕ-СПИСКА. УСТАНОВКА-В.

<    списки исходных агентств > — содержит все параметры < идентификация исходного агентства >, имеющиеся в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество параметров < идентификация исходного агентства >. Операциями являются РАВНО. СОДЕРЖИМОЕ-СПИСКА. УСТАНОВКА-В.

<    списки указателей исходных агентств > — содержит все параметры <указатель источника документа > и < структура исходного агентства документа >. расположенные в полях < блок документа > в спецификации подзадания в порядке их появления. Требуется, чтобы при любом изменении сохранялось одно и то же количество элементов в списке. Следует заметить, что поле < пароль > всегда имеет значение НУЛЬ. Операциями являются РАВНО. СОДЕРЖИМОЕ-СПИСКА. УСТАНОВКА-В.

<    действие при ошибке > — см. 3.4.3.4. Операциями являются РАВНО, и УСТАНОВКА-В.

*    < время ожидания > — см. 3.4.!. Допустимы только операции РАВНО. БОЛЬШЕ ЧЕМ, БОЛЬШЕ ИЛИ РАВНО. МЕНЬШЕ ЧЕМ. МЕНЬШЕ ИЛИ РАВНО.

*    < общий размер> — см. 3.4.1. Равно нулю, если только не ожидается передача СР. Допустимы только операции РАВНО, БОЛЬШЕ ЧЕМ. БОЛЬШЕ ИЛИ РАВНО. МЕНЬШЕ ЧЕМ, МЕНЬШЕ ИЛИ РАВНО.

3.4.7 Записи управления передачей

Открытая система может содержал» одну или несколько ЗУП, при помощи которых определяется маршрут, по которому открытая система передает СР в другие открытые системы.

Каждая ЗУП в открытой системе устанавливается, чтобы управлять передачей СР в указанную открытую систему. Она дает возможность получателю СР влиять на совмещенность выполнения действий и приоритет для передачи СР посылающей системой.

<    запись управления передачей > : : = < установить системой = N >

<    отметка времени > (см. 3.3.2)

<    получатель = N >

<    управляющая спецификация >

<    управляющая спецификация > : : = (НЕУПРАВЛЯЕМЫЙ | < выбор >)

<    выбор >:: = |< селектор >|*L (см. 3.4.4.2.1)

Первоначально все ЗУП, хранящиеся открытой системой, устанавливаются в значение НЕУПРАВЛЯЕМЫЙ. В этом случае открытая система будет делать попытки передачи с совмещением выполнения действий, определяемым локально. Она может принять любой алгоритм для выбора СР при передаче. (Атгоритмы будут обычно использовать некоторые комбинации типа «первым обслуживается самый ранний запрос», «первым обслуживается наименьший запрос» и «первым обслуживается запрос с наивысшим параметром < срочность >»).

53

Страница 59

ГОСТ Р ИСО/МЭК 8831-99

Если значение этого параметра НЕУПРАВЛЯЕМЫЙ, то параметры < установка системой > и

<    отметка времени > не записываются. Параметр < отметка времени > показывает время выполнения операции УСТАНОВКА.

Если значение этого параметра отличается от НЕУПРАВЛЯЕМЫЙ, то параметр < выбор > используется не только для определения таких СР. которые могут вызывать осуществление попыток передачи, но также для управления степенью совмещенности действий. Если список < выбор > пустой, только СР управления передачами вызывает передачи. Передачи всегда разрешаются, но они не позволяют реализовать совмещенность выполнения действии, устанавливаемую параметром

<    выбор >. которая превышает одно действие.

Попытка передачи СР агентству < получатель > не предпринимается, если только каждая СР (при ее наличии) еше не передана этому получателю, а СР, которая должна быть передана, выбрана другим параметром < селектор > в списке < выбор >.

Примечание — Это означает, что каждый селектор допускает одновременную передачу нескольких СР. В параметре < выбор > может быгь несколько идентичных параметров < селектор >. Там, где более одной СР соответствуют параметру < селектор >. выбор СР для передачи является локальным делом PC (см. 3.4.3.1).

3.5 Документы ПОЗ

Этот раздел определяет семантику документов, содержащих отображения отчетов ПОЗ, отображения работы ПОЗ и отображения-ПОЗ-ЗУП. Синтаксис передачи для этих документов указывается в спецификации протокола ПОЗ.

Документы могут формировать часть СР и параметры примитивов J-GIVE и J-DISPOSE.

3.5.1.    Д о к у м е н т «отображение-отчета* ПОЗ

<    документ ПОЗ-отображепие-отчета > : : =

|< ПОЗ-отображение-отчета >|* L

<    ПОЗ-отображение-отчета > : : =

<    система монитора задания В ОС = N >

<    отметка времени > (см. 3.3.2)

1< отчет >|* L (см. 3.3.2)

Если эти документы сформированы ПОЗ. они содержат только один параметр < ПОЗ-отображение-отчета >. Обьединение этих документов составляет список < ПОЗ-отображение-отчета >.

Если такие документы формируются в результате управления отчетами, выбранные отчеты вносятся в список в порядке получения их системой монитора задания ВОС. чтобы обеспечит!» список < отчет > для параметра < ПОЗ-отображение-отчета >. Параметр < отметка времени > пред-сгавляет дату и время выполнения отображения.

Если такие документы формируются пунктом монитора при использовании примитива J-DISPOSE, чтобы разместить < отчет > в соответствии с параметром < данные размещения >, то

<    отметка времени > содержит время создания документа пунктом монитора, и в подзаданни типа ПЕРЕМЕЩЕНИЕ-ОТЧЕТА имеется один параметр < ПОЗ-отображение-отчета >. содержащий все представленные отчеты.

Этот тип документа указывается значением ОписательОбьекта АСН .1 (см. ГОСТ 34.973) параметра «-ПОЗ-отображение-отчета» и значением ИДЕНТИФИКАТОР ОБЪЕКТА АСН.1. которое указано в ГОСТ I’ ИСО/МЭК 8832.

3.5.2.    Документ «отображение-работы* ПОЗ

<    документ отображения работы > : : = |< отображение работы >}• L

<    отображение работы > : : = < система отображения = N >

< отметка времени > (см. 3.3.2)

|< отображение спецификации работы >]• L

<    отображение спецификации работы > : : =

(< полное отображение > | < краткое отображение >)

<    полное отображение > : : =

< список заголовков > (см. 3.4.6)

|< состояние системы назначения >|* С

<    состояние системы назначения > : : = < система назначения >

<    состояние >

<    отметка времени > (см. 3.3.2)

|< текст = S >1* L

<    диагностика СИВ >

Страница 60

ГОСТ Р ИСО/МЭК 8831-99

<    система назначения > : : =

(< получатель = N > | < исходное агентство > | < пи агентство >)

<    исходное агентство >:: = (< имя источника = S > |

< имя хранилища файлов = N >) (см. 3.4.4.1.3)

<    пи агентство >:: = (< имя пи = S > |

< имя-хранилиша-файлов = N >) (см. 3.4.4.1.1)

<    состояние > : : = (ВЫПОЛНЯЕТСЯ) | ПРИНЯТО | ОЖИДАНИЕ)

<    краткое отображение > :; = < идентификация подзадання > (см. 3.3.2)

|< состояние системы назначения >|*С Иоле < отметка времени > в параметре < отображение работы > представляет время выполнения отображения.

Поле < список заголовков > в параметре < полное отображение > содержит заголовки для выбранного ползадания и для всех проформ, содержащихся в нем.

Параметр < состояние системы назначения > содержит информацию об агентствах или передачах. связанных с СР. Поле < отметка времени > в параметре < состояние системы назначения > указывает время введения этого состояния.

Параметр < диагностика СИВ > содержит последнюю принятую диагностику «повторить-поз-же» и отсутствует, если значение параметра < состояние > не ОЖИДАНИЕ.

Форма < имя-хранилища-файлов > используется для агентств, которые получают или размешают документы, используя ПДУФ. В противном случае используются формы параметров < имя источника > и < имя пи >.

Значение ВЫПОЛНЯЕТСЯ означает, что в настоящее время выполняется элементарное действие. Поставщик услуг ПОЗ формирует < текст >, который содержит читабельную нестандартизо-ванную информацию.

Значение ПРИНЯТО означает, что агентством было выдано сообщение об исполнении по приему информации. Список текстов получается при помощи примитива J-STATUS, который выдает читабельную нестандартную информацию.

Значение ОЖИДАНИЕ означает, что ресурсы недоступны, получен результат диагностики «повторить-позже* или ЗУП препятствует выполнению. Поставщик услуг ПОЗ формирует список текстов, который содержит читабельную не стандартную информацию.

Объединение этих документов создает новый список отображений работы.

Тип этого документа указывается значением ОписательОбьекта АСН.1 (см. ГОСТ 34.973) параметра «документ ПОЗ-отображение-работы» и значением ИДЕНТИФИКАТОР ОБЪЕКТА АСН.1, которое указывается в ГОСТ ИСО/МЭК 8832.

3.5.3 Документ «о т о б р а ж е н и е-3 У П» И О 3

<    документ отображения передачи > : : = |< отображение передачи >)• L

<    отображение передачи > : : =

<    система отображения = N >

<    отметка времени > (см. 3.3.2)

<    запись упраатення передачей >|* L (см. 3.4.7)

Значение параметра < отметка времени > представляет время, в которое выполнено отображение.

Объединение этих документов создает новый список < отображение передач >.

Тип этого документа указывается значением ОписателъОбъекта АСН.1 (см. ГОСТ 34.973) параметра *ПОЗ-отображение-докумеита-ЗУП» и значением ИДЕНТИФИКАТОР ОБЪЕКТА АСН.1, которое указывается в расширенной спецификации протокола ПОЗ.

3.6 Параметры сервисных примитивов ПОЗ

3.6.1 П р и м и т и в ы запроса и подтверждения J-IN1T1ATE Примитив запроса J-INIT1ATE содержит следующие поля СР:

< идентификация инициирования >    (см. 3.3.2)

< имя задания ВОС >    (см. 3.3.2)

|< вторичная контролирующая спецификация >|* L (см.    п. 3.4.2)

<    полномочия >    (см.    3.4.2)

<    разрешения >    (см.    3.4.2)

<    учет >    (см.    3.4.2)

<    параметры защиты    >    (см.    3.4.2)

55

Страница 61

ГОСТ Р ИСО/МЭК 8831-99

<    спецификация подзадания >    (см.    3.4.1)

<    список проформ >    (см.    3.4.1)

<    список документов >    (см.    3.4.1)

Они полностью определяют работу, которая должна быть выполнена.

Примитив подтверждения J-1N1T1ATE содержит только один параметр < локальный указатель задания ВОС = S >.

Такая строка формируется в системе предоставления задания ВОС для явной идентификации такого использования примитива J-IN1TIATE в данной открытой системе. Желательно, чтобы локальное представление данных и времени введения примитива было соответствующими, но может использоваться любая другая явная строка.

Уровень исполнения и параметры СИВ указателя кода диагностики (представленные примитивом J-BEGIN) выбираются при помощи введения примитива запроса J-INIT1ATE.

Диагностика СИВ и информация учета может быть выдана пользователю в других параметрах, относящихся к СИВ.

3.6.2 Сервисные примитивы J-D1SPOSE 3.6.2.1 Примитив ипОикаиии J-DISPOSE

Вводится системой < целевая система > СР в принимающее или исполняющее агентство, указанное полем < имя пи = S > для формы < пи ПОЗ >, и в локальное принимающее агентство, осуществляющее доступ к ПДУФ для формы < принимающее агентство ПДУФ >.

Содержит следующие параметры:

<    идентификатор активности поставщика = S >

<    полномочие пользователя >

<    счет пользователя >

<    дополнительные полномочия >    (см. 3.4.4.

1.1)

1.1)

12)

(< имя-хранилнша-файлов = N > |

<    параметр агентства >)    (см. 3.4.4.

<    указатель пи документа >    (см. 3.4.4.

<    ошибки >

<    документ размещения >

<    ошибки >:: = |< диагностическая информация >|* L

(см. 3.3.3)

(см. 3.3.2) (см. 3.4.2.1)

(см. 3.3.2) (см. 3.4.2.1)

<    полномочие пользователя > : : = (НЕИЗВЕСТНЫЙ) |

<    идентификация > |

<    элемент полномочий >)

<    счет пользователя > : : = (НЕИЗВЕСТНЫЙ) |

<    идентификация > I

<    элемент учета >)

<    документ размещения > : : = < тип документа = ND >

< документ = D >

Параметр < идентификатор активности поставщика > представляет локальную информацию, необходимую для идентификации активности последующих групп примитивов, используемых агентством (таких, как J-END-SIGNAL. J-MESSAGE и т. д.). Его форма не стандартизована.

Примечание — Если агентство и поставщик являются частью одной и той же открытой системы, то параметр < идентификатор активности поставщика > является прозрачным в функциональной среде ВОС.

Параметры < полномочие пользователя > и < счет пользователя > получаются из полей

<    элемент полномочий > и < элемент учета >. Они проверяются поставщиком услуг 1103, если только обеспечивается параметр < идентификация >, в противном случае обеспечивается полный параметр < элемент полномочий > или < элемент учета >. Выбор параметра < элемент полномочий >. подлежащего использованию для примитива J-DISPOSE, выполняется локальной директивной функцией, использующей имя принимающего или исполняющего агентства и имя уполномоченного по идентификации пользователя в параметре < элемент полномочий >. Значение НЕИЗВЕСТНЫЙ указывает на невозможность отыскания соответствующего элемента полномочий, что часто является причиной возврата в исходное состояние агентства.

Однако в некоторых случаях параметр < дополнительные полномочия > или данные в самом документе могут быть достаточными, чтобы предоставить возможность выполняться этой активности.

Страница 62

ГОСТ Р ИСО/МЭК 8831-99

Для каждого параметра < идентификация пн > в поле < пи агентства > выдается одна группа примитивов J-DISPOSE для каждого документа, формируемого при помощи параметра < блок документа >. Параметры < имя-хранилнша-файлов > или < параметр агентства > получаются из параметра < идентификация пи >.

Группа примитива J-D1SPOSE также выдается в принимающее агентство, указанное в параметре < данные размещения > (при его наличии) для монитора задания ВОС. при каждом отчете, который поступает в монитор задания ВОС.

Параметр < указатель пи документа > получается из параметров < префикс пи >, < блок документа > или < данные размещения >.

Параметр < ошибки > содержит список < диагностическая информация >, формируемый из параметров < идентификация исходного агентства > и < информация об ошибке > для любого параметра < указатель одного документа > со значением БЕЗУСПЕШНО параметра < состояние > (см. 3.4.4.1.3). Параметры < ошибки > (при их наличии) передаются в принимающее агентство вместе с параметром < документ размещения >. Размещение параметра < ошибки > не стандартизовано.

Параметр < документ размещения > содержит поле < ПОЗ-отображение-отчета > или документ любого другого (стандартного или нестандартного) типа, обеспечиваемого PC.

Примечание — Необходимо, чтобы PC устанавливали тииы документов, которые они обеспечивают (для примитивов J-GIVE, J-D1SPOSE и передачи). Предполагается, что универсальные PC, должны обеспечивать. но меньшей мере, первые три типа документов, определенные в приложении С.

Размещение отчетов в принимающие агентства выполняется примитивом J-DISPOSE после преобразования параметра < отчет > в параметр < ПОЗ-отображение-отчета >.

3.6.2.2 Примитив ответа J-DISPOSE

Содержит единственный параметр

<    идентификатор активности агентства = S >.

Он представляет локальную информацию, необходимую для идентификации активности последующих групп примитивов, выдаваемых поставщиком услуг ПОЗ (J-KILL. J-STATUS и т. д.). Его формат не стандартизован.

3.6.3 Сервисные примитивы J-GIVE

3.6.3.1 Примитив индикации J-GIVE

Вводится в исходное или исполняющее аге»ггство в результате обработки параметра < указатель единичного документа > или параметров < структура исходного агентства документа > и

<    список-имен >, следующих за примитивом J-ENQU1RE (см. 3.4.4.1.3 и 3.4.4.I.4).

Примитив индикации J-GIVE выдается системой < открытая система действия = N > в исходное или исполняющее агентство, идентифицированное параметром < имя исходного агентства = S > для формы < пн ПОЗ > и в локальное исходное агентство, осуществляющее доступ к ПДУФ для формы < исходное агентство ПДУФ >.

Примитив индикации J-GIVE содержит следующие параметры:

(см. 3.6.2) (см. 3.6.2) (см. 3.4.4.1.1) (см. 3.4.4.1.3)

(см. 3.4.4.1.3)

<    полномочие пользователя >

<    счет пользователя >

<    дополнительные полномочия >

<    указатель источника документа >

(< имя-хранилиша-файлов = N > |

<    параметр агентства = S >)

<    тип документа = ND >

<    группа документа >

<    группа документа > : : =

(ПОСТОЯННЛЯ I < группа конца активности > I < группа проформы >)

<    группа конца активности > : : =

< идентификатор активности агентства >    (см. 3.6.2)

<    группа проформы > : : =

< идентификатор активности агентства >    (см. 3.6.2)

<    обработка запроса порождения = S >

Все параметры и их смысл определены в предыдущих разделах, кроме параметра < группа документа >. Этот параметр будет иметь значение ПОСТОЯННЫЙ до тех пор, пока примитив J-GIVE не будет введен в исполняющее агентство со значением < группа конца активности > или

57

Страница 63

ГОСТ Р ИСО/МЭК 8831-99

<    группа проформы >. В дампом случае это означает, что примитив индикации J-G1VE для документов доступен в конце активности или получается при порождении проформы, которая имеет значение параметра < обработка порождения документа >. соответственно равное значению параметра

<    обработка запроса порождения >.

Если параметр < имя исходного агентства > указывает исполняющее агентство, то активность, к которой относится примитив J-GIVE, идентифицируется параметром < идентификатор активности агентства >. Из множества документов, к которым должен осуществляться доступ, те которые становятся доступными в конце активности, имеют параметр < группа конца активности >, а те, которые досту пны при выдаче примитива J-SPAWN, имеют параметр < группа проформы >. В дальнейшем параметр < обработка запроса порождения > будет равен его значению в примитиве запроса J-SPAWN.

3.6.3.2 Примитив ответа J-GIVE

Содержит единственный параметр < документ >. Этот < документ > имеет < тип документа > в примитиве индикации J-GIVE. Следует заметить, что если соответствующий документ не может быть найден, примитив запроса J-ROLLBACK выдается вместо примитива ответа J-GIVE. после чего поставщиком услуг используется диагностика услуги типа «С-* ПОЗ для диагностики ПОЗ.

Агентство, которое является исходным и принимающим, предоставляет возможность немедленного доступа примитива J-GIVE к документу, размещенному примитивом индикации J-DISPOSE в том случае, когда используется тот же идентификатор элементарного действия.

Агентство допускает выполнение нескольких примитивов J-G1VE при помощи одного и того же элементарного действия, даже если при последнем доступе указывается значение операции ПЕРЕМЕЩЕНИЕ. Исходный документ удаляется только в том случае, если все группы примитивов J-G1VE исполнили операции или возвращены в первоначальное состояние, по меньшей мере, с одним исполнением операции ПЕРЕМЕЩЕНИЕ.

Параллельно выполняемая активность с другим идентификатором элементарного действия придерживается обычных правил СИВ.

3.6.4    П р и м и т и в ы индикации и ответа J-ENQU1RE

Выдается в исходное или исполняющее агентство в результате обработки блока документа

<    групповая форма > в подзадании ВОС, которое должно выполняться.

Исходное или исполняющее агентство, которому выдается этот примитив, получает его также как и примитив индикации J-G1VE. Он содержит следующие параметры:

<    полномочие пользователя >    (см. 3.6.2)

<    счет пользователя >    (см. 3.6.2)

<    дополнительные полномочия >    (см. 3.4.4.1.1)

<    параметр агентства = S >    (см. 3.4.4.1.1)

<    структура исходного агентства документа >    (см. 3.4.4.1.4)

<    селектор документа = S >    (см. 3.4.4.1.4)

<    тип документа = ND >

< группа доку мента >    (см. 3.6.3.1)

Примитив ответа J-ENQUIRE содержит только параметр |< список-имен >|* L.

Примитив J-ENQUIRE используется для получения имен всех документов, чей < список-

имен > начинается с последовательности < частичный-список-имен > в параметре < структура исходного агентства документа > и к которым возможен доступ при помощи примитива J-GIVE, используя указанные параметры (см. 3.4.4.1.4).

Выданные имена < списка-нмен > представляют собой суффиксы, добавляемые к последовательности < частичный-список-имен > при выдаче примитивов J-GIVE.

Если документ не может быть найден, выдается примитив запроса J-ROLLBACK вместо примитива ответа J-ENQU1RE, и затем диагностика услуги типа «С-* используется поставщиком услуг ПОЗ для диагностики ПОЗ.

Следует заметить, что не требуется, чтобы примитив ответа J-ENQU1RE оставался доступным после соответствующего примитива индикации J-COMM1T. Поставщик услуг ПОЗ выдает все необходимые группы J-G1VE (с таким же идентификатором элементарного действия) до исполнения операций, относящихся к примитиву J-ENQU1RE.

3.6.5    11 р и м и т и в запроса J-MESSAGE

Содержит параметры:

58

Страница 64

ГОСТ Р ИСО/МЭК 8831-99

<    идентификатор активности поставщика >

<    сообщение >

< сообщение > : : = |< текст = S >|4 L

Параметр < сообщение > используется поставщиком услуг ПОЗ для формирования списка текстов отчета, который передается в монитор задания ВОС. если выбирается уведомляющая служба тина события СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ. (Если уведомляющая служба такого типа события не выбирается для любого пункта монитора. < сообщение > отклоняется).

Параметр < уровень исполнения > устанавливается в значение ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА, и элементарное действие всегда выполняется до исполнения. Указатель кода диагностики идентичен его указателю в соответствующем примитиве J-DISPOSE, а < сообщение > соответствует наборам знаков, требуемым указателем кода диагностики. Каждая строка < текст > в параметре < сообщение > ограничивается по длине до 40 знаков.

3.6.6    Примитив запроса J-SPAWN

Используется, чтобы вызвать создание новых СР из одной или нескольких проформ верхнего уровня в СР. связанной с активностью. Параметрами являются:

<    идентификатор активности поставщика >

<    обработка запроса порождения >

Порождаемой является любая проформа верхнего уровня с параметром < обработка запроса порождения >, равных» одноименному параметру < обработка запроса порождения > примитива запроса J-SPAWN. После соответствующего примитива индикации J-READY любые документы, которые должны использоваться при порождении, могут быть удалены (выбор при помощи примитива J-GIVE завершается).

Параметр < уровень исполнения > может принять некоторое определенное значение. Элементарное действие может быть возвращено в исходное состояние примитивом J-ROLLBACK.

3.6.7    Примитив запроса J-END-SIGNAL

Неявно ссылается на более ранний примитив J-D1SPOSE, который задал уровень исполнения ПРИ НЯТИЕ. Этот примитив содержит только параметр < идентификатор активности поставщиках Если приачекается только одна активность, то все проформы верхнего уровня, отмеченные для порождения с условием ЗАВЕРШЕНИЕ или УСЛОВНЫЙ, обязательно порождаются в порядке их появления в списке < список проформ >. См. также 3.4.5.2. Если привлечено более одной активности. то порождение выполняется только в том случае, если выполняются все группы примитивов J-END-SIGNAL.

Уровень исполнения равен I. и элементарное действие всегда выполняется до исполнения.

3.6.8    Примитивы индикации и ответа J-STATUS

Примитив индикации J-STATUS выдается поставщиком услуг ПОЗ в принимающее или исполняющее агентство, которое предоставило примитиву J-DISPOSE уровень исполнения ПРИНЯТИЕ, но еще не был введен примитив запроса J-END-SIGNAL. Он содержит только < идентификатор активности агентства >. Примитив ответа содержит единственный параметр < сообщение о состоянии >:: = |< текст = S >|* L

Примитив индикации выдается поставщиком услуг ПОЗ как результат выполнения операции «отображение выполнения работы» в СР, связанной с этой активностью. Параметр < сообщение о состоянии > содержится в этом отображении. Его форма не определена, но он должен выдавать как можно больше информации о состоянии активности в агентстве. Если агентство желает, чтобы отчет содержал < идентификатор активности агентства >, оно включает его в < сообщение о состоянии >.

Это элементарное действие всегда выполняется до исполнения. Набор знаков в сообщении о состоянии соответствует требованиям указателя кода диагностики. Каждая строка параметра < текст > ограничена по длине до 4() знаков.

3.6.9    Примитивы индикации J-HOLD, J* RELEASE. J-K1LL. J-STOP

Эти примитивы содержат только параметр < идентификатор активности агентства >.

Примитив индикации и J-HOLD информирует принимающее или исполняющее агентство о

том. что поставщик услуг ПОЗ желает, чтобы активность была приостановлена. Примитивы запроса J-MESSAGE, J-SPAWN и J-END-SIGNAL не выдаются до тех пор. пока не будет принят примитив индикации J-RELEASE.

Примитив индикации J-RELEASE разрешает выдачу примитивов запроса J-MESSAGE. J-SPAWN. J-END-SIGNAL и используется для отмены примитива J-HOLD.

59

Страница 65

ГОСТ Р ИСО/МЭК 8831-99

Примитив индикации J-KILL требует, чтобы принимающее или исполняющее агентство завершило активность, начатую примитивом J-D1SPOSE. и сформировало примитив запроса J-END-SIGNAL. Примитив J-END-SIGNAL не может обеспечить никаких документов. (Поставщик услуг ПОЗ не выдает группы J-ENQU1RE или J-GIVE).

Примитив индикации J-STOP имеет такое же действие, как примитив J-KILL, но документы будут доступны в результате выполнения примитива J-END-SIGNAL. (Поставщик услуг ПОЗ выдает группы J-ENQUIRE и J-G1VE). Управляемый ЛО не выдает примитива J-ROLLBACK для этих элементарных действий, но управляющий ЛО может потребовать возвратиться в первоначальное состояние.

3.6.10 Краткое описание

Краткое описание СП ПОЗ представлено в таблице 3. Указания по их использованию представлены в таблице 2.

Таблица 2 — Примитивы, потенциально используемые при обработке одного подавления

Подзцданнс «перемещение-документа»

J-ENQUIRE    если представлен блок документ групповой формы

J-GIVE    если представлен указатель одного документа или после примитива J-ENQLIRE

J-DISPOSE    этот примитив завершает или разрешает примитивы J-END-SIGNAL, J-SPAWN    и

J-MESSAGE

Подзадание «перемещение-отчета*

J-DISPOSE

Под задание «выполнение-работы»

J-KILL

J-STOP

J-HOLD

J-RELEASE

J-STATUS

Подзадание «обработка-ЗУП* Her

Подзаданис «управление-отчетом» Her

Таблица i — Краткое описание СП и параметров ПОЗ

Примитивы

Запрос

Индикация

Ответ

Подтверждение

J-INITIATE-WORK спецификация перемещения документа локальный указатель задания ВОС

_

-

J-IN1TIATE-WORK-MAN спецификация выполнения работы локальный указатель задания ВОС

-

-

J-1NITIATE-TCR-MAN спецификация управления передачами локальный указатель задания ВОС

_

-

J-INITIATE-REPORT-MAN спецификация управления отчетами локальный указатель задания ВОС

-

-

60

Страница 66

ГОСТ Р ИСО/МЭК 8831-99

Окончание табл. .?

Примитивы

Запрос

Индикации

Ответ

Подтверждение

J-DISPOSE

идентификатор активности поставщика

улолномочснкый поль ювапсля

счет пользователя

параметр агентства | имя-хранилиша-файлов

указатель пи документа

дополнительные полномочия

ошибки

документ и тип документа

идентификатор активности агентства

-

J-GIY'E

уполномоченный пользователя

счет пользователя

параметр агентства I имя-хранилиша-файлов

указатель источника документа

дополнительные полномочия

тип документа

группа документов

документ и тип документа

-

J-ENQUIRE

упалномоченный патьэователя

счет пользователя

параметр агентства

структура исходного агентства документа

дополнительные полномочия

тип документа

селектор документа

группа документов

список списков имен

-

J-SPAWN

идентификатор активности поставщика

имя проформы

J-MESSAGE

идентификатор активности поставщика

сообщения

J-END-SIGNAL

идентификатор активности поставщика

J-STATUS

идентификатор активности агентства

-

сообщение о состоянии

J-HOLD

идентификатор активности агентства

-

J-RELEASE

идентификатор активности аге»ггства

-

J-KILL

идентификатор активности агентства

-

J-STOP

идентификатор акгивносги агентства

агентства

4-1- IU4.4

61

Страница 67

ГОСТ Р ИСО/МЭК 8831-99

Группа примитивов J-INITIATE может привести к выдаче последующих СП в виде прямого результата выполнения первого подзадания. Если первое подзадание порождает другие подзадания при помощи примитивов J-SPAWN. J-END-SIGNAL при завершении примитива J-DISPOSE или после обработки, то впоследствии могут быть выданы группы примитивов. Эти группы примитивов, обусловленные выдачей первоначальных групп примитивов J-IN1TIATE, могут быть выданы одновременное выдачей такой группы примитивов или после нее, в зависимости от уровня исполнения. Поскольку проформа может содержать любой тип подзадания (кроме ПЕРЕМЕЩЕНИЕ-ОТЧЕТА), то любой тип группы примитивов J-INITIATE может развиваться до всех форм СП в зависимости от его параметров. Кроме того, отчеты о событиях, включая отчеты, обусловленные группой J-MESSAGE, могут привести к выдаче примитива J-DISPOSE. В таблице 2 приведены подробные сведения о примитивах, которые могут быть использованы при обработке одного подзадания.

РАЗДЕЛ 4. БАЗОВЫЙ КЛАСС

4.1    Группы примитивов и тины документов для базового класса

4.1.1    Группы сервисных примитивов Можно использовать следующие группы примитивов:

J-INJTIATE-WORK

J -1N ГПАТЕ-WORK MAN

J-DISPOSE

J-GIVE

J-END-SIGNAL J-STATUS J-K1LL J-STOP J-MESSAGE

PC базового класса может обеспечить любую комбинацию следующих наборов СП:

a)    J-INITIATE-WORK:

b)    J -1NIT1AT E- WORK - MAN;

c)    J-DISPOSE (к принимающему или исполняющему агентству) с уровнем исполнения операций ЗАВЕРШЕНИЕ в примитиве J-READY;

d)    J-G1VE (для группы конца активности);

e)    J-DISPOSE (к принимающему или исполняющему агентству) с уровнем исполнения ПРИЕМЛЕМЫЙ ДНЯ АГЕНТСТВА в примитиве J-READY

J-END-SIGNAL J-STATUS J-MESSAGE J-KILL J-STOP

Система базового класса не обеспечивает значения ЗАВЕРШЕНИЕ для уровня исполнения в примитивах C-BEGIN или J-BEGIN. Однако она может выдать или принять такое значение в примитиве С-READY или J-READY.

4.1.2    Типы документов

Системам базового класса нет необходимости обеспечивать полную классификацию типов документов. ГОСТ ИСО/МЭК 8832 определяет три типа документов, поименованных значениями ОписательОбьекта АСН.1 (см. ГОСТ 34.973):

•простой текстовый документ ИСО*;

«простой документ для печати ИСО*;

«простой документ в двоичном формате ИСО*.

Для краткости эти типы документов указываются в этом разделе только, как «текст» (I), «печать* (2) и «двоичный» (3). соответственно.

Кроме того, в базовом классе используются следующие типы документов (см. 3.5):

«документ отображение-работы ПОЗ*,

«документ отображение-отчета ПОЗ».

Для краткости эти типы документов указываются в этом разделе только как «отображение-работы (4)* и «отображение-отчета (5)* (см. 4.2.1).

62

Страница 68

ГОСТ Р ИСО/МЭК 8831-99

Следующие типы документов, требующиеся для общею назначения, обеспечиваются PC базового класса:

в примитиве J-INITIATE-WORK текст (1) печать(2);

в проформе примитива J-IN1TIATE-WORK печать (2):

в проформе примитива J-INIT1ATE-WORK-MAN отображение-работы (4) (только короткое);

в примитиве J-GIVE печать (2);

в примитиве J-D1SPOSE текст (I) печать(2)

отображение-отчета (5)

отображен не-работы (4) (только краткое).

Следует замелеть, что другие типы документов нет необходимости обеспечивать в PC базового класса ПОЗ.

4.2 Концептуальные структуры данных для базового класса

В данном разделе описаны подмножества структу р данных (определенных в 3.3—3.5). которые используются в базовом классе. 13 4.3 определены дополнительные ограничения базового класса на параметры СП.

Примечание — Если на параметры примитива запроса J-INIT1ATE базового класса (см. 4.3) налагаются болсс сильные ограничения, чем на соответствующие ноля концептуальной структуры данных базового класса, определенные в этом разделе, то имеет место только описанный здесь обший случай, при котором PC базового класса взаимодействует с PC. обладающей болсс широкими функциональным» возможностями. чем требуется для базового класса.

4.2.1    Отчеты

Отчеты базового класса формируются PC базового класса. Пункт монитора базового класса может обрабатывать отчеты только базового класса.

Эти отчеты образуют подмножество отчетов, определенных в 3.3.2 следующим образом:

<    отчет > : : = < имя уведомителя >

<    отметка времени >

<    идентификация подзадания >

<    идентификация события >

<    параметры события >

Параметр < идентификация подзадания > имеет весь диапазон значений, указанных в 3.3.2.

<    идентификация события > : : =

(НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ | ЗАВЕРШЕНИЕ-ОБРАБОТКИ I

АВАРИЙНОЕ ЗАВЕРШЕНИЕ) | СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ)

Другие события не распознаются в базовом классе. Отчеты о других событиях не обрабатываются пунктами монитора базового класса. Запросы (в параметре < селектор отчета >) отчетов о других событиях СР отклоняются системой базового класса.

Для < параметров событий > обеспечиваются только значения < число порождений >, < текст > и < диагностика >.

4.2.1.1    Диагностическая информация

Параметр < диагностическая информация > в сообщениях, принятых пунктами монитора базового класса, может иметь полную форму, определенную в 3.3.3, со следующими исключениями.

Поля < детали исходного агентства > и < детали пи > не относятся к активности ПДУФ. а параметр < диагностика СИВ > не содержит значения < итог ПДУФ >.

4.2.1.2    Ин<\юрмация учета

Информация учета не формируется системами базового класса. Если она передается к таким системам в примитивах C-READY или C-REFUSE, она игнорируется.

63

4-1*

Страница 69

ГОСТ Р ИСО/МЭК 8831-99

4.2.2 Спец и фи каин и работы

PC базового класса обеспечипает ограниченную форму СР. СР создаются в системе базового класса как результат поступающей информации или (если инициирующее агентство обеспечивается) примитива J-IN1TIATE (см. 4.3). Такие СР содержат только определенную ниже информацию. Попытка передать более сложную СР в систему базового класса завершается отклонением и диагностикой СИВ.

<    спецификация работы > : : = < параметры задания ВОС >

<    спецификация подзадания >

<    список проформ >

<    локальные поля >

<    список документов >

Параметры < локальные поля > являются такими же, как в 3.4.1, за исключением того, что поля < время ожидания > и < подсчитанный размер > не представлены, а поля < параметры активности агентства > идентифицируют, самое большее, одну активность агентства.

<    спецификация подзадания > : : = < параметры подзадания ВОС >

<    параметры действия ПОЗ >

<    действие при ошибке >

<    действие при ошибке > : : = ЗАВЕРШЕНИЕ

<    список проформ >:: = |< проформа >|*L

<    список документов > : : = |< документ >1*L

Параметр < список проформ > для некоторой СР с параметром < целевая система > базового класса содержит, самое большее, одну проформу верхнего уровня. Любые списки проформ внутри этой проформы обрабатываются прозрачно. СР, созданные порождением в системе базового класса и предназначенные для некоторой другой системы, содержат прозрачный список проформ.

Примечание — Списки проформ имеют место только внутри проформы, если первоначальная СР была создана в PC с более широкими функциональными возможностями, чем требуется для базового класса.

СР базового класса содержит, самое большее, один параметр < документ >, указываемый подзаданием верхнего уровня.

4.2.2.1 Параметры задании ВОС

Ограничения базового класса на эти параметры применимы к целому заданию ВОС. Любое задание ВОС, которое должно использовать систему базового класса для обработки любых своих подзаданий ВОС. подчиняется ограничениям этого раздела.

< параметры задания ВОС > :: = < система предоставления задания ВОС >

<    идентификация инициирования >

<    время инициирования >

<    имя задания ВОС >

<    локальный указатель задания ВОС >

<    проверочная трасса >

<    первичная контролирующая спецификация >

<    полномочия >

<    разрешения >

<    параметры СИВ >

Отметим, что параметры < первичная контролирующая спецификация >, < учет > и < параметры защиты > отсутствуют.

Примечание — Взаимосвязь между расширенной PC, требующей параметр < учет >, и PC' базового класса невозможна. По этой причине требуется, чтобы расширенные PC имели возможность работать без параметров < учет >.

Поля < параметры задания ВОС > имеют полную форму и значения, определенные в 3.4.2 за исключениями, приведенными ниже.

Система базового класса может игнорировать параметр < полномочия > и выполнить полномочие, используя данные, содержащиеся в параметре < документы >, которые должны быть посланы принимающим и исполняющим агентствам.

Примечай и с — Не требуется, чтобы системы базового класса обеспечивали исходные агентства. Следовательно, для примитива J-GIVE полномочие не Требуется, поскольку доступ имеется только к активности исполняющего агентства, установленной ранее выданным примитивом J-D1SPOSE. Связующим параметром между двумя примитивами является идентификатор активности агентства.

64

Страница 70

ГОСТ Р ИСО/МЭК 8831-99

Параметр < первичная контролирующая спецификация > не содержит значения < промежуточная система >, а параметр < инструкции по размещению > не имеет значения СОХРАНЕНИЕ. Параметр < селектор отчета > содержит только следующие категории событий:

НОРМА.'!ЬНОЕ ЗАВЕРШЕНИЕ ЗАВЕРШЕНИЕ-ОБРАБОТКИ АВАРИЙНОЕ ЗАВЕРШЕНИЕ СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ.

4.2.2.2 Пирометры подзадачи* ВОС

< параметры п од задан н я ВОС >:: = < список имен под задания >

<    список целевых систем >

<    срочность >

<    тип подзадания >

Параметр < список целевых систем > содержит только значение < целевая система > для СР. передаваемой в систему базового класса или формируемой там при помощи порождения или примитива J-IN1TIATE. Параметр < удержания > также отсутствует в таких подзаданиях.

Эти ограничения не применяются в проформах, которые остаются прозрачными для системы базового класса (не порожденные) (см. 4.2.7).

Параметр < тип подзадания > имеет одно из следующих значений: ПЕРЕМЕЩЕНИЕ-ОТЧЕТА ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА ВЫПОЛНЕНИЕ- РА БОГ Ы.

Другие значения параметра < тип подзадания > имеются только в проформах, которые остаются прозрачными.

4.2.3    Операции перемещения документов

Следующие ограничения налагаются на подзадания, параметр < целевая система > которого указывает систему базового класса. Они не применяются там, где проформа обрабатывается прозрачно (см. 4.2.7).

Имеется один параметр < перемещение документа > и один параметр < идентификация пи >. Параметр < блок документа > имеет значение < одна форма >.

Параметр < идентификация пи > не имеет формы < ни ПДУФ >. Он не имеет значения

<    дополнительные полномочия >; < параметр агентства > имеет значение НУЛЬ, а параметр

<    префикс пи > является пустым.

Параметр < указатель пи документа > не имеет формы < ПДУФ—писать данные >, а < параметр доступа пи > имеет значение НОРМАЛЬНЫЙ.

Имеется один параметр < указатель документа >, который при достижении целевой системы базового класса имеет значение ВЛОЖЕННЫЙ, или содержит одно иоле < указатель единичного документа > со значением параметра < состояние > БЕЗУСПЕШНО.

В последнем случае параметр < идентификация исходного агентства > имеет значение < исходное агентство ПОЗ >, отсутствует параметр < дополнительные полномочия >, а параметр < указатель источника документа > имеет значение < ПОЗ-читать данные >. Параметр < диагностика СИВ > имеет форму, определенную в 4.2.1.1.

Если < операции перемещения документов > имеются в подзадании верхнего уровня, произведен нога в системе базового класса порождением, то может иметь место параметр < указатель единичного документа > с состоянием НЕТ-ПОПЫ ГКИ. Если < действие открытой системы > является локальной, параметр < идентификация исходного агентства > имеет значение ПОСТАВЩИК или < исходное агентство ПОЗ >, которое представляет исполняющее агентство, и имеется

<    параметр агентства > со значением НУЛЬ и < параметр доступа к исходному агентству > со значением ПЕРЕМЕЩЕНИЕ.

4.2.4    Операции выполнения работы

Операции выполнения работы в подзадании, предназначенные для целевой системы базового класса, имеют следующие ограничения.

Параметр < операции СР > содержит дм поля < операция работы >. Первое поле < операция работы > имеет значение «ВЫБОР < селектор >* (см. ниже).

Второе поле имеет одно из значений

УНИЧТОЖЕНИЕ

ОСТАНОВ

ОТОБРАЖЕНИЕ < имя-док > КРАТКОЕ.

65

4-2-КЫЗ

Страница 71

ГОСТ Р ИСО/МЭК 8831-99

Параметр < селектор > содержит три поля < тест поля >, составленные из операторов и для получения значения < тест заголовка >. При этом параметр < селектор > будет иметь значение

П ЕРВ Ы Й - ЗАГОЛОВОК- И М ЕЕТСЯ

< тест заголовка >.

Три поля < тест поля > содержит тесты на пригодность трех полей

ВОС-СИСТЕМЛ-П РЕДОСТАВЛ Е Н ИЯ - ЗАДАН ИЯ

ВОС-ИМЯ-ЗАДАН ИЯ

ТИП-ПОД ЗАДАН ИЯ.

Использование значения ЛЮБОЙ-ЭЛЕМЕНТ не обеспечивается в базовом классе.

В системах базового класса концептуальная структура данных «список заголовков* содержит, таким образом, только один заголовок и только с этими тремя полями.

Если СР содержит апоженные проформы, они являются полностью прозрачными, и имена открытых систем, содержащихся в параметре < целевая система > или в параметрах < промежуточная система > этих проформ, не обеспечивают неявных разрешений для обработки или отображения СР.

4.2.5    Операции перемещения отчетов

Параметр < операция перемещения отчетов > имеет полную общность с описанием в 3.4.4.5, за исключением того, что:

a)    индекс монитора всегда имеет значение «нуль* (только первичные мониторы);

b)    < данные размещения > не имеют значение СОХРАНЕНИЕ;

c)    ограничения на форму параметров < идентификация пи > и < указатель пи документа > определены в 4.2.3.

4.2.6    Проформы

Проформа верхнего уровня в системе базового класса имеет параметр < данные управления порождением >, установленный в значение ЗАВЕРШЕНИЕ. Имя проформы не используется ни в одном указателе проформы в любой вложенной проформе.

4.2.7    Прозрачность проформ

СР. передаваемая в систему базового класса, имеет параметр < целевая система > этой открытой системы.

СР. созданная порождением (или примитивом J-IN1T1ATE), может (первый случай) или не может (второй случай) иметь такую открытую систему, которая указана параметром < целевая система >.

В первом случае подзадание. указанное в СР. имеет, самое большее, одну проформу верхнего уровня: основное подзадание, проформа верхнего уровня и подзадание. указанное в проформе верхнего уровня, подчиняются ограничениям базового класса, указанным в этом разделе. Параметр < список проформ > в проформе верхнего уровня яатяется прозрачным и неограниченным.

Во втором случае подзадание. указанное в СР. подчиняется ограничениям базового класса, однако параметр < список проформ > в под задан и и яатяется прозрачным и неограниченным.

4.2.8    Записи управления передачей

Системы базового класса не распознают понятие ЗУП, и не обеспечивают подзадания типа ЗУ П-О Б РАБОТ КА.

Все передачи, выполняемые из таких систем, планируются в зависимости от PC.

4.2.9    Документы ПОЗ

Система базового класса обеспечивает формирование и передачу отображений работы ПОЗ. содержащих только параметр < краткое отображение >. Она не обеспечивает такие документы, если они содержат параметр < полное отображение >.

Если система обеспечивает формирование примитива J-INITIATE-MAN, она обеспечивает прием таких документов и их размещение, используя примитив J-D1SPOSE.

Если система базового класса обеспечивает пункт монитора, она способна преобразовать параметр < отчет > (см. 4.2.1) в документ отображения отчета ПОЗ и разместить этот документ, используя примитив J-DISPOSE к принимающему агентству.

Документы отображения ЗУП ПОЗ не обеспечиваются.

Система базового класса, предназначенная для общего назначения, обеспечивает типы документов, перечисленные в 4.1.2. Она также может обеспечивать другие типы документов.

66

Страница 72

ГОСТ Р ИСО/МЭК 8831-99

4.3 Параметры группы примитивов J-INITIATE для базового класса

В службе базового класса группа примитивов J-INITIATE имеет подмножество параметров, доступных в расширенной [103. Имеются следующие ограничения.

Уровень исполнения имеет только значения ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА и ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА и примитиве J-BEGIN.

Отсутствуют параметры < вторичная контролирующая спецификация >, < учет > и < параметры защиты >.

Допускаются только примитивы

J-IN1TIATE-WORK

J -1N1TIATE-WORK- MAN.

Параметр < спецификация под задания > для примитива J-IN1TIATE-WORK подчиняется ограничениям, указанным в 4.2, но кро.ме этого на него налагаются следующие ограничения.

4.3.1    Параметры верхнего уровня

<    параметры задания ВОС >;

<    параметры под задан и я ВОС >;

<    параметры действия ПОЗ >;

<    действие при ошибке > — ЗАВЕРШЕНИЕ;

<    список проформ > — одна проформа или нет проформ. (Одна проформа не имеет вложенных проформ);

<    список документов > — одни документ «текст (1)» или «печать (2)» для примитива J-INITIATE-WORK. Нет документов для примитива J-INUIATE-WORK-MAN. Если документ «-печать (2)*, то проформы отсутствуют.

4.3.2    Параметры задания ВОС

<    идентификация инициирования > — любое значение;

<    ВОС-имя-задания > — любое значение;

<    данные полномочия > — параметры < элемент полномочий > и < элемент разрешения >, предоставляющие идентификацию пользователя и пароль для использования в открытой системе

<    целевая система >. Этот параметр используется для полномочий активностей ПОЗ, таких как обработка или выдача результата. Исполняющее агентство может потребовать, чтобы одна и та же информация повторялась в заголовке документа (<-ЯУЗ*). передаваемом в примитиве J-DISPOSE. Могут присутствовать дополнительные полномочия и элемент разрешения, чтобы обеспечить выполнение действия в целевой системе проформы. Идентификация элемента разрешения всегда совпадает с идентификацией элемента полномочий;

<    вторичная контролирующая спецификация > — отсутствует. Локальная САУ устанавливает параметр < первичная контролирующая спецификация > с полем < селектор отчетов >, указывающим один или несколько типов событий АВАРИЙНОЕ ЗАВЕРШЕНИЕ. СООБЩЕНИЕ-ПОЛЬЗОВАТЕЛЯ. НОРМАЛЬНОЕ ЗАВЕРШЕНИЕ И ЗАВЕРШЕНИЕ-ОБРАБОТКИ, и с параметром

<    данные размещения > по своему выбору. Значение СОХРАНЕНИЕ не используется в базовом классе.

4.3.3    Параметры подзадания ВОС

<    список целевых систем > — одно поле < целевая система >; параметр < промежуточные системы > имеют пустое значение;

<    срочность > — только значение СРЕДНЯЯ;

<    удержания > — имеет пустое значение;

<    тип подзадания > - только значение ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА или ВЫПОЛНЕНИЕ-РАБОТЫ.

4.3.4    Параметры действия ПОЗ

Ими являются < операции перемещения документа > или < операции выполнения работы >.

4.3.4.1 Операции перемещения документа

Имеется одна операция < перемещение документа >. содержащая параметры:

<    тип документа > — «текст (I)» или «печать (2)»;

<    агентство пи > — один параметр < идентификация пи > формы < пн ПОЗ >. содержащий:

<    имя пи > — значение имени принимающего агентства (тип документа «печать (2)* или имя исполняющего агентства (тип докумеша «текст ( I)*) в параметре < целевая система >;

<    параметр агеиства > — НУЛЬ;

67

4—2*

Страница 73

ГОСТ Р ИСО/МЭК 8831-99

<    префикс пи > — НУЛЬ:

<    дополнительные полномочия > — отсутствуют;

<    блок документов > — только одии параметр < единичная форма >. содержащий папе

<    ПОЗ-писать данные >:

<    параметр доступа пи > — установить значение НОРМАЛЬНЫЙ.

<    список-имен > — установить имя документа;

один < указатель документа > — установить значение ВЛОЖЕННЫЙ.

4.3.4.2 Операции выполнения работы

Имеются две < операции выполнения работы >. Первая — < операция выбора >, а вторая — УНИЧТОЖЕНИЕ, ОСТАНОВ или ОТОБРАЖЕНИЕ. Параметр < селектор > имеет значения

ПЕРВЫЙ ЗАГОЛОВОК ИМЕЕТСЯ и

И ВОС-СИСТЕМА- П РЕДОСТАВЛ ЕН ИЯ - ЗАДАН ИЯ РАВНО < имя >

И ВОС-ИМЯ-ЗАДАНИЯ РАВНО < строка >

ГИП-ПОДЗАДАНИЯ РАВНО < тип подзадания >.

Операция ОТОБРАЖЕНИЕ запрашивает значение КРАТКОЕ, и значением параметра < имя документа > является строка ОТОБРАЖЕНИЕ. Параметр < имя > указывает такую открытую систему, в которой был введен примитив J-INITIATE-MAN.

4.3.5 Проформы

Одна проформа, если она представлена, содержит

<    имя проформы > — установить значение ВЫВОД.

Основная часть проформы с параметрами:

<    данные управления порождением > — установить значение ЗАВЕРШЕНИЕ;

<    параметры подзадания ВОС >— как в 4.3.3, но тип подзадания имеет значение ПЕРЕМЕЩЕНИЕ-ДОКУМЕНТА;

<    параметры действия ПОЗ > — см. ниже;

<    список проформ > — проформы не появляются в проформах в примитиве J-INITIATE базового класса.

Параметры действия ПОЗ в проформе базового класса содержат одну операцию перемещения документа с параметрами:

<    тип документа > — система предостатения задания ВОС с минимальным согласованием возможна при установке этого поля в значение «печать (2)» (для примитива J-INITIATE-WORK) и в значение «отображение-работы (4)* (для примитива J-INITIATE-WORK-MAN) и любое другое значение устанавливать не требуется. Для системы с минимальным согласованием, принимающей СР. не требуется обеспечение любого значения, отличного от перечисленных выше:

<    пи агентство > — имеется один параметр < идентификация пи > формы < пн ПОЗ >:

<    имя пи >— соответствующее имя принимающего агентства в целевой системе проформы;

<    параметр агентства > — НУЛЬ;

<    префикс пи > — НУЛЬ:

<    блок документов > — имеет значение < одна форма >, содержащее:

<    параметр доступа пи > - установить значение НОРМАЛЬНЫЙ:

<    список-имен > — одно имя.

Параметр < блок документа > также содержит одно поле < указатель документа >, которое имеет значение < указатель одного документа >, предоставляющий параметры:

<    действие открытой системы > — равно начальному значению < целевая система >;

<    идентификация исходного агентства >— значение ПОСТАВЩИК в проформе при обработке. в противном случае — значение < исходное агентство ПОЗ >;

<    имя исходного агентства > — равно начальному значению < имя пи >:

<    параметр агентства > — НУЛЬ:

<    указатель источника документа > — имеет значение < ПОЗ-читать-данные >;

<    параметр доступа к исходному агентству > — имеет значение ПЕРЕМЕЩЕНИЕ;

<    список-имен > — принимает соответствующее значение для сборки документа из целевой системы;

<    встроенная диагностика >— имеет значение ВСТРОЕННАЯ.

68

Страница 74

ГОСТ Р ИСО/МЭК 8831-99

4.3.6 Краткое описание информации, содержащейся в прими-т иве запроса J-I N 1 Т I А Т Е базового класса

4.3.6.1    Примитив J-1NITIA ТЕ- WORK

В этом примитиве поставщику услуг ПОЗ передается следующая информация:

a)    идентификация инициирования:

b)    имя задания ВОС;

c)    имя целевой системы:

d)    имя принимающего или исполняющего агентства в целевой системе;

e)    идентификация пользователя и пароль для использования в целевой системе:

О документы «текст (I)* или «печать (2)* для передачи в исполняющее или принимающее агентство (соответственно) и их имена;

g)    имя целевой системы проформы (если используется исполняющее агентство);

h)    идентификация пользователя и пароль для использования в целевой системе проформы, если это требуется;

i)    имя итоговой распечатки (2), произведенной в начальной целевой системе;

j) имя принимающего агентства в целевой системе проформы для итогового распечатываемого документа (2);

к) имя для итогового распечатываемого документа (2) при передаче его в принимающее агентство в целевой системе проформы.

Все другие поля имеют фиксированные значения.

4.3.6.2    Примитив J-INITIATE-WORK-MAN

В этом примитиве поставщику услуг ПОЗ передается следующая информация:

a)    идентификация инициирования:

b)    имя задания ВОС для обработки;

c)    ВОС-имя-задания для задания ВОС, которое должно выполняться, и тип его подэадания;

d)    имя целевой системы;

e)    идентификация пользователя и пароль для использования в целевой системе;

О имеется ли запрос на выполнение операции КРАТКОЕ ОТОБРАЖЕНИЕ, ОСТАНОВ или УНИЧТОЖЕНИЕ для задания ВОС, которое должно быть выполнено;

g)    имя целевой системы проформы:

h)    идентификация пользователя и пароль для использования в целевой системе проформы, если это требуется;

i)    имя принимающего агентства для документа «отображение—работы (4)* в целевой системе проформы;

j) имя для документа «отображение—работы (4)» при передаче его в принимающее агентство в целевой сисгеме проформы.

4.4    Другие группы примитивов в базовом классе

4.4.1    П р и м ит и в J-D I SPOS Е

Полный набор параметров, определенных в 3.6.2, за следующими исключениями.

Отсутствуют параметры < дополнительные полномочия > и < счет пользователя >. а < параметр агентств;» > имеет значение НУЛЬ. Параметр < диагностическая информация > не содержит значения < итог 11ДУФ >.

Параметр < документ размещения > имеет значение «отображение-работы (4)* (краткое), «отображение-отчета (5)*, «текст (I)* (для исполняющего агентства) или «печать (2)* (ятя принимающего агентства).

4.4.2    П р и м и т и в J-GIVE

Полный набор параметров, определенных в 3.6.3, за следующими исключениями.

Отсутствуют < дополнительные полномочия > и < счет пользователя >. а < параметр агентства > имеет значение НУЛ Ь. Параметр < группа документов > имеет значение < группа конца активности >, а < тип документа > имеет значение «печать (2)».

4.4.3    Другие группы примитивов

Остальные группы примитивов базового класса (J-MESSAGE. J-END-SIGNAL, J-STATUS, J-KILL, J-STOP) содержат полный набор параметров, определенных в 3.6.5, 3.6.7—3.6.9.

4.5    Сводный перечень примитивов и параметров базового класса

Сводный перечень приведен в таблице 4.

69

Страница 75

ГОСТ Р ИСО/МЭК 8831-99

Т а 6 л и и а 4 — Сводный перечень примитивов и параметров ПОЗ базового класса

Примитивы

Запрос

И it дик а и и 12

Ответ

Подтверждение

J-INITIATE

Базовая спецификация перемещения документа

-

Локальный у ка за течь задания ВОС

J-IN1TIATE-WORK-MAN

Базовая спецификация выполнения работы

-

Локальный указатель задания ВОС

-

J-DISPOSE

Идентификатор активности поставщика

Полномочие пользователя

Параметр агентства *= НУЛЬ

Указатель пи документа

Ошибки

Тип документа

текст (1). печать (2),

отображение-работы (4) или

отображение-отчета (5)

Идентификатор активности агентстве!

J-GIVE

Полномочие пользователя

Параметр агентства « ПУЛЬ

Указатель агентства документа

Тип документа ш печать (2)

Группа документов конца активности

Документ и тип документа

J-END-S1GNAL

Идентификатор активности поставщика

-

J- STATUS

Идентификатор активности агентства

-

Сообщение о состоянии

J-KILL

Идентификатор активности агентства

-

J-STOP

Идентификатор активности агентства

-

J-MESSAGE

Идентификатор активности поставщика

-

Сообщение

-

70

Страница 76

ГОСТ Р ИСО/МЭК 8831-99

ПРИЛОЖЕНИЕ А

(обязательное)

Соглашения но услугам 1103

А.1 Введение

ГОСТ Р ИСО/ТО 8509 ограничивается областью двусторонних операций, используемых на сетевом. транспортом, сеансовом уровнях и уровне представления. Данное приложение представляет модель услуг по ГОСТ Р ИСО/ТО 8509 с минимальными изменениями и определяет соглашения по услугам, используемые в ПОЗ.

А.2 Назначение

Данное приложение устанавливает определения терминов и соглашений при определении услуг, обеспечиваемых ПОЗ.

А.З Ссылки

ГОСТ 28906-91 (ИСО 7498—84, Доп. 1—84 ИСО 7498—84) Системы обработки информации. Взаимосвязь Открытых систем. Вазовая эталонная модель.

А.4 Определения

А.4.1 Данное приложение построено но концепциям ГОСТ 28906 и использует следующие определенные в нем термины:

a)    (N) ■= услуга

b)    (N) •= средство;

c)    (N) — уровень.

А.4.2 Для данного приложения применимы также следующие определения:

А.4.2.1 Пшьзоватем услуги — абстрактное отображение ЛО в одной системе, которая использует услугу; любой пользователь услуги может инициировать услугу или ответить на инициирование от поставщика услуг в результате иницирования другою пользователя или пользователей услуг.

А.4.2.2 Поставщик услуг — абстрактный автомат, который моделирует поведение множества ЛО. обеспечивающих услугу, с точки зрения пользователя услуги.

А.4.2.3 Услуга уровня — услуга, обеспечиваемая уровнем эталонной модели.

А.4.2.4 Сервисный примитив; примитив — абстрактный, независимый от PC элемент взаимодействия между пользователем услуги и поставщиком услуги.

А.4.2.5 Запрос (примитив) — примитив, введенный пользователем услуги, чтобы вызвать процедуру (для подтверждаемой или ненодтвсрждасмой услуги) при помощи поставщика услуг.

А.4.2.6 Индикация (примитив) — примитив, введенный поставщиком услуг, чтобы вызвать некоторую процедуру (для подтверждаемой или ненодтвсрждасмой услуги) пользователем услуги.

А.4.2.7 Ответ (примитив) — примитив, введенный пользователем услуги, чтобы завершить процедуры, связанные с подтверждаемой услугой.

А.4.2.8 Подтверждение (примитив) — примитив, введенный поставщиком услуг, чтобы завершить процедуры. связанные с подтверждаемой услугой.

А.4.2.9 Пункт доступа к сервисному элементу — концептуальный пункт, в котором имеют место взаимодействия между поставщиком услуг ПОЗ и агентством ПОЗ.

А.5 Модель ПОЗ

ПОЗ определяется в терминах абстрактной модели (см. рис. А. 1), которая имеет следующие элементы:

a)    пользователи услуг ПОЗ;

b)    поставщик услуг ПОЗ.

Отме тим, что использование термина «пользователи услуг» для ПОЗ не означает наличия более высокого уровня. Он просто предоставляет обозначение соглашения для описания взаимодейст вия с агентствами ПОЗ.

Каждый пользователь услуг взаимодействует с поставщиком услуг при помощи выдачи или получения СП. Служба определяет отношения между взаимодействиями с одним пользователем услуги и последующими взаимодействиями с одним или несколькими другими пользователями услуг.

А.6 Сервисные примитивы

Использование примитивов не препятствует любым специфическим PC' службы использовать термины интерфейсных примитивов. Следующие комментарии применяются для такого метода определения, основанного на СП:

a)    СП являются концептуальными и не относятся непосредственно к элементам протокола и не рассматриваются как обращения макрокоманд метода доступа к услуге;

b)    имеются другие эквивалентные наборы СП. которые могут описывать такую службу;

71

Страница 77

ГОСТ Р ИСО/МЭК 8831-99

с) учитываются только тс СП. которые соответствуют некоторому элементу услуг, в котором участвуют другие пользователи услуг. Примитивы, относящиеся только к локальным соглашениям между пользователем и поставщиком услуг, не относятся к этому методу описания. Например, строго локальные функции могут быть обеспечены в некоторых PC. Когда они не вызывают других пользователей, такие функции являются невидимыми вне локальной системы.

^    Агентства    11    •    •    •    •    •

Рисунок A. I — Модель службы

А.6.1 Типы услуг Имеется два типа услуг:

а) неподтвержласмая услуга, включающая в себя

1)    один примитив запроса (см. A.4.2.S) и один или несколько примитивов индикаиии (см. А.4.2.6) в различных пунктах доступа к сервисному элементу;

2)    один или несколько примигивов индикаиии в различных пунктах доступа к сервисному элементу;

Ь> подтверждаемая услуга, включающая в себя

1> один примитив запроса (см. А.4.2.5);

2)    один или несколько примитивов индикации (см. А.4.2.6) и один или несколько примитивов отвега (см. А.4.2.2) — оба в различных пунктах к сервисному элементу из перечисления I);

3)    один примитивов подтверждения (см. А.4.2.8) в том же пункте доступа к сервисному элементу, как представлено в перечисления 1).

А.6.2 Свойства примитивов

Наличие СП является логически отдельным и неделимым событием. Это событие имеет место в логически отдельном экземпляре, который не может быгь прерван другим событием.

СП передается в направлениях:

a)    от пользователя услуги к поставщику услуг:

b)    от поставщика услуг к пользователю услуг.

С каждым СП могут быгь связаны один или несколько параметров и каждый из этих параметров имеет определенный набор значений. Значения параметров, связанных с СП. передаются в направлении передачи СП.

А.6.3 Имена примитивов Имя каждого СП содержит гри элемента:

a)    начальное имя (или имена), указывающее услугу (см. А.8.1);

b)    общее имя, указывающее группу примитивов (см. А.8.2);

c)    специфическое имя, указывающее тип примитива (см. А.8.3).

А.6.4 Группы примитивов

Наличие группы СП не яачяется логически одновременным и неделимым событием. Интервалы между составляющими СП могут быгь неразрывно заполнены другими СП.

Группа, которая включает примитивы, отображающиеся в примитивы СИВ. называется группой исполнения. или, иначе творя, поименованы как примитивы, например: группа исполнения J-INITIATE группа исполнения J-DISPOSE.

А.7 Временные диаграммы Указывают:

a)    последовательность взаимодействий с пользователем услуги;

b)    в необходимых случаях последовательность событий между двумя или несколькими пользователями

услуг.

72

Страница 78

ГОСТ Р ИСО/МЭК 8831-99

Каждая диаграмма содержит одну или несколько вертикальных линий, отображающих взаимодействие между поставщиком и пользователем услуг (пункт доступа к сервисному элементу); для пользователя инициирующего объекта или ГУЛ О (исполнения) левая от линии область отображает пользователя услуг, а правая — поставщика услуг; в других случаях поставщик услуг представляется областью слева от линии, а пользователь услуг — справа.

Стрелки, помещенные в областях, представляющих пользователя услуг, указывают направление прохождения примитивов. Угол, под которым проведена стрелка в поле, не имеет значения.

Получатель 2

Запросчик

Получатель 1

Запрос

\|„------------------,

Индикация    Индикация

Пользователь 1    Пользователь    2    Пользователь    3

к:

Л

Индикация

к

Индикация

Индикация

Рисунок А.2 — Нсиодтверждаемые услуги Ответчик 1

Запрос

Инициатор

Ответчик 2

Инициатор

Запрос

Ответчик 1

Ответчик 2

Подтверж

дение

Рисунок А.З — Подтверждаемые услуги


>


Индикация


73

Страница 79

ГОСТ Р ИСО/МЭК 8831-99

Необходимая последовательность связей между взаимодействиями указывается горизонтальной пунктирной линией. При отсутствии временных зависимостей пунктирной линии не должно быть. В этом случае все примитивы для одного взаимодействия могут иметь место после или перед всеми примитивами для некоторого другого взаимодействия или чередоваться с ними.

Пунктирная линия может содержать конец стрелки или острие стрелки в каждом пункте доступе к сервисному элементу. Все взаимодействия, расположенные выше всех концов стрелки, необходимо выполнять до всех взаимодействий, расположенных ниже любого острия стрелки.

А.7.1 Примеры не подтверждаемых услуг Возможны все последовательности, показанные на рисунке А. 2.

А.7.2 Примеры подтверждаемых услуг

Возможны все последовательности, показанные на рисунке А.З; следует заметить, что во втором случае поставщик услуг принимает ответственность за завершение услуги и проверяет доступность некоторого механизма службы отчетности об ошибках, обычно путем включая последующий примитив индикации для того же самого или другого пользователя услуги.

A.S Соглашения по наименованиям сервисных нрнмшнвок А.8.1 Инициалы

Следующие инишшлы используются для указания услуг, обеспечиваемых уровнями ВОС:

F    -    служба ПДУФ;

J    —    служба ПОЗ;

V — службы ВТ (виртуальные терминалы);

С    -    служба СИВ:

А — услуги других прикладных систем;

Р    —    услуги уровня представления;

S    —    услуги сеансового уровня;

Т — услуги транспортного уровня;

N — услуги сетевого уровня;

DL — услуги звена данных:

Ph — услуги физического уровня.

Примечание — Использование инициала N дли обозначения услуг сетевого уровня не следует путать с использованием символа (N) для обозначения конкретного, но неопределенного уровня модели.

А.8.2 Общее имя

Одно слово или слово, написанное через дефис, используется для общего имени, например. ИНИЦИИРОВАНИЕ, РАЗМЕЩЕНИЕ, КОНЕЦ-СИГНАЛ.

А.8.3 Конкретное имя

Конкретное имя содержит одно из следующих (указывающих тин примитива или группу примитивов):

a)    запрос:

b)    индикация;

c)    ответ;

d)    подтверждение;

с) группа исполнения.

А.8.4 Представление

Инициал представляется в форме, приведенной в А.8.1. Общее имя записываегся прописными буквами, конкретное — строчными.

Инициал и общее имя разделяются черточкой. Общие и конкретные имена разделяются пробелами. А.8.5 Пример ы

Ниже приведены примеры имен параметров, образованные с использованием указанных соглашений:

a)    J-INITIATE запрос;

b)    J-KILL индикация;

c)    J-DISPOSE группа исполнения.

74

Страница 80

ГОСТ Р ИСО/МЭК 8831-99

ПРИЛОЖЕНИЕ В (обязательное)

Регистры типов документов

В.1 Введение

Организация может пожелать установить регистр типов документов личного пользования или регистрировать тип документов в Регистре ИСО типов документов.

Данное приложение определяет информацию, которая запрашивается ПОЗ для элемента регистра, обеспечивающего типы документов, поддерживаемые ПОЗ.

В.2 Назначение элемента

Назначение элемента состоит в обеспечении:

a)    идентификации типа документа;

b)    определения (возможно, при помощи указателя) семантики и абстрактного синтаксиса документа, который стандартизован для этого типа;

c)    определения (возможно, при помощи указателя) одного или нескольких синтаксисов передачи для типа документа;

d)    определения правил сцепления для типа документа.

ВЗ Идентификация

Тип документа идентифицируется значениями ИДЕНТИФИКАТОР ОБЪЕКТА и ОписательОбъекта ACH.I. назначаемыми согласно правилам ГОСТ Р ИСО/МЭК 8824.

В.4 Семантика документов

Семантика, которая стандартизуется, может быть очень полной, поскольку имеется тип документов, определяемых для обеспечения отображений ПОЗ. Для других типов документов семантики могут быть только частично стандарт изо ваны. Примером этого является тип документа «простой текстовый документ ИСО» (см. ИСО/МЭК 8832). который стандартизован только для строк графических знаков.

Типы документов с повышенно определенными семантиками могут формировать специальный тип документов с меньшим определением. В этом случае они могут разделять один и тот же синтаксис передачи.

Абстрактный синтаксис типа данных, обеспечивающих передачу семантик типов документов, определяется и именуется в соответствии с требованиями ГОСТ 34.971 для наименований абстрактных синтаксисов.

В.5 Синтаксис передачи

Если соединение возможно, необходимо иметь соглашение по синтаксису передачи, который должен использоваться для каждого типа документа. Это соглашение может быть двусторонним, специальным для определенной организации или представленным в виде стандарта.

Элемент pci истра определяет либо непосредственно, либо путем ссылки на правила кодирования точный набор битов, который должен быть использован для передачи одного значения сервисных данных уровня представления (см. ГОСТ 34.971). которые должны содержать семантики документов (для передачи базового класса) и точный набор битов, который должен использоваться для передачи ряда Значений сервисных данных уровня представления в тех случаях, когда расширенные PC' обеспечивают передачу.

Примечание— Ни ПОЗ, ни служба уровня представления не налагают никаких ограничений на форму спецификации или на кодирование для абстрактного синтаксиса или синтаксиса передачи, за исключением того, что в базовом классе для каждого документа передается только один набор битов.

Синтаксис передачи для типа документа получает имя в соответствии с требованиями ГОСТ 34.971 для наименований синтаксисов передачи.

Примечание — Приведенный выше текст допускает одно имя абстрактного синтаксиса для всех значений данных, используемых при формировании типа документа, и один синтаксис передачи для такого абстрактного сикгаксиса. Это ограничение рекомендуется, но не является обязательным требованием ПОЗ. Возможна полная общность уровня представления при использовании различных абстрактных синтаксисов для каждого значения данных и для имеющихся значений вложенных данных из различных абстрактных синтаксисов, поскольку имеется возможность выбирать из числа синтаксисов передачи, обеспечивающих каждый абстрактный синтаксис.

75

Страница 81

ГОСТ Р ИСО/МЭК 8831-99

В.6 Взаимоотношения синтаксиса и семантики

Возможно (но маловероятно) для двух полностью различных абстрактных синтаксисов и. соответственно. с полностью различными семантиками сформировать для передачи одинаковые битовые комбинации при использовании различных правил кодирования.

Также возможно (и более вероятно) для двух полностью различных типов документов с различными семантиками разделять общий абстрактный синтаксис.

Таким образом, в общем случае невозможно установить происхождение абстрактного синтаксиса из синтаксиса передачи или установить происхождение семантики документа (типа документа) из абстрактного синтаксиса или синтаксиса передачи.

Однако для заданного типа документа можно установить (из элемента регистра) один или несколько возможных абстрактных синтаксисов, а из них установить один или несколько синтаксисов передачи.

Правильная интерпретация полученных последовательностей битов (синтаксис передачи) требует знания правил кодирования, которые были использованы для формирования битов. Правильная интерпретация абстрактного синтаксиса также требует знания используемых семантик.

Протокол ПОЗ явно содержит имя тина документа с каждым документом, определяя таким образом все стандартизованные аспекты семантик. Если доступно несколько синтаксисов, то использование конкретного синтаксиса передачи согласовывается при использовании услуг уровня представления.

В.7 Синтаксические соглашения

Протокол ПОЗ определяется использованием нотации ACH.I абстрактного синтаксиса, но такое ограничение не налагается на типы документов.

Каждый документ представляется как отдельное значение данных уровня представления, и все проблемы разделения документов и выравнивания до восьми символов решаются службой уровня представления.

В.К Содержимое решетра

Каждый элемент регистра содержит информацию, определяемую в последующих подразделах.

В.8.1 Идентификатор типа документа

Представляет собой значение ИДЕНТИФИКАТОР ОБЪЕКТА и ОнисатсльОбъекга АСН.1.

В.8.2 Семантики документов

Определение (непосредственно или путем ссылки на другой стандарт) тех частей общих семантик, которые стандартизованы для ЭТОГО типа документа.

В.8.3 Синтаксисы документов

Определение (непосредственно или путем ссылки на другой стандарт) одного или нескольких синтаксисов передачи (возможно, через один или несколько абстрактных синтаксисов и правил кодирования), которые должны обеспечивать семантики документов.

Еслз! указывается множество синтаксисов передачи, то один из них выбирается как минимальное требование PC для аттестуемых систем, претендующих на обеспечение данного тина документа.

В.8.4 Имена синтаксисов

Синтаксису передачи и абстрактному синтаксису присваивают имена для обеспечения передачи документа так же. как и одному (для базового класса ПОЗ) или нескольким (расширенного класса) значениям сервисных данных уровня представления (см. ГОСТ 34.971).

В.8.5 Сцепление

Это оператор, при помощи которого типы документов могут быть включены в операцию сцепления:

А сцепить с В, чтобы получить С и который содержит определение операций в каждом случае.

Примечание — Наиболее распространен случай, когда документы А. В и С имеют один и тот же тип.

В.8.6 Дополнительная и нформац и я

Дополнительная информация может потребоваться, если тип документа должен использоваться в других протоколах, но не требуется для ПОЗ.

76

Страница 82

ГОСТ Р ИСО/МЭК 8831-99

ПРИЛОЖЕНИЕ С (справочное)

Консультативный материал

С.1 Введение

Первоначально работа ПОЗ была предназначена для обеспечения удаленной автономной обработки. Однако она никак не вписывается в стандартизованный ЯУЗ и в модель какой-либо информации, которая образует «обработку».

ПОЗ распознает запрос на передачу (прозрачную) документов в систему для «обработки» вместе с информацией. которая позволит этой сисгсмс правильно размешать документы, образующиеся в результате «обработки*.

Документы могут представлять собой традиционные задания на ЯУЗ. программы и данные, а «обработка» может вызывать формирование очереди для действия типа «выполнение -задания». С другой стороны, документы могут быть посланиями с вложениями, а «обработка» может выполняться человеком. Третьим возможным вариантом является обмен документами или запросами для повторной передачи, а «обработка» может вызвать немедленное планирование или диспетчирование работы с выходными документами, являющимися счетами или управляющими операторами или уведомлением ожидаемых времен поступления.

ПОЗ имеет дело с так называемыми «заданиями ВОС*. Их не следует путать с традиционными «заданиями», обрабатываемыми в одной машине.

Выполняемая работа ПОЗ. т. с. задание ВОС', состоит в перемещении документов (файлов) между oi-крытыми системами, паузы для тех документов, которые должны быть обработаны открытыми системами (прозрачно для ПОЗ), затем перемещение документов, полученных в результате этой обработки и так далее.

Обработка, которая должна быть выполнена, не входит в сферу интересов ПОЗ. Она касается исключительно документов. которые она доставляет, и обычной передачи дальнейших выходных документов. Обработка может быть произведена традиционным способом «выполнение задания» (при котором один из документов, передаваемых ПОЗ, должен быгь в форме ЯУЗ). или некоторым прикладным специфическим процессом, таким как процесс обработки заказов и распределения товаров. Обработка может выполняться даже полностью вручную при выдаче человеком службе ПОЗ сообщения о том, что выходные документы доступны и что работа задания ВОС может выполняться.

С.2 Лрхюсктура

«Архитектура» ПОЗ включает в себя концепцию так называемого «инициирующего агентства» — как правило, но не обязательно, — представляющего оператора. Это агентство определяет возможные образцы перемещения документов, открытые системы, которые должны использоваться, и источники поступления начальных доку ментов. Все перечисленное указывается в так называемой «спецификации работы». Понимание ПОЗ почти полностью даст понимание очень широкого набора активностей, которые могут быть указаны в СР.

СР создастся поставщиком услуг ПОЗ из параметров СП J-1N1TIATE. После этого ПОЗ полностью принимает на себя ответственность за выполняемую активность. Основной особенностью разработки протокола ПОЗ является то. что ответственность за обработку СР передается от одной открытой системы в другую от крытую систему. Открытой системе, в которую был введен примитив J-INITIATE, нет необходимости сохранять активность, как только первая часть его будет завершена, а ответственность передана.

Обычно элементы протокола (называемые элементами передачи), содержащие некоторую или всю информацию в СР. передаются открытым системам, каждая из которых выполняет некоторую часть запрошенной активности — предоставление документа, доступ к документу для печати, формирование файла или отображение пользователю, обработка одного или нескольких документов и тому подобное.

С.2.1 Использование СИВ

Вся активность ПОЗ (СП и передачи протоколов) выполняется в пределах Одного или нескольких элементарных действий СИВ. Это даст полную защиту от сбоев прикладных систем и сбоев связи, давая в результате гарантию отсутствия потерь и дублирования для требуемой работы.

С.2.2 Агентства ПОЗ

Стандарты ПОЗ распознают не только инициирующее агентство (определяющее работу путем использования примитива J-INITIATE), но также агентства, доступные при помощи услуги ПОЗ (через последующие СП) для включения работы, которая должна быть выполнена. Это описывается в следующих подпунктах.

С.2.2.1 Исходные агентства

«Исходное агентство» ПОЗ становится доступным для поставщика услуг ПОЗ посредством СП J-G1VE. Этот СП выдается (как результат запросов в С'Р). чтобы запросить названный документ из исходного агентства. Исходное агентство обычно моделирует условное локальное хранилище файлов, но оно может также моделировать некоторую работающую программу, оператора, которого запросили загрузить магнитную ленту, или обработчика ПДУФ, получившего документ удаленным способом. Следует заметить, что на открытые систе-

77

5— I— J04K

Страница 83

ГОСТ Р ИСО/МЭК 8831-99

мы, в которых могут выдаваться примитивы J-GIVE, ПОЗ не налагает никаких ограничений. Открытая система А может выдать примитив J-INITIATE, предназначенный для обработки некоторых документов в открытой системе В, а примитивы J-GIVE, предназначенные для получения начальных документов, могут быть выданы

в открытой системе А. открытой системе В или в полностью отдельных открытых системах С. D, Е____Протокол

ПОЗ упорядочивает необходимые запросы и документы, которые должны быть переданы между системами.

С.2.2.2 Принимающие агентства

«Принимающее агентство» ПОЗ становится доступным для поставщика услуг ПОЗ посредством СП J-DISPOSE. Этот СП выдастся, чтобы запросить агентство разместить документ, представляемый услугой (обычно полученный при помощи более раннего примитива J-GIVE). Это размещение может (в зависимости от агентства) быть в файле, на печатной строке, на графопостроителе, в качестве корогкого сообщения в ♦почтовый яишк» пользователя, сообщения оператору, сигнала в работающую программу и так далее. Так же, как и для примитива J-GIVE. на место выполнения примитива J-DISPOSE не налагается никаких ограничений (определяется полномочиями, обсуждаемыми ниже).

С.2.2.3 Исполняющие агентства

«Исполняющее агентство* ПОЗ также становится доступным при помощи С'П J-DISPOSE. Различие между ним и принимающим агентством состоит в том. что исполняющее агентство имеет возможность формировать новые документы при поступлении (используя примитив J-GIVE) как часть активности, стимулированной примитивом J-DISPOSE. Оно формирует элемент -обработки» в н yip и модели ПОЗ.

С.2.3 Уровень и с п о л нения

ПОЗ использует так называемый механизм «уровень исполнения» в примитивах СИВ. Элементарное действие, содержащее иримигив J-DISPOSE для принимающего или исполняющего агентства, может завершиться с уровнем исполнения:

-    ЗАВЕРШЕНИЕ; в этом случае все запрошенные активности (печать или обработка документа) завершаются до выдачи сообщения об исполнении;

-    ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА; в этом случае поставщик услуг ПОЗ просто запоминает (с зашитой, на диске) сохраняемые запросы в С'Р и ожидает сигнала от агентства (СП J-END-SIGNAL) о завершении активности.

Если имеет мссго уровень исполнения ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА, тогда через некоторое время (возможно, в результате вмешательства оператора, указывающего, например, что работа была отправлена) агентство выдаст иримигив запроса J-END-SIGNAL для информирования поставщика услуг ПОЗ о завершении раСюты. Если агентство было исполняющим, оно теперь можег выдать примитивы J-GIVE. чтобы собрать документы, и указанная ёРработа продолжается.

С.2.4 Размещение новых документов

Документы, сформированные исполняющим агентством, будут должным образом передаваться в другие принимающие или исполняющие агентства последующими примитивами J-DISPOSE. Таким образом ПОЗ обеспечивает произвольную (неограниченную, потенциально бесконечную) последовательность активностей J-GIVE/J-DISPOSE. J-GIVE/J-D1SPOSE (см. рисунок С.1). Следует заметить, что эго является процессом ответвления. причем каждое ответвление выполняется асинхронно.

ШНАЛО - иии» wiiifc (шищпнО ц щп мин hiImwoii да кгшъноЯ CP (J -1MTVCTE)

ОййпД>«м * ffiana BQC СР и Опрадта■ i — wi и OtewOt ий 1^*адио» ■thicvhp (j-амЕ)

1 I Г

Порот* СР И ичннют нашорых <хыпск н»кфцдн99 ■питало &J-OIVE)    I    |_

1

Обработка СР для р—ннциш дцнмпв в rj—■■■■ipn m меютмяде тнгслас (J - IMPOSE)

Имиин работа дшмкитнж    Нот работ дтмтпямн

Ощщмвтм1сРпоат1«мш    КОНЕЦ^ЭТОГО

услуг ГЮЭзскрваапмюмноюторыд    ОТВЕТВЛЕНИЯ

овьекж не но*»*» еенгето У-ЯУЕ)

_I

Рисунок C.I — Иллюстрация обработки СР

78

Страница 84

ГОСТ Р ИСО/МЭК 8831-99

С.2.5 Обеспечение неавтономной обработки

Активность, запрошенная по примитиву J-INITIATE. может быть выполнена «-автономно», как описано выше. Если, однако, инициирующее агентство запрашивает' в примитиве J-INITIATE уровня исполнения СИВ ЗАВЕРШЕНИЕ, то полная активность выполняется немедленно (или вообше не выполняется) при получении соответствующего ответа на примитив J-INITIATE.

С.2.6 Последовательность примитивов

Активность, запрашиваемая инициирующим агентством, в общих случаях вызывает древовидную структуру СП типа «J-», которые лолжны выдаваться, возможно, параллельно, возможно, последовательно в нескольких различных системах. Эти примитивы выдаются как часть одного или нескольких элементарных действий (в зависимости от требуемого уровня исполнения). Некоторые примеры приведены в С. 16.

С.З Служба отчетности

Как часть СР. определяемой примитивом J-INITIATE. инициирующее агентство определяет один или несколько пунктов монитора и одну или несколько категорий отчетности. ПОЗ формирует отчеты (документы, содержащие определенные ПОЗ форматированные данные), когда имеет место какое-либо событие таких категорий. Категории отчетности включают завершение части работы, передачу между системами ответственности за выполнение работы, информацию учета и. что более важно, ошибки в спецификации, которые препятствуют дальнейшему выполнению работы. (Такие ошибки могут вызывать либо отказ от выполнения оставшейся работы или. в зависимости от того, что указано в СР. просто приостановить выполнение для корректирующих действий).

С.З.I Доставка и размещение

Все запрошенные отчеты доставляются (используя протокол почти идентичный тому, который используется для выполнения основной работы) в открытые системы, содержащие указанные пункты монитора. В настоящее время используются два способа:

-    отчет включается в документ и примитив J-DISPOSE выдается в принимающее агентство в пункт монитора, что обычно приводит к выводу отчетного документа на печатающее устройство или к его отображению;

-    отчет сохраняется (с защитой, на диске) поставщиком услуг ПОЗ; оно может быть запрошено из другой открытой системы последующей инициативой (человеком), как описано ниже.

С.3.2 Ответственность за отчетность

Для каждой категории отчетов ответственность за формирование СР для доставки и размещения отчетов остается за одной определенной открытой системой в древовидной структуре элементарных действий СИВ. Открытая система указывается в спецификации протокола ПОЗ и описывается в основной части этого текста.

Некоторые отчеты (например отчеты о создании СР. о передаче ответственности за нее, о нормальном завершении) выдаются как часть основного элементарного действия СИВ. выполняющего работу. Они передаются только если это действие выполняется, в противном случае они подвергаются возврату в первоначальное состояние. В терминах СИ В они являются частью связанных данных действия.

Другие отчеты (например отчеты учетной информации, о попытках нарушения зашиты или об отказе элементарного действия, формируемые при помоши открытой системы, содержащей ГУ.ТО исполнения) выдаются как отдельные элементарные действия. Эти отчеты передаются даже в том случае, если основное элементарное действие возвращается в первоначальное состояние.

С.4 Обработка

После выдачи примитива J-INITIATE возможно продолжение выполнения работы без дальнейшего взаимодействия с человеком. Болес типично, олнако. котла дальнейшее взаимодействие с человеком осуществляется для того, чтобы:

-    отобразить текущее состояние нрелостааченных ранее СР;

-    модифицировать СР. возможно для коррекции ошибок, о которых был послан отчет пунктам монитора;

-    опросить пункты монитора, которые сохраняют отчеты, как описано в С.З.I;

-    обеспечить контроль оператора над планированием различных передач, по которым услуга ПОЗ выполняет завершение предоставленных ей СР.

Такие взаимодействия также выполняются инициирующим агентством (любым). Кроме того агентство обеспечивает информацию для СР. но требуемой работой теперь является одна из перечисленных выше операций. Кроме того, агентство может предпочесть установить режим «автономной* активности или (что более типично для подобных случаев) потребовать уровень исполнения ЗАВЕРШЕНИЕ в примитиве J-INITIATE.

С.5 Примитивы J-INITIATE

СП, предоставляющий обычную СР. называется J-1N1TIATE-WORK. Примитив, запрашивающий отображение иди модификацию СР. называется J-INITIATE-WORK-MAN. («MAN* означает обработку). Примитив при помоши которого выпатняется опрос пунктов мониторов, называется J-INITIATE-REPORT-MAN. Примитив, выполняющий управление передачами, называется J-INITIATE-TCR-MAN. («TCR* означает ЗУП): управление передачами описано в С. 11.6).

Во всех случаях примитива J-IN1T1ATE запрошенная активность описывается при помоши СР (какого-либо типа). Все типы СР содержат рял глобальных полей, относящихся к полномочию, идентификации и

79

5-1*

Страница 85

ГОСТ Р ИСО/МЭК 8831-99

защите информации. Они формируются из параметров примитива J-INIT1ATE, обеспечиваемых информацией. поставляемой поставщиком услуг ПОЗ для формирования, гак называемых, «параметров задания ВОС». Эп1 параметры содержатся в протоколе для всех передач ПОЗ, связанных с этой СР. (включая перемещение отчета) и служат для координации всей активности. Эти ноля СР описываются в С.9 после вводного описания некоторых концепций.

С.6 Присвоение имен

ПОЗ распознает два типа назначаемых объектов, которые требуют (повсеместно) присвоения однозначных имен. Один из них идентифицирует PC' ПОЗ. Такие имена предполагают вид (ПОЗ) «символическое-имя-прикладного-ло», как описано и дополнении к базовой эталонной модели в части адресании. Второй тип ПОЗ называет «имена-уполномоченного-по-идентификации-пользователя». Они используют ту же область имен, что и «символическое-имя-прикладного-ло», и представляют источника идентификаций пользователя. Часто такие идентификации пользователя вводятся для использовании внутри одной вычислительной (открытой) системы. В этом случае одно значение «символ ическое-нмя-прикладного-ло» может трать обе роли. В других случаях одна вычислительная (открытая) система может иметь более одного набора идентификаций пользователя. или. возможно, в более общем случае, один набор идентификаций пользователя может быть введен для включения нескольких вычислительных (открытых) систем. Целью работы по присвоению имен и адресации является обеспечение уникальности каждого «символичсского-имсни-прикладного-ло» на всемирной основе. Повсеместная уникальность идентификаций пользователей и идентификаций СР следует из того, что именно такие имена присваиваются этим идентификациям.

С.7 Аутентификация

Механизмы однозначного присвоения имен не решают проблем «маскирования», когда система или иатьюватель преднамеренно используют имя. присвоенное какой-либо другой системе или пользователю. «Маскирование» предотвращается соответствующим механизмом аутентификации. ПОЗ распознает три механизма. которые могут применяться для достижения аутентификации.

С. 7.1 И н ф о р м а и и я з а щ и т ы

Первый из этих механизмов, традиционно применяемый к идентификациям пользователей, заключается в использовании на ратей или средств засекречивания информации, известной только уполномоченному по аутентификации и объекту, подлежащему аутентификации, Этот механизм приводит к использованию:

-    паролей, которые должны передаваться и, следовательно, эти пароли уязвимы для пассивных перехватов сигналов (незаконные приемники, наблюдающие за сетью);

-    паролей, которыми должны обладать поставщики услуг ПОЗ для использования в санкционировании последующих примитивов J-DISPOSE и J-G1VE) в течение длительного периода времени; это нежелательно в связи с трудностями изменения паролей.

Вывод состоит в том, что использование паролей в идеальном случае должно быть ограничено зоной зашиты или строками защиты, а также теми применениями где отсутствуют автономные активности.

С.7.2 Оценки доверительности третьей стороны

Второй механизм зашиты заключается в том, чтобы аутентифицировать источник обмена данными (заявленное им имя открытой системы) при поступлении данных, а затем «доверить» их известным открытым системам, которые аутентифицированы. Это «доверие» позволяет получателю воспринимать от отправителя утверждения о том. что идентификаторы, участвующие в обмене данными, уже проверены — т. с. то. что в 1103 называется как «уже проверенный признак». ПОЗ распознает три уровня аутентификации вызывающей системы; эти уровни и характер прикладной программы определяют, должно ли иметь место такое «доверие». (Фактические имена открытых систем, которые должны быть «доверительными» на каждом уровне, могут быть изменяемы в PC ПОЗ). Этими уровнями являются:

-    НЕИЗВЕСТНЫЙ

-    ИЗВЕСТНЫЙ

-    АУТЕНТИФИЦИРОВАННЫЙ

Открытая система с уровнем НЕИЗВЕСТНЫЙ являлся системой, где при обмене данными вызывающему известны только собственный оператор вызова. В некоторых случаях (внутри единой монолитной зоны зашиты информации или при невысоких требованиях к защите информации, например, при выводе на печатающее устройство) этого может оказаться достаточно. Открытая система с уровнем ИЗВЕСТНЫЙ — это система, для которой сама сеть обеспечивает адекватный уровень зашиты информации для прикладной программы и обеспечивает аутентификационный сетевой адрес, который может быть использован для проверки правильности имени вызываемой открытой системы. Это обычный уровень аутентификации, применяемый в настоящее время к основной массе банковских коммерческих графиков. Открытая система с уровнем АУТЕНТИФИЦИРОВАНО — это система, для которой методы криптографического кодирования используются с целью зашиты обмена данными от вмешательства в данной открытой системе. Определенные протоколы нижнего уровня, которые должны использоваться для получения этого самого высокого уровня аутентификации, находятся вне области ПОЗ и результаты работ по обеспечению зашиты информации в ВОС только ожидаются.

С.7.3 Расширение до многосторонних операций

Третий механизм, используемый ПОЗ. состоит в обеспечении так называемой «проверочный трассы». Эго список имен открытых систем, каждая из которых помечена как АУТЕНТИФИЦИРОВАННАЯ.

Страница 86

ГОСТ Р ИСО/МЭК 8831-99

ИЗВЕСТНАЯ или НЕИЗВЕСТНАЯ. Если ответственность за выполнение (части) СР ПОЗ передается из одной открытой системы (скажем. А) в другую открытую систему (скажем. В) система А добавляет свое имя в конец проверочной трассы с пометкой НЕИЗВЕСТНАЯ. При получении система В может изменить этот признак на АУТЕНТИФИЦИРОВАННАЯ или ИЗВЕСТНАЯ. Эта проверочная трасса представляет сущность всей защиты ПОЗ от «маскирования». Все при знаки «уже проверено» в идентификациях пользователей определяют элемент в проверочной трассе, о котором известно, что проверка уже выполнена. При условии, что сторона известна и «доверяет» всем именам в этой проверочной трассе (с допустимым уровнем аутентификации в каждом пункте). допускается включение признака «уже проверено» в идентификации пользователя.

При обычной операции ответвленная сторона может «доверить» главной стороне (но не наоборот). Ог-ветвленная сторона может проверить (локально) идентификацию пользователя во время выполнения примитива J-INITIATE и ввести признаки «уже проверено». Если несколько позже главная сторона возвращает ответственность за оставшуюся часть СР обратно для выполнения примитива J-DISPOSE. идентификация пользователя с признаком «уже проверено» доступна для полномочия введенной активности. (Иллюстрация этих механизмов приведена в подразделе С.20).

С.7.4 Подлинность инициатора

Проверочная трасса играет также роль при обнаружении «маскирования» при заявленной подлинности инициатора СР. Эго важно из-за наличия другого свойства защиты в ПОЗ. Одной из категории отчетов, которая может быть выбрана, является отчет о попытках несанкционированных попыток (со стороны другой СР. например, сисгемы В) модифицировать данную СР (например систему А). О такой попытке, подлинности инициатора системы В. времени предоставления и о полной проверочной трассе системы В необходимо послать уведомление в пункты монитора сисгемы А.

С.8 Терминология ПОЗ

ПОЗ использует термин «задание ВОС» для полной активности, указанной примитивом запрос:! J-IMTIATE.

Задание состоит из начального «ползадании», которое может быть «иодзаданием перемещения документа». «подзаданием выполнения работы*, «под-заданием обработки запроса» или «иодзаданием управления передачами». Эти спецификации подзаланий могут содержать проформы, которые указывают тип подзада-ния. и др.

Открытая система, в которой для определенного задания ВОС выдается примитив J-INITIATE. называется «системой предоставления задания ВОС».

Термин «обработка» означает как модификацию СР (или удаление отчетов), так и отображение СР или отчетов.

Семантика рабогы. которая должна выполняться ПОЗ (включая порождение новой работы из проформы), называется «спецификацией работы». Выполнение обшей работы называется заданием ВОС. разбиваемой на ползадания ВОС. Протокольный блок данных (ПБД) ПОЗ, содержащий детали СР или ее части (для передачи ответственности за нее другой открытой системе), называется элементом передачи.

С.9 Параметры заданий ВОС

Ниже описываются так называемые «параметры задании ВОС*.

Параметр «идентификация отправителя» представляет собой имя открытой сисгемы (всегда равное первому элементу в проверочной трассе после начальной передачи) и идентификацию пользователя (содержащую имя «уполномоченного по идентификации пользователя», которое может быть таким же. как имя данной открытой системы или отличным от него). Этот параметр обеспечивает значения идентификации для службы отчетности и для проверок защиты информации, описанных в С.7.4, но не используются в полномочиях активности. Он предоставляется поставщиком услуг ПОЗ в точке входа.

Параметр «дата и время предоставления» предстаатяет собой время выдачи примитива запроса J-IMTIATE и обеспечивается поставщиком услуг ПОЗ.

Парамет р «имя-задания-ВОС» содержит прозрачную строку (любой длины, любого набора знаков), обеспечиваемую инициирующим агентством в примитиве J-INITIATE. Имя дополняется уникальным указателем, сформированным открытой системой, которая осуществляет инициирование, и дополнительными полями, которые служат для идентификации различных частей активности, когда она начинает ответвление. Этот так называемый «список-имсн-иодзадания» добавляется в процессе продолжения работы так, что каждая часть активности идентифицируется траекторией через древовидную структуру активности к данной части работы. Доба&тясмыс имена называются "именами-проформы*, описываемыми ниже.

Параметр «проверочная трасса» описан в С.7.3 и формирует основу механизмов защиты информации

ПОЗ.

Параметр «монитор задания ВОС» содержит Спецификацию так называемого «первичного монитор;!», обеспечиваемую поставщиком услуг ПОЗ в инициирующей открытой системе. (Изменения здесь потребуют больших полномочий, чем изменения в так называемых, «вторичных мониторах»). При выдаче примитива J-IN ITIATE агентство может обеспечить от одной до нескольких спецификаций вторичных мониторов. Каждая спецификация монитора дает те категории служб отчетности, которые требуются, и параметр «имя открытой системы» (пункт монитора), в которую должны быть посланы отчеты о результатах выполнения рабогы. Спе-

& 1

2-1041

Страница 87

ГОСТ Р ИСО/МЭК 8831-99

цификапия также указывает, должны ли отчеты удерживаться пунктом монитора (см. С.3.1), или обеспечивает подробную информацию о принимающем агентстве, для которого должен быть выдан примитив J-DISPOSE.

Паче «параметры защиты» обеспечивается в примитиве J-INITIATE и используется для определения уровня зашиты информации, необходимого при выполнении функиий ПОЗ по обмену данными относительно данной СР. Значения этих параметров к настоящему времени не определены, поскольку не завершены работы по защите информации В ОС и по обеспечению соответствующих параметров в услугах уровня представления или через обший сервисный элемент прикладного уровня (ОСЭП). Наиболее вероятны следующие значения:

-    защита не требуется;

-    требуется обнаружение несанкционированного вмешательства;

-    требуется зашита от разрушения.

Олнако работы по этом вопросам еще не завершены и не входят непосредственно в сферу ПОЗ.

Поле «список полномочий* содержит набор идентификаций пользователя (или идентификаций САУ — другая концепция ПОЗ — ем. С. 10). которые могут потребоваться для полномочий активности. Каждый элемент в таком списке содержиттакже «поле доступа* для аутентификации идентификации. В примитиве J-1NITIATE это поле может содержать только пароль, однако поставщик услуг может добавить элементы с признаком «уже проверено» во время инициирования, а также при проверке пароля. ПОЗ допускает также обеспечение в примитиве J-INITIATE дополнительных элементов полномочий всякий раз, когда в СР даются ссылки на документы. которые должны быть получены от исходных агентств или переданы принимающим агентствам.

Паче «список учета* является точным аналогом полю «список полномочий» и обеспечивает идентификации учета с теми же механизмами доступа. Эти идентификации должны при необходимости использоваться при ведении учета (затрат) для данной активности. Следует заметить, что протокол ПОЗ распределяет учетную информацию по пунктам монитора. Как и элементы полномочий, дополнительные элементы учета могут быть представлены с указателями исходных и принимающих агентств.

Параметр «список разрешений» является основой защиты С'Рот несанкционированного вмешательства. Эго список идентификаций тех пользователей, которые обладают полномочиями по модификации (или проверке) данной СР. Модификация СР ограничивается (аттестованными системами) теми СР, которые содержат в своем списке полномочий допустимую идентификацию, соответствующую одной из идентификаций в «списке разрешений» (или управляемую ей).

С. 1C Идентификация систем административного управления

В идентификациях ПОЗ распознаются два вида САУ; С'АУ для открытой системы тт САУ для «уполномо-ченного-ио-нденгификацин-иользователя*. Проверка правильности таких идентификаций производится также. как и идентификаций пользователя. Подтвержденное полномочие для САУ «уполномоченного-по-иденти-фнкапии-пользоватедя» содержит все привилегии ПОЗ. которыми Может обладать любой из ее пользователей. Подтвержденное полномочие для САУ открытой системы допускает как управление передачами ПОЗ. так и модификацию любых СР. содержащихся в Этой открытой системе, или поддерживающих эту откры тую систему в проверочной трассе, или указывающих эту открытую систему как необходимую для будущей активности. Такие модификации не требуют явных разрешений в списке разрешений.

С. 11 Активность ПОЗ (подзадания)

Теперь может быть описана активность, которая может' потребоваться в СР. Она может быть представлена в виде набора активностей, организованных в древовидную структуру и называемых «подзаданиями». Древовидная структура активности может быть выпажена либо как одна древовидная структура элементарного действия СИВ. либо в виде каждого подзадания. формирующего отдельное элементарное действие (в зависимости от требуемого уровня исполнения).

0.11.1 Подзадания перемещения документов

Для СР. предоставленных примитивом J-1N1T1ATE-WORK. первое подзаданне яачяется подзаданием перемещения документов. Такое подзаданне является по существу простым. Оно обеспечивает две несколько различные возможности.

С. 11.1.1 Перемещение конкретных поименованных документов

Первая возможность позволяет инициирующему агентству;

-    определить одну открытую систему (называемую «целевая система»), которая должна выдавать один или несколько примитивов J-DISPOSE принимающему или исполняющему агентству;

-    определять агентства (со всеми необходимыми параметрами идентификации, полномочия и учета) для каждого примитива J-DISPOSE (агентство может выполнить локальное действие или может использовать ПДУФ для удаленного действия);

-    определять (как определено ниже) документы, которые должны быть переданы каждому агентству в примитиве J-DISPOSE, и имена этих документов в принимающем агентстве.

Один и тот же документ может быть передан в нескольких примитивах J-DISPOSE (средства дублирования ПОЗ).

Каждый документ указывается как набор частей документа (средство сцепления ПОЗ). Каждая часть документа обеспечивается в примитиве J-INIT1ATE или идентифицируется при помощи:

82

Страница 88

ГОСТ Р ИСО/МЭК 8831-99

-    спецификации для каждой части документа открытой систсмы (открытая система действия), которая должна собрать часть документа, выдавав примитив J-GIVE в тс агентства, которые могуг обращаться к этому документу (локально или при помощи ПДУФ);

-    спецификации агентства (со всеми необходимыми параметрами идентификации, полномочий и учета) для примитива J-G1VE;

-    спецификации имени требуемого документа (в исходном агентстве), которое предназначено для формирования данной часта документа.

Открытая система действия должна быть или такой системой, в которой подзаданис стартует (инициирующая система для первого подзалания). или целевой системой, или, возможно, одной из промежуточных систем, использующей N-маршрут к целевой системе.

Элемент протокола ПОЗ (содержащий семантику СР) лучше всего представить в виде модели «выделенная часть». Документы разбиваются на части (получаемые с помощью примитива J-GIVE). которые перемешаются (возможно, через ретрансляционные системы) по направлению к целевой системе. В целевой системе документы для этого ползадания удаляются и посылаются из нее. используя примитив J-DISPOSE. (Некоторые документы, необходимые для более поздних иодзаданий, мот сохраняться).

С. 11.1.2 Перемещение групп документов

Вторая возможность позволяет инициирующему агентству:

-    указать, чтобы целевая система выдала примитив J-DISPOSE (к одному агентству) для каждой группы документов;

-    указать, чтобы группа документов была получена одной огкрытой системой действия, которая имеет достли к одному исходному агентству, дчя получения (локально или при помощи нестандартных протоколов) всех (от нуля до нескольких) документов, которые исходное агентство может принять и которые удовлетворяют определенному критерию. Этот критерий предегаатяет собой любую комбинацию обшей начальной части имени файла, общего типа документа или строку, которая зависит or PC. (Следует заметить, что средство «обший тип документа» относится к регистрации имен для типов документов — см. С.И).

Эта форма иодзадания особенно полезна для перемещения всех файлов, указанных в одном и том же подсправочнике, или для сбор;! всей выводимой из задания информации, когда неизвестны точные имена файлов/ документов. Поставщик услуг ПОЗ узнает имена текущих документов, используя примитив J-ENQL IRE для исходного агентства. Затем, чтобы получить документы, следует серия примитивов J-GIVE. Часть имени документа в исходном агентстве используется при формировании имени документа для принимающего агентства.

С. 1! .2 Завершение иодзадания и порождение проформы

Подзаданис готово дтя завершения, когда все определенные в нем примитивы J-DISPOSE указали готовность, предтожив исполнение уровнем ЗАВЕРШЕНИЕ, или более поздним примшивом запроса J-END-SIGNAL из принимающего или исполняющего агентства. В этот момент одно или несколько новых иодзаданий инициируется посзавишком услуг ПОЗ. Эти иодзадания формируются как часть элементарного действия примитива J-DISPOSE, то есть как элементарное действие бодсс раннего иодзадания или элементарное действие примитива J-END-S1GNAL, то есть новое элементарное действие. Эти новые иодзадания были определены в начальной СР, созданной примитивом J-INITIATE. Эго осуществляется при помощи подпараметров в примитиве J-INITIATE, называемых «проформами». Каждая проформа содержит «имя проформы» и дальнейшую спецификацию под задания перемещения документа, как было описано выше.

СР содержит спецификацию (одного) начального иодзадания и либо не содержит, либо содержит одну или несколько проформ. Каждая проформа содержит спецификацию (одну) иодзадания вместе с одной или несколькими проформами, либо без проформ, и так далее, на любую глубину.

Когда начинается работа в определенном проформой подзалании, проформа предлагает «породить» иод-задание. Каждая проформа, порождающая в конце выполнения подзаданис, порождает новую активность, которая действует независимо (и обычно параллельно) от активности, порожденной другими проформами. Действия для получения документов, указанных внутренними проформами, не предпринимаются до тех пор, пока они не породят подзаданис. Однако «выделенная часть» ПОЗ может содержать такие документы, если они были обеспечены примитивом J-INITIATE.

Предыдущее обсуждение концентрировалось на том. что называется «порождение конца активности*. Однако возможно также, что исполняющее агентство до завершения своей работы может выдать примитив J-SPAWN, чтобы породить из поименованной проформы для распределения некоторых документов, которые уже являются доступными. Такое действие называется «порождение запроса». Третье дополнительное действие называется «порождение принятия», предпринимаемое поставщиком услуг ПОЗ. когда все примитивы J-DISPOSE предоставили агентству уровень исполнения ПРИНЯТИЕ (или более высокий).

С.11.3 Обеспечение непрерывной активности

Имеется две дополнительные возможности, которые обеспечивают бесконечную (рекурсивную) последовательность активности ПОЗ; первая возможность представляет собой механизм, посредством которого проформа при порождении подзаданис может определить, что полная копия порождающей проформы (или одной из «родственных* ей) должна сформировать проформу в новом ползадании. Это называется «наследованием». Второе свойство называется «списком удержаний».

83

J—2*

Страница 89

ГОСТ Р ИСО/МЭК 8831-99

Список удержаний для каждого под задании может присутствовать в проформе во время задачи примитива J-INITIATE. или. в более общем случае, может вводиться при обработке или поставщиком услуг при возникновении ошибок. Список удержаний может содержать от нуля до нескольких «элементов удержания». Наличие элемента удержания приводит к удержанию подзадания поставщиком услуг ПОЗ (когда ответственность за него достигает указанной открытой системы). Элемент удержания содержит:

-    факультативный элемент разрешения для его освобождения при помощи обработки;

-    местоположение, где должно быть применено удержание (обычно или в области порождения, блокируя примитивы J-G1VE и передачи, или в облает целевой системы, блокируя примитивы J-DISPOSE);

-    факультативную читабельную причину для удержания;

-    факультативное время окончания, после которого удержание автоматически сбрасывается поставщиком услуг ПОЗ.

С.11.4 П о д з а д а н и я «в ы и о л и с и и е-р а б от ы*

Примитив J-INITLATE-WORK-MAN указывает начальное подзадание для выполнения (отображения или модификации) других СР. Соответствующая обрабатываемая СР направляется в указанную целевую открытую систему и содержит последовательность операций, которые должны быть выполнены поставщиком услуг ПОЗ в данной открытой системе. К этим операциям относятся:

ВЫБОР — либо не выбирать ни одной, либо выбрать одну или несколько СР. за которые данная открытая система несет ответственность: выбор определяется общим логическим выражением, включая тесты почти на любое иоле в СР;

УНИЧТОЖЕНИЕ — выбранные СР удаляются; любая соответствующая активность в принимающих или исполняющих агентствах завершается при помоши примитива J-KILL, а СР сбрасывается;

ОСТАНОВ — выбранные СР не выполняются, но любые соответствующие принимающие и исполняющие агентства посылают сигнал J-STOP; предполагается, что агентства должны «немедленно» завершить свою работу (возможно, обеспечивая вывод информации); подробности зависят от PC;

МОДИФИКАЦИЯ — указанные поля в выбранной СР изменяются или дополняются: количество модифицируемых полей меньше количества выбираемых полей;

ОТОБРАЖЕНИЕ — выбранные СР должны быть отображены при создании форматированного определенного ПОЗ документа: документ «собирается* от поставщика услуг ПОЗ включением одной или нескольких проформ (обычный тип «перемещение-документа*) в С'Р.

С. 11.5 Спецификация работы «управление отчетами»

СР J-IN1TIATE-REPORT-MAN указывает целевую систему, которая является пунктом монитора, и запрашивает либо отображение (в документе, собранном проформами), либо удаление отчетов, которые были собраны. Кроме того, к активности применяются механизмы полномочий. (На рисунке С.2 показаны некоторые аспекты активности ПОЗ).

С. 11.6 Спецификации работы «управление передачами»

СР J-INITIATE-TCR-MAN обеспечивает управление (определяемое полномочиями) со стороны любой Открытой системы так называемыми записями управления передачей, содержащимися в любой другой открытой системой.

Рисунок С.2 — Активность ПОЗ

S4

Страница 90

ГОСТ Р ИСО/МЭК 8831-99

C.1I.6.I Модель ЗУП

Модель ПОЗ, в основе которой лежит управление передачами, приведена ниже.

В некоторый момент времени открытая система А должна выполнить некоторое количество передач к открытой системе В. каждый раз передавая ответственность за выполнение СР системе В. САУ в системе В требует осуществлять некоторый контроль над этими передачами. Типичными примерами подобной ситуации являются:

-    попросить систему А прекратить попытки, либо потому, что система В неожиданно была отключена, либо система В принимает инициативу по запросу указанной передачи, либо система В является мобильной системой, отключившей себя в данный момент от сети;

-    попросить систему А ничего не предпринимать из того, что запросит конкретное устройство в системе В. поскольку оно неисправно:

-    попросить систему А не пытаться выполнять более трех одновременных передач системе В, если только одна из них не имеет высокий приоритет (другой параметр примитива J-IMTIATE), либо передается отчет или обработка задания.

Эти требования поддерживаются наличием в системе А концептуальной структуры данных, называемой записью управления передачей (ЗУП), управляющей передачами к системе В. Если ЗУП не устанавливается, действия системы А не ограничиваются и зависят от PC. Если она устанавливается, то либо не содержит, либо содержит один или несколько селекторов. Эти селекторы точно такие же. которые использовались в операции выполнения работы ВЫ ВОР для выбора одной или нескольких СР с использованием многообразия полей в них. (Обеспечивается также выбор, использующий время ожидания и размер).

Каждый селектор в ЗУП в любой момент времени «захватывается» несколькими СР. которые должны быть переданы. Имеется только одна СР. которая удовлетворяет требованиям выбора. Таким образом, никогда не выполняется число передач (инициируемых системой А к системе В), превышающее количество селекторов. и все представленные выше требования могут удовлетворяться соответствующей установкой селекторов ЗУП.

С. 11.6.2 Операции ЗУП

СР. предоставленная примитивом J-1N1TIATE-TCR-MAN, указывает целевую систему и ЗУП в той системе, которая должна обрабатывать. Запись может быть помешена (операция УСТАНОВКА) или отображена (операция ОТОБРАЖЕНИЕ) в документе при его сборке проформой.

Третья доступная операция называется ПРОВЕРКА. Она может быть использована в приведенном выше примере системой А в качестве запроса системе В после выхода из строя системы А. Операция содержит ЗУП. которую система А в данный момент собирается использовать для управления передачами к системе В. а ио-сушеству говорит »я пока вне полномочий — и если она не больше соответствующей записи, вы лучше измените ее». (Это является разновидностью повторной синхронизации очень высокого уровня).

Обработка ЗУП позволяет, чтобы ЗУП устанавливалась или приемником передач, который должен быть управляемым, или (соответственно полномочной) третьей стороной.

Примером третьей стороны, устанавливающей ЗУП. является система, в которой центр САУ системы «А» помешает ЗУП в спул главной системы «В» (действуя, как ретрансляционная система ПОЗ) для упраате-ния передачами к простому устройству управления печатью системы «С*. Зуп содержит иоле «УСТАНОВИТЬ СИСТЕМОЙ» с именем системы «А» и. следовательно, любая последующая операция ПРОВЕРКА посылается из системы «В» в систему «А», несмотря на тот факт, что эти передачи предназначены для управляемой системы «С» (см. рисунок С.З).

85

Рисунок С.З — Пример обрабогки ЗУП третьей стороной

5_3-!041i

Страница 91

ГОСТ Р ИСО/МЭК 8831-99

Инициирующее агентство

Рисунок С.4 — Иллюстрация иснолыования ПОЗ при традиционной активности задания

86

Страница 92

ГОСТ Р ИСО/МЭК 8831-99

В этом примере центр С'АУ системы «А» будет обеспечивать ПОЗ базового класса, расширенную, по меньшей мере, добавлением до функиии обработки ЗУГ1: спуд главной системы «В» будет обеспечиваться ПОЗ базового класса, расширенной, по меньшей мерс, дополнением до функции ЗУП: устройство управления печатью системы <>С» будет обеспечиваться только ПОЗ базовою класса.

С. 11.7 Иллюстрация

Рисунок С.4 иллюстрирует простое использование ПОЗ, эквивалентное нестандартной операции «удаленный ввод заданий» (УВЗ) (небольшое подмножество возможностей ПОЗ).

С. 12 Действия при ошибках

Котла открытая система, пытающаяся выполнить элементарное действие, обнаруживает ошибки, поставщик услуг ПОЗ готовится к выполнению любого из трех возможных действий, выбираемых при помощи признаков в СР.

Первое действие применимо только к ошибкам, появившимся с результатом попытки выполнить примитив J-GIVE (например, ошибкам «файл не существу ею. «недостаточные полномочия» и т. д.). При запросе такою действия диагностика СИВ из примитива J-G1VE вкладывается в СР вместо документа и со временем будет передана в принимающее и исполняющее агентства в примитиве J-DISPOSE. Основное элементарное действие, выдавшее примитив J-GIVE, продолжается нормально с примитивом C-READY. но включается предупреждающий отчет СИВ. Отчет ПОЗ может быть также выработан, если была запрошена такая категория отчетности.

Второе и третье действия выполняются ГУЛ О элементарного действия, когда от получает диагностику СИВ в примитиве C-REFUSE. Если запрашивается второе действие, элемент удержания добавляется к СР и в дальнейшем не выполняется до тех пор. пока не будет исправлена ошибка и не будет снято удержание. (Если удержание заканчивается до модификации и ошибка сохраняется, выполняется третье действие, см. ниже). Добаатение элемента удержания (не выполнять) является событием, которое может быть выбрано для отчетности.

Третье действие просто аварийно завершает СР, устанавливая диагностику СИВ в отчете «аварийное завершение».

С. 13 Документы

Стандарты ПОЗ главным образом относятся к перемещению документов. Термин «документ* вообще может широко определяться как содержимое файла или части файла — структурированная информация, отличающаяся какими-либо концепциями наименований, структурой доступа или другими атрибутами, относящимися к доступу.

ПОЗ распознает три типа документа (структурированная информация), которые полностью определяются ПОЗ (семантика и синтаксис передачи). Это — отображения отчетов ПОЗ, отображения работы ПОЗ и отображения ЗУП ПОЗ.

ПОЗ распознает также три типа документа, которые являются важной частью использования ПОЗ при разработке открытых систем общего назначении. Эю текстовые документы (строки знаков), документы для печати (строки знаков с символами «управление кареткой») и документы в двоичном коде (произвольной длины, неструктурированные, битовые последовательности).

Наконец, ПОЗ может запросить и содержать любые документы, которые имеют:

-    зарегистрированное имя (тип документа);

-    по меньшей мере, один определенный синтаксис для передачи с соответствующими именами синтаксиса.

Полное обеспечение ПОЗ для таких документов требует определения и регистрации типов данных, которые могут быть сцеплены для формирования такого документа.

Другим важным свойством ПОЗ является распознавание PC •обеспечение хранения». PC ПОЗ предоставляет «обеспечение хранения» для типа документа, если примитив J-GIVE. следующий за примитивом J-DISPOSE для любого конкретного документа этого типа, имеет результатом идентичное выдаваемое значение. В общем случае тс PC. которые не предусматривают возможность обеспечения хранения, например для документов типа ДВОИЧНЫЙ, могут дополнить битовую строку до размера, кратного восьми битам.

С. 14 Ретрансляционные системы ПОЗ

В общем случае под задание начинается примитивом J-1NITIATE или порождением и ответственность за соответствующую СР передается непосредственно из области инициирующего или порождающего агентства в область целевой системы при помощи протокола ПОЗ.

Эта простая ситуация неадекватна в следующих четырех случаях:

-    обе системы поочередно подключаются к сетям и никогда не подключены одновременно;

-    обе системы работают в различных временных зонах и никогда не работают одновременно;

-    очень простая принимающая система желает «прикрыться» более сложной системой, позволяя более сложной системе собирать и планировать передачи в простую систему;

-    не обеспечены документы, которые должны быть собраны из ретрансляционных систем, и не обеспечивается удаленный доступ к таким системам при помощи (например) ПДУФ.

Стандарты ПОЗ позволяют пользователю (в примитиве J-INITIATE) включать ретрансляторы ПОЗ в маршрут к целевой системе как для начального подзадания, так и для под заданий, порожденных проформами.

87

S-3*

Страница 93

ГОСТ Р ИСО/МЭК 8831—99


На рисунке С.5 показана обработка подзадания при передаче его к своей целевой системе через ретрансляционную систему. Документы собираются при помощи примитива J-G1VE во всех трех системах.

На рисунках С.6 и С. 7 показаны альтернативные подзадания, которые путем использования Г1ДУФ дают аналогичные результаты, но с различными временами связок для документов. Различия в иод заданиях определяются в спецификации < действий открытой системы > и в использовании или неиспользовании ПДУФ.


Остфиггфедмршиии явдрмЕЮС


Поствшрк yoiyr ПОЗ


Преете аапрехж

И1ТТАТЕ

Приыитю^^ш^


С


ИнМЦМфрМЦМ «ШТОПО


Приингтна ntiRTMpWWW J-IWTVCTE


сP


с


Шжодаовшшпотк»


J __


CD


1%трмслшрааннвя остяв


Пбенищ V

услуг ПОЗ


пралтш


с


ПрвШШВОТЕВТЖ J-


Цат ЕастБмв


J-Ж

Поставщик

ючгпоэ

гумитш отшт* J-orvc

Пршитиа


С


ИШНМ1ШШ16



с


)ШШШ


J-DBP08E


-опащфикщж

рйОйТЫ


CD


-доцммт п


Рисунок С.5 — Обработка подзадания через ретрансляционные системы ПОЗ


88

Страница 94

ГОСТ Р ИСО/МЭК 8831-99

Оиствы» првдоегавпм*» авданмя ЭОС

П|—им    J-M

СР


_v приммш^ма

HMWfijn iM intimiTB'i ) _ J-IMTWE    rbc*w»f*w»Tn08


[ Bumiemwe )феееееуе **юе ПДУ»


Рвтрянстрпмя смствив

Оптация 1ПД»


CntfMUM

чтм ПДЛ»

Цммсжтмн


Т^ТтаЯ?”*"


Г^С»»иирв

увцгПОЗ



прммтжывшта J-QCVE


00


\


ОЦрвАпчж ПДУ* в рани ишднагешннпш ПОЭ


CD

I


С


(1Ъапмм)пвуушешвлипа


СР

1

2

т


Гкамттив огаягаГТГЛ "-GTVE | 3 ]

г'1Т1мр8вец*


J-DWP08E

Рисунок С.6 — Обработка подзадания с поздним соединением

89

Страница 95

ГОСТ Р ИСО/МЭК 8831-99

Рисунок С.7 — Обработка под задания с ранним соединением

Страница 96

ГОСТ Р ИСО/МЭК 8831-99

С. 15 Протоколы доступа к агентству

В начальных стандартах ПОЗ «действие открытой системы» получает документы путем использования СГ1 J-GIVE (который может вызвать использование ПДУФ). Целевая открытая система размешает документы путем использования примитива J-DISPOSE (который может вызвать использование ПДУФ).

В сталии изучения находятся вопросы обеспечения очень простого протокола для поддержки связи между удаленным агентст вом и поставщиком услуг ПО'З (отображая соответствующие СП ПОЗ). Такое расширение ПОЗ будет включать простые «периферийные дисковые устройства» для работы (используя стандартные протоколы) через локальную сеть к «замкнутой системе» без периферии, но действующая как поставщик услуг ПОЗ.

Будет предусмотрено также обеспечение примитивов J-ENQU1RE, J-HOLD, J-END-SIGNAL и др.. которые не обеспечиваются ПДУФ.

С. 16 Временные соотношения между сервисными примитивами

Последовательность СП ПОЗ. формирующая группу исполнения операций J-IN1TIATE. целиком представлена в одном пункте доступа к услугам.

Если уровнем исполнения для этой группы является ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА (самый низкий из возможных), тогда нет необходимости выдавать примитивы в любой другой пункт доступа к услугам до тех пор. пока не завершится группа исполнения операций J-IMTIATE.

Если уровень исполнения для этой группы выше, чем ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА, тогда другие группы исполнения вводятся в другие пункты доступа к услугам во время обработки группы исполнения операций J-INITIATE. Все обязательства по временным соотношениям между группами в двух или более пунктах доступа к услугам полностью описываются в определении услуг СИВ или неявно предполагаются в потребности поставщика услуг получать данные (в примитиве ответа J-G1VE) до их доставки (в примитиве индикации J-DISPOSE).

Подзалаиие ПОЗ может включать (например) (руины примитивов J-INITIATE. J-D1SPOSE и две группы J-GIVE в четырех различных пунктах доступа к услугам.

Даже в случае исполнения с уровнем ЗАВЕРШЕНИЕ возможны значительные расхождения во временной последовательности элементов групп примитивов в различных пунктах доступа к услугам. На рисунке С.9 пока юны возможные последовательности примитивов при помощи диаграммы временной последовательности (см. приложение А) ятя потока обработки, показанного на рисунке С.8.

Следует заметить, что включение исполнения с уровнем ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА ослабляет еше больше временные ограничения, налагаемые на последовательности примитивов. Показанная на рисунке С.8 конкретная последовательность может, однако, все еще иметь место — PC' может всегда попытаться обратиться к более высокому уровню исполнения по сравнению с запрошенным.

Солее интересное взаимодействие но временной последовательности имеет место, когда принимающее агентство предоставляет документ, и более или менее одновременно исполняющее агентство тоже предоставляет документ для обработки, и это приводит к тому, что исполняющее агентство (невидимое для ВОС) принимает документ вводимый принимающим агентством для размещения. Следует заметить, что на этой стадии поставщик услуг не может принимать другие труппы примитивов J-DISPOSE. Правила параллельности СИВ требуют, чтобы документ, передаваемый принимающему агентству, был доступен исполняющему агентству. где он обрабатывается как часть одного и того же элементарного действия. 'Этот случай может быть важен, когда один документ (скажем, данные) посылается в постоянное хранилище файлов, пока другой документ (Я УЗ) передается к разделителю задания.

С. 17 Подмножества и соответствие

Этот раздел завершает обзор операций ПОЗ. Все обеспечиваемые возможности связаны с общими понятиями полномочий, перемещений документов и порождений проформ. Общая доступность создает потенциально очень мощную систему для определения и поддержки активности сети с минимальными затруднениями для человека. Однако для того чтобы облегчить исходную задачу реализации ПОЗ. определены две формы «подмножеств*.

Первая форма подмножест в называется базовым классом ПОЗ. Она налагает ряд ограничений в расчете на облегчение разработки PC. обеспечение простой активности, гас система А посылает документ системе В для обработки, а система В возвращает результирующий документ системе А.

СР базового класса и соответствующий элемент протокола является определенным подмножеством общего случая. Расширенная PC и PC базового класса будут взаимодействовать в том случае, если примитив J-1NIT1ATE гарантирует, что достаточно ограниченные ползадания передаются в PC базового класса (см. С.18).

Начальные стандарты ПОЗ содержат полную спецификацию услуг, и спецификацию протоколов только базового класса с добавлением в будущем протоколов для обеспечения расширенных PC.

Вторая форма подмножества содержится в характере поддержки агентства, обеспечиваемого PC. Определенная PC может быть предусмотрена для работы только в качестве инициирующего агентства. Эго называется «поддержкой для предоставления задания ВОС ПОЗ». Другая PC можегбыть предусмотрена для работы только определенного устройства в качестве пункта монитора ПОЗ. Следующая PC может обеспечивать использование одного (но. возможно, не всех) из своих печатающих устройств в качестве принимающего агентства ПОЗ. Некоторая PC может обеспечивать все СП ПОЗ при помощи вызовов подпрограмм из программы пользователя

91

Страница 97

ГОСТ Р ИСО/МЭК 8831-99

СМшй 1

Рисунок С.8 — Пример потока обработки для уровня исполнения ЗАВЕРШЕНИЕ

92

Страница 98

г«лша<>


эи huhixIa илг floiituimiidti ихэончiraLOToroimou


Страница 99

ГОСТ Р ИСО/МЭК 8831-99

на языке ФОРТРАН (но, возможно, не из программ на языке КОБОЛ). 'Это будет называться «поддержкой ПОЗ на языке xyz». Последнее служит примером обеспечения человеку возможности принимать сообщение о документах для обработки и сигнализировать о завершении обработки — «поддержка ПОЗ для обработки человеком».

Точные детали интерфейсов, участвующих в этих поддержках (так называемые «илыковые связки»), не являются частью текущей работы ПОЗ и определяются соответствующими PC. Однако набор функций, которые потребуются для подкрепления заявок типа «поддержка ПОЗ для ... определяется в соответствующих операторах протоколов ПОЗ.

C.1S Взаимодействие базовых н расширенных реализаций

PC базового класса обеспечивает выдачу в своей системе примитивов базового класса и обрабогку СР базового класса.

Расширенная PC' ПОЗ может также (в зависимости от дополнительно реализованных функций) обеспечивать выдачу примитивов сверх определения базового класса и/или обработку СР сверх возможностей базового класса.

Элемент передачи всегда отображает структуру- данных, которая подчиняется ограничениям базового класса, если он является частью (аланин ВОС, инициированного примитивом J-INITIATE базового класса. Примитив J-INITIATE расширенного класса может, тем не менее, сформировать начальный элемент передачи, соответствующий базовому классу (и обрабатываемый системой базового класса), если все дополнительные функции находятся в спецификациях проформы. В равной мере более поздний элемент передачи может входить в базовый класс, даже если начальный элемент передачи выхолит за пределы базового класса.

Эти свойства возможны, поскольку для СР базового класса допускается иметь список прозрачных проформ. если она предназначается и для других целей.

На рисунке С. 10 показана PC базового класса, формирующая элемент передачи, который выходит за рамки базового класса вследствие порождения из проформы, полученной при передаче из расширенной PC.

Рисунок С. 10 — Взаимодействие


А — спецификации подзаланкя базового класса с одной проформой: В - спецификации пол заданны базового класса cd списком проформ: С — может указывать нолзалании базовою класса или имен- расширенные функциональные возможности.

94

Страница 100

ГОСТ Р ИСО/МЭК 8831-99

В таблице C.I представлены (дчя одного задания ВОС) возможные комбинации функциональных возможностей примитива J-INITIATE. элементы передачи, принятые FC во время выполнения задания ВОС. и результирующие элементы передачи.

Таблица C.I — Комбинации функциональных возможностей базового и расширенного классов

J-INITIATE для гад айн я ВОС

Вм-шоАмые элементы передачи мри выполнении задании ВОС

Возможные роультируюшис элементы перелл'ш

Базовый

Базовый

Базовый

Расширенный

Расширенный

Базовый или расширенный

Расширенный

Базовый

Базовый или расширенный

Базовый элемент передачи может быт ь обработан получателем ин(|юрмапии базового класса. Расширенный элемент передачи требует, чтобы принимающая система имела расширенную функциональность

С. 19 Протокол ПОЗ

Спецификация протокола ПОЗ состоит из трех основных частей:

-    определение абстрактного синтаксиса передачи (с использованием ACH.I) структуры данных, используемой для передачи СР. при которой получатель ин<]юрмапии вместе с проформами и документами в настоящий момент находится в «выделенной части»:

-    детальные процедурные операторы по действиям, которые должны быть выполнены PC ПОЗ при выдаче примит ива запроса J-INITIATE или при приеме вышеописанной структуры данных: эти действия включают в себя задачу (как часть элементарного действия СИВ) примитива J-GIVE и/или J-DISPOSE. порождение, формирование отчетов и так далее;

-    средства, фактически передающие (в пределах элементарного действия СИВ) описанную выше структуру данных.

В базовом классе последняя спецификация включает задачу одного примитива Р-DATA в элементах СИВ (в ассоциации СЭУА). Каждый документ представляет собой значение отдельных данных в одном примитиве Р-DATA. В расширенной спецификации протокола документ может передаваться в качестве набора значений данных водном или нескольких примитивах Р-DATA. Начальные стандарты ПОЗ требуют, чтобы отправители и получатели информации обеспечивали передачу при помощи непосредственного и простого использования примитива P-DATA.

С.20 Примеры механизма назначения полномочий

Рассмотрим следующий пример. Пользователь в области А предоставляет С'Р. содержащую одну проформу. чтобы выполнить задание в области В и выдать результат в область А. Пользователь имеет следующие присвоенные ему имена пользователя: в области А имя пользователя USERA и пароль PASSA, а в области В имя пользователя LSERB и пароль PASSB. Имеется четыре случая, которые следует рассмотреть в отношении того, какая область какой области доверяет:

ОТ УЧАЙ А — Область А доверяет области В, а область В доверяет области А;

СЛУЧАЙ В — Область А доверяет области В. а область В не доверяет области А;

СЛУЧАЙ С — Область А не доверяет области В. а область В доверяет области А:

СЛУЧАЙ D — Область А не доверяет области В. а область В не доверяет области А.

С.20.1 Определение доверия

Когда СР появляется в области В. проверочная трасса будет иметь один элемент, а именно, элемент области А. Значением состояния будет НЕИЗВЕСТНЫЙ: область В использует сведения об имеющихся сетях и/или методах кодирования, чтобы (возможно) перевести это полученное значение в значение ИЗВЕСТНЫЙ или АУТЕНТИФИЦИРОВАННЫЙ. Область В имеет список областей, которым она будет «доверять, если АУТЕНТИФИЦИРОВАННЫЙ, «доверять, если ИЗВЕСТНЫЙ» или .доверять, даже если НЕИЗВЕСТНЫЙ». Эго зависит от того, доверяет ли область В области А. Списки формируются (вручную) в САУ.

Когда (порожденная) СР возвращается обратно в область А. она содержит два элемента проверочной трассы — один для области А. за которым следует один элемент для области В. Область А вначале определяет, доверяет ли она последней области (область В) в проверочной трассе (как описано выше). Если она доверяет последней области, она затем определяет , доверяет ли она предпоследней области (область А) в проверочной трассе, основываясь на опенке значений НЕИЗВЕСТНЫЙ. ИЗВЕСТНЫЙ или АУТЕНТИФИЦИРОВАН-Н ЫЙ для области В и своих сведениях об области В. Если она не доверяет последней област и, она автоматиче-

95

Страница 101

ГОСТ Р ИСО/МЭК 8831-99

ски нс может доверять любой другой области в проверочной трассе до тех пор. пока область, которой не было оказано доверие, не внесет изменения (определением) в любые более ранние элементы в проверочной трассе, таким об раю XI делая се недействительной.

В общем случае проверяющая область продолжает просматривать проверочную трассу or последнего элемента до первого элемента до тех пор. пока не обнаружит область, которой она нс доверяет. После этого она отказывает в доверии всем оставшимся областям. Таким образом определяется степень доверия дли каждой области проверочной трассы.

С.20.2 Необходимые списки полно м о ч и й С.20.2.1 Случай А (обе области доверяют друг другу)

Когда пользователь обеспечивает полномочие для задачи ПОЗ, он не обеспечивает никакою пароля: элементы полномочия с «проверенными индексами» I добавляются поставщиком услуг ПОЗ для своих локальных и удаленных имен пользователей (USERA и USERB) при предоставлении СР со списком полномочий: область A    USERA 1

обтасть В    USERB !

Когда СР поступает в область В, то поскольку область В доверяет (только) области в проверочной трассе, она изъявляет желание воспринять элемент полномочий обтасть В    LSERB I,

как обеспечивающая полномочие доступа для самой себя, например, она доверяет области А заиметь проверенного пользователя, который имеет имя пользователя USERB.

Если (порожденная) СР, содержащая выходную информацию, поступает в область А. то область А доверяет обеим областям в проверочной трассе и. следовательно, она знает, что USERA был предварительно проверен сю самой ранее во время выполнения задачи ПОЗ (после этого можно полагать, что «проверенный индекс» I должен быть правильным). Поэтому отта имеет достаточное полномочие на размещение выходной информации.

В этом примере проверенный индекс принимает только значение 1, поскольку проверки! всех паролей была провслсиа в системе предоставления задании В ОС.

С.20.2.2 Случай В /обметь В не доверяет области А)

Когда СР поступает в обтасть В. то поскольку область В нс доверяет области А. она будет требовать следующий элемент полномочий

обтасть В    liSERB    PASS В

прежде, чем она сможет обрабатывать С'Р. Поэтому пользователь ирсдоста&тяст свое имя и пароль для области В при предоставлении задачи ПОЗ в области А.

Когда (порожденная) СР с выходной инфорхишией поступает в область А, область А доверяет обеим областям в проверочной трассс и поэтому она будет удовлетворена следующим элементом полномочий область A    USERA    I,

как и в приведенном выше случае А.

С.20.2.3 Случай С (область А не доверяет области В)

В этом случае при предоставлении задачи ПОЗ пользователю необходимо включить свой собственный пароль и имя пользователя для области А. но только единственное имя пользователя для области В. предоставляя следующий список полномочий:

обтасть A    US ERA    PASSA

обтасть В    USERB    I

Поскольку область В доверяет области А, она нс требует пароли для выполнения задания, однако область А нуждается в правильном пароле (PASSA) для размещения выдаваемо» выходной информации, поскольку она нс доверяет СР, выходящим из области В. Следует, однако, заметить, что хотя область А нс доверяет области В. (человек) пользователь в области А должен доверять области В для тою, чгобы правильно использовать свои пароль (обчасть А), который он посылает в область В.

С.20.2.4 Случай D (ни одна us областей не доверяет друг другу)

Пользователь предоставляет имена пользователей и пароли для обеих областей А и В. поскольку ни одна область нс доверяет другой и се «маскараду».

С.20.3 О б ш и е пункты

Если пользователь всегда предоставляет имена пользователя и пароли для обеих областей, СР всегда будут иметь достаточное полномочие независимо от того, доверяют области друг другу или нет; цель механизмов доверия — освободить ПОЗ от необходимости содержания паролей, вложенных в свои СР, и избежать забот, которые заставляют человека запоминать несколько паролей.

С.20.4 Иллюстрация

Таблица С.2 иллюстрирует этот прихтер с некоторыми дополнительными предположениями. Во-первых, предполагается, что механизмы положительной аутентификации используются между областями, которые имеют взаихтное доверие, и что используемые сети предоставляют достаточную идентификацию областей иньш способом. Во-вторых, предполагается, что в тех случаях, когда САУ области еще нс установила механизмы. отображающие доверие, пользователь этих областей, тем не менее, будет доверять всем областям, которые используюгся его заданием В ОС с сто паролем для других областей.

96

Страница 102

ГОСТ Р ИСО/МЭК 8831-99

Таблица С. 2 — Значение списка полномочий и проверочная трасса в примерном сценарии

СР передается hi области А и область В

СР передастся из области В в область А

Случаи

Список полномочий

Проверочная трасса после обработки п области В

Список полномочии

Проверочная трасса после обработки в области А

Идеи шфнклнин пользователи

Поле

проверки

Идентификация

пользователя

Поле

проверки

Обе области д о вс ря ют друг другу

USERA

USERB

1

1

Область А АУТЕНТИФИЦИРОВАНА

USLRA

USERB

1

1

Область А АУТЕНТИФИЦИРОВАНА Область В АУТЕНТИФИЦИРОВАНА

Область В не доверяет области А

USERA

USERB

1

PASS В

Область А ИЗВЕСТНА

USERA

USERB

I

PASS В

Область А И ЗВЕСТНА

Область В ИЗВЕСТНА

Область А не доверяет области В

US ERA USERB

PASSA

1

Область А ИЗВЕСТНА

USLRA

USERB

PASSA

1

Область А ИЗВЕСТНА

Обтасть В ИЗВЕСТНА

Все области не доверяют другим

USERA

USERB

PASSA PASS В

Область А И 3-ВЕСТНА

USERA

USERB

PASSA PASS В

Область А ИЗВЕСТНА

Область В ИЗВЕСТНА

ПРИЛОЖЕНИЕ D (справочное)

Словарь терминов

Данное приложение содержит расположенные в алфавитном порядке определения, используемые в настоящем стандарте. При обнаружении противоречий с настоящим стандартом, предпочтение следует отдавать данному приложению.

D.1 Агентство — абстрактное описание таких функций среды локальной системы, которые необходимы для обеспечения услуг ПОЗ.

D.2 Активность (в агентстве) — работа, выполняемая каким-либо агентством, инициируемым СП, выданным в это агентство поставщиком услуг ПОЗ; завершение этой активности указывается СП. выданным этим агентством поставщику услуг ПОЗ.

D.3 Аутентифицируемая идентификация — известные данные, необходимые для правильной идентификации пользователя или САУ, по запросам которых должна выполняться работа путем использования проверки пароля или некоторого другого механизма проверки.

D.4 Данные управления порождением — данные, содержащиеся в про(|юрме. которая управляет состояниями. при которых имеет место порождение из этой проформы.

D.5 Диагностика «вс повторять* - информация, передаваемая услугой СИВ при возврате в исходное состояние, когда действие не может быть завершено, а последующая повторная попытка не предполагается.

D.6 Диашостика «повторить позже» — информация, передаваемая услугой СИВ при возврате в исходное состояние, когда действие не может быть завершено по крат ковременным причинам.

97

Страница 103

ГОСТ Р ИСО/МЭК 8831-99

D.7 Документ — совокупность данных, образующих часть СР к блок взаимодействия между поставщиком услуг ПОЗ и агентством.

D.8 Задание В ОС — обшая рабога во всех открытых системах, являющаяся непосредственно или косвенно результатом обработки начальной СР.

D.9 Запись управления передачами — концептуальная структура данных, сохраняемая открытой системой для упраачения передачей СР и выдачи СП.

D.10 Идентификатор спецификации работы — уникальный указатель для СР. который содержит имя системы предоставления задания ВОС. идентификацию инициирующего пользователя, локальный указатель задания ВОС и имя задания ВОС; если СР была создана порождением, идентификатор также содержит одно или несколько имен проформы.

0.11 Идентификатор инициирования — идентификация, обеспечиваемая поставщиком услуг ПОЗ во время предоставления для того, чтобы идентифицировать инициатора задания ВОС.

D.12 Уполномоченный по идентификации — поименованный уполномоченный, который назначает идентификаторы: зги идентификаторы могут использоваться для определения средств, которые должны быть доступны соответствующей аутентифицируемой идентификации (полномочие), или для взимания платы за расходы (учет), или для того и другого.

D.I3 Идентификация пользователя — данные, которые могут использоваться в определенном контексте, чтобы идентифицировать пользователя, от имени которого должна запрашиваться рабога.

D.14 Идентификация уполномоченного по идентификации САУ — имя уполномоченного по идентификации, который будучи аутентифицирован, выдаст полномочия активностям ПОЗ, относящимся к управлению активностью, инициируемой идентификаторами пользователя, которые выдаст этот уполномоченный.

D.15 Идентификация САУ открытыми системами — имя открытой системы, которая, будучи аутентифицирована, уполномочивает активности ПОЗ или затраты, отнесенные к САУ этой открытой системы.

D.16 Идентификация учета - данные, которые могут использоваться в соответствующем конгексте для идентификации учета, подлежащего занесению в дебет со всеми затратами, за которые взимается плата.

Примечание— Идентификации пользователя и учета состоят из имени уполномоченного по идентификации вместе с одной из идентификаций, которые он выдаст.

D.17 Имя задания ВОС — последовательность знаков, предоставляемая инициирующим агентством во время предоставления задания ВОС.

D.18 Инициирующее агентство — агентство, которое вызывает создание СР.

0.19 Исполняющее агентство — любая часть открытой системы, которая первоначально действует как принимающее агентство для документов, а впоследствии — как исходное агентство для соответствующих документов, сформированных в результате обработки более ранних документов.

D.20 Исходное агентство — некоторая часть открытой системы, которая может представить документы в результате обработки СР для включения в СР при их запросе поставщиком услуг ПОЗ.

D.21 Локальный указатель задания ВОС — указатель задания ВОС. который является уникальным внутри системы предоставления задания ВОС, назначаемый этой открытой системой.

D.22 Мониторы задания ВОС — открытые системы, в которые посылаются отчеты ПОЗ об определенном задании ВОС.

D.23 Начальная спецификация работы — СР. созданная инициирующим агентством в результате выдачи СП инициирования.

D.24 Обновление — данные, которые используются для модификации выбранной СР или проформы.

D.25 Операции выполнения работы — операции, которые выбирают одну или несколько СР или проформ и запрашивают отображение, уничтожение, останов или модификацию.

D.26 Операции управления передачами — операции, запрашивающие ЗУП для установки, отображения или проверки.

D.27 Операции управления отчетностью — операции, запрашивающие удаление или отображение отчетов. сохраняемых открытыми системами, назначенные некоторой СР в качестве пункта монитора.

D.28 Передача спецификации работы — элементарное действие, при помоши которого СР создается в принимающей открытой системе и разрушается в посылающей открытой системе.

D.29 Нодзаданне ВОС (подзадаиие) — общая работа, являющаяся результатом обработки одной СР. включая порождение дополнительных СР. но исключая работу, заключающуюся в обработке этих дополнительных СР.

D.30 Порождение — процесс получения данных из проформы и использования их для формирования новой СР.

D.31 Предупреждающая диагностика — информация, переданная услугой СИВ в предложении исполнения. которая уведомляет (обычно человека) о каких-либо отклонениях от ожидаемого действия или о неожиданных результатах при выполнении действия.

D.32 Предъявление задания ВОС — использование С'П инициирования инициирующим агентством для создания начальной СР.

D.33 Принимающее агентство — некоторая часть открытой системы, в которую в результате обработки СР могут быть переданы документы поставщиком услуг ПОЗ.

98

Страница 104

ГОСТ Р ИСО/МЭК 8831-99

D.34 Проформа — часть СР. указывающая дополнительную работу н используемая для формирования ноной СР как части выполнения предшествующей работы.

D.35 Проформа верхнего уровня — проформа, не содержащая внутри никакой другой проформы.

D.36 Селектор — данные, используемые для указания выбора СР.

D.37 Система предоставления задания В ОС — открытая система, в которой имеет место предоставление задания ВОС.

D.3S Спецификация работы - концептуальная структура данных, используемая поставщиком услуг 1103 и указывающая определенным способом работу, которая должна быть выполнена.

D.39 Спецификация выполнения работы — СР. содержащая операции выполнения работы.

D.40 Спецификация управления передачами — СР. содержащая операции управления передачами.

D.41 Спецификация выполнения отчетов — тип СР. созданной поставщиком услуг ПОЗ для перемещения отчетов ПОЗ; целевая открытая система для таких СР представляет собой один из мониторов задания ВОС.

D.42 Спецификация работы управления отчетами — СР. содержащая операции управления отчетами.

D.43 Уведомление ПОЗ — закодированная информация, регистрирующая обработку или сбой задания ВОС. сформированная поставщиком услут ПОЗ. возможно, в результате взаимодействия с агентством.

D.44 Уровень исполнения - параметр, который определяет либо необходимость выполнения операций, затребованных в элементарном действии, во время элементарного действия, либо необходимость пометить эти операции (как сохраняемые данные) для последующего выполнения.

99

Страница 105

ГОСТ Р ИСО/МЭК 8831-99

УДК 681.324:006.354    ОКС 35.100.70    П85    ОКСТУ4002

Ключевые слова: задание, спецификация работы, обмен информацией, агентства, взаимосвязь открытых систем, реализующая система, сервисный примитив

Редактор В. П. Огурцов Технический редактор Я. А. Куи/еиова Корректор Е. Ю. Mumpoif/anoea Компьютерная верстка 3. И Мартыновой

Изд. яиц. Nk 021007 от 10.08.95 г. Сдано в набор 13.04.99. Подписано ■ печать I7.0S.99. Уел. печ.л. 12.09. Уч. ида.л. 12,40. Тираж 252 >к».С2842. Зак. I04K.

ИПК Издательство стандартов.!07076. Москва. Колодезный пер., 14. Набрано в Калужской типографии стандартов на ПЭВМ. Калужская типография стандарте, ул. Московская. 256.

ПЛР № 040138