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

189 страниц

1004.00 ₽

Купить ГОСТ Р 34.1983-93 — бумажный документ с голограммой и синими печатями. подробнее

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

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

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

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

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

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

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

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

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

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

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

 Скачать PDF

Оглавление

Введение

Раздел 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. Документ отображения записи TCR службы ПОЗ

     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. Терминология службы JTM

     В.9. Параметры задания модели OSI

     B.10. Идентификация управляющей системы

     В.11. Активность службы JTM (подзадания)

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

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

     В.14. Промежуточные системы службы JTM

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

     В.16. Временные соотношения в сервисных примитивах

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

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

     В.19. Протокол службы JTM

     В.20. Примеры механизма санкционирования

Приложение Г. Термины

Информационные данные

 
Дата введения01.01.1994
Добавлен в базу01.10.2014
Завершение срока действия01.01.2000
Актуализация01.01.2019

Этот ГОСТ находится в:

Организации:

03.03.1993УтвержденГосстандарт России62
ИзданИПК Издательство стандартов1993 г.
РазработанТК 22 Информационные технологии

Information technology. Open systems interconnection. Job transfer and manipulation concepts and services

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

ГОСТ Р 31.198.1 93 (ИСО 8831—89)

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

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

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

92/717


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

из

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

УДК 681.224:006.354    Группа    П85

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

ГОСТ P 34Л983—93 (ИСО 8831—89)

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

Information technology Open Systems Interconnection. Job Transfer and Manipulation concepts anb services

ОКСТУ 0034

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

ВВЕДЕНИЕ

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

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

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

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

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

С. 10 ГОСТ Р 34.1983--93

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

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

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

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

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

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

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

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

ГОСТ Р 34.1983-93 С. 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 34Л983—93 G. 13

может отклонить с ответом «повторите позже» попытку поставщика услуг службы ПОЗ инициировать новую активность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 34.1983-93 С. 15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 34.1983-93 С. 17

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

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

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

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

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

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

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

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

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

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

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

2 Зак. 815

С. 18 ГОСТ Р 34.1083-93

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 34.1983-93 С. 19

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

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

2.1.8.1. Обзор.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.8.2.    Уровни совершения операций для службы ПОЗ.

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

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

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

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

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

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

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

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

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

ГОСТ Р 34.1983-93 С. 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 34.1983-*$ С. S

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

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

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

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

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

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

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

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

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

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

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

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

С. В ГОСТ Р 34.1983-03

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

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

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

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

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

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

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

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

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

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

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

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

жение, уничтожение, остановку или модификацию.

ГОСТ Р 34.1983-93 С. 7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OSI (Open systems interconnection);

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

JTM (Job transfer and manipulation);

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

FTAM (File transfer, access and management);

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

ГОСТ Р 34.1983-98 С. 9

CCR (Commitment, concurrency and recovery).

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

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

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

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

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

2.1.1 Обзор

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

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

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

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

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

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

для:

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

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

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

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

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

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

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

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

1

До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 «Информационная технология».

2

До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 «Информационная технология».