---

1. нарушены правила ГОСТ 22558 пли

2. используются средства, для которых правила ГОСТ 22558 были опреде­лены недостаточно четко, и поэтому зависят от определяемых реализацией рас­ширений или интерпретации правил.

1. Длина константы ALL литерал (ВСЕ литерал) (2 Я ДР). Когда, стан­дартная константа ALL литерал (ВСЕ литерал) не связана с другим данным, длиной строки является длина литерала.

Обоснование

Правила в стандарте Кобола для размера стандартной константы ALL лите­рал (ВСЕ литерал) различны в зависимости от того, где использована стандарт­ная константа в программе. Если стандартная константа ALL литерал (ВСЕ ли­терал) используется в параграфе SPECIAL-NAMES (СПЕЦИАЛЬНЫЕ-ИМЕ- НА), ее длина равна единице, а ее значением является самая левая литера ли­терала. Рассмотрим следующий пример.

IDENTIFICATION DIVISION.

PROGRAM-ID. EXAMPLE.

ENVIRONMENT DIVISION.

CONFIGURATION SECTION.

OBJECT-COMPUTER.

PROGRAM COLLATING SEQUENCE IS COL-SEQ.

SPECIAL-NAMES.

COL-SEQ IS ALL «01234567'89»

DATA DIVISION.

01 FIELD 1 PIC X(80).

PROCEDURE DIVISION.

START-PROGRAM.

IF FIELD-1—ALL «ABCDEF»

DISPLAY «TEXT IS TRUE».

■РАЗДЕЛ ИДЕНТИФИКАЦИИ.

ПРОГРАММА. ПРИМЕР.

РАЗДЕЛ ОБОРУДОВАНИЯ.

СЕКЦИЯ КОНФИГУРАЦИИ.

ОБЪЕКТНАЯ .МАШИНА.

ПРОГРАММНЫЙ АЛФАВИТ ПР-АЛФ.

СПЕЦИАЛЫ ЗЫЕ-ЙМЕПА.

ПР-АЛФ ВСЕ «0123456789».

РАЗДЕЛ ДАННЫХ.

01 ПОЛЕ1 ШХ(80).

■ РАЗДЕЛ ПРОЦЕДУР.

НАЧАЛО-ПРОГРАММЫ.

ЕСЛИ ПОЛЕ! - ВСЕ «АБВГДЕ»

ВЫДАТЬ «ТЕКСТ ВЕРЕН».

В приведенном выше примере, когда стандартная константа ALL литера® (ВСЕ литерал) используется во фразе имя-алфавита параграфа SPECIAL­NAMES (СПЕЦИАЛЬНЫЕ-ИМЕНА). используется только первая литера лите­рала, независимо от количества литер в литерале. Во втором случае IF FIELD! = «ABCDEF» (ЕСЛИ ПОЛЕ1 = ВСЕ «АБВГДЕ») размером литерала счита­ются все литеры, входящие в литерал.

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

2. Фраза имя-алфавита (1 ЯДР). Ключевое слово ALPHABET (АЛФА­ВИТ) должно предшествовать имени-алфавита во фразе имени-алфавита пара­графа SPECIAL-NAMES (СПЕЦИАЛЬНЫЕ-ИМЕНА).

Обоснование

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

SPECIAL-NAMES. WORD-1 IS WORD-2.

СПЕЦИАЛЬНЫЕ-ИМЕНА. СЛОВО-1 ЕСТЬ СЛОВО-2.

Если WORD-1 (СЛОВО-1) является именем-реализации и именем-алфавита, a WORD-2 (СЛОВО-2) было и мнемоническнм-именем и именем-реализации, то невозможно установить, что предполагается в вышеприведенной фразе — фраза имени-реализации или фраза имени-алфавита. Введение ключевого слова ALPHABET (АЛФАВИТ) во фразе имени-алфавита разрешает эту неоднознач­ность.

Этой проблемы не было в ГОСТ 22558, поскольку системные-имена и слова, определенные пользователем, входили в непересекающиеся множества, поэтому вышеприведенная конструкция не допускалась.

Разрешение совпадения системных-имен и слов, определенных пользователем, способствует облегчению переноса программ с одной реализации на другую: системные-имена больше не нуждаются в замене. Для модификации имеющихся программ перед фразой имени-алфавита необходимо вставить ключевое слово ALPHABET (АЛФАВИТ)/

3. Программный алфавит (1 ИПД). Программный алфавит (основная по­следовательность), используемый для доступа к индексному файлу, является алфавитом, связанным с внутренним набором литер, действовавшим для файла во время создания файла.

Обоснование

1. В ГОСТ 22558 правила не устанавливали, какой именно алфавит использу­ется для извлечения и занесения записей при доступе к индексному файлу. Были возможны две различные интерпретации.Внутренний алфавит.

2. Алфавит, определенный фразой PROGRAM COLLATING SEQUENCE (ПРОГРАММНЫЙ АЛФАВИТ).

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

4. Фраза CURRENCY SIGN (ВАЛЮТНЫЙ ЗНАК) (1 ЯДР). Литерал, указанный в фразе CURRENCY SIGN (ВАЛЮТНЫЙ ЗНАК), не может быть стандартной константой.

Обоснование

В ГОСТ 22558 допускалось использование стандартной константы во фразе CURRENCY SIGN (ВАЛЮТНЫЙ ЗНАК), но не было правил, определяющих смысл использования в этом контексте литералов HIGN-VALUE (НАИБОЛЬ- ШЕЕ-ЗНАЧЕНИЕ), LOW-VALUE (НАИМЕНЬШЕЕ-ЗНАЧЕНИЕ) или ALL ли­терал (ВСЕ литерал).

Можно было бы добавить правила для разъяснения значения различных случаев, но польза от этого кажется мнимой. Таким образом, использование стандартной константы во фразе CURRENCY SIGN (ВАЛЮТНЫЙ ЗНАК) было запрещено. Предполагается, что эти изменения коснутся некоторых имеющихся программ.

4. Фраза RELATIVE KEY (ОТНОСИТЕЛЬНЫЙ КЛЮЧ) (1 ОТД). Дан­ное относительного ключа, указанное во фразе RELATIVE KEY (ОТНОСИ­ТЕЛЬНЫЙ КЛЮЧ), не должно содержать символ шаблона Р (М).

Обоснование

В ГОСТ 22558 допускается, чтобы относительный ключ содержал в строке литер шаблона символ Р (М). Если бы относительный ключ был бы так описан, не все записи в файле были бы доступны программе. Например, данное с шаб­лоном 9Р (9М) может иметь только значения 00, 10, 20, 30, 40, 50, 60, 70, 80 и 90. Это значит, что доступны только записи с этими номерами. Использование такого описания ключа возможно является ошибкой и может диагностировать­ся как таковое в соответствии с настоящим стандартом.

4. Фраза LINAGE (ВЕРСТКА) (2 ПОД). Файлы, для которых указана фраза LINAGE (ВЕРСТКА), не могут быть открыты в режиме дополнения.

Обоснование

Поведение файла, имеющего соответствующую фразу LINAGE (ВЕРСТКА) и открытого в режиме дополнения, определено недостаточно четко в ГОСТ 22558. Например, указано, что значение LINAGE-COUNTER (СЧЕТЧИК-ВЕРСТКИ) при выполнении оператора OPEN (ОТКРЬІТЬ) устанавливается в единицу. Кроме того, в ГОСТ 22558 не определяются значения для файла, имеющего со­ответствующую фразу LINAGE (ВЕРСТКА) и открываемого в режиме дополне­ния.

Возможность режима дополнения при открытии файла, имеющего связанную с ним фразу LINAGE (ВЕРСТКА), определяется техникой, используемой для реализации таких файлов. Некоторые разработчики реализовали режим допол­нения. для открытия файла, имеющего соответствующую фразу LINAGE (ВЕРСТКА). Другие разработчики запрещают режим дополнения при открытии файла, имеющего соответствующую фразу LINAGE (ВЕРСТКА).

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

4. Вариант FOOTING (КОНЦОВКА) (2 ПОД). Если вариант FOOTING (КОНЦОВКА) не указан, не выполняется никакое условие конца страницы, не­зависимо от условия переполнения страницы.

Обоснование

В ГОСТ 22558 спецификации поля концовки во фразе LINAGE (ВЕРСТКА) и операторе WRITE (ПИСАТЬ) противоречивы. Некоторые имеющиеся реали­зации обеспечивают для поля концовки одну строку, в то время как другие реа­лизации не обеспечивают поле концовки, если фраза FOOTING (КОНЦОВКА) не указана. Это несоответствие нельзя разрешить, не затрагивая некоторые имею­щиеся реализации. Новое правило базируется на принципе:

если поле концовки не указано, значит оно нежелательно.

Таким образом, если фраза FOOTING (КОНЦОВКА) не указана во фразе LINAGE (ВЕРСТКА), то не существует поля концовки и не выполняется усло­вие конца страницы. Это изменение повлияет только на те программы, в кото­рых для файла не указан вариант FOOTING (КОНЦОВКА) во фразе LINAGE и которые используют оператор WRITE (ПИСАТЬ) с вариантом END-OF-PAGE (В КОНЦЕ СТРАНИЦЫ) для этого файла и используют имеющуюся реализа­цию, обеспечивающую поле концовки.

4. Фраза OCCURS (ПОВТОРЯЕТСЯ) (2 ЯДР). Если принимающее дан­ное является данным переменной длины и содержит объект варианта DEPEN­DING ON (В ЗАВИСИМОСТИ ОТ), будет использоваться максимальная длина данного.

Обоснование

В ГОСТ 22558 длина вычислялась по значению данного фразы DEPENDING ON (В ЗАВИСИМОСТИ ОТ) до выполнения оператора. Использование правил ГОСТ 22558 с оператором MOVE (ПОМЕСТИТЬ) или READ INTO (ЧИТАТЬ В) могло привести в результате к потере данного, если значение данного во фразе DEPENDING ON (В ЗАВИСИМОСТИ ОТ) не было установлено для ука­зания длины посылаемого данного до выполнения оператора MOVE (ПОМЕС­ТИТЬ).

FD INPUT-FILE.

01 А.

02 A-TABLE.

03 A-ODO РІС 99.

03 А-ІТЕМ OCCURS 1 ТО 10 TIMES DEPENDING ON A-ODO. WORKING-STORAGE SECTION.

04' B.

02 B-TABLE.

03 B-ODO PIC 99.

03 B-ITEM OCCURS 1 TO 1'0 TIMES DEPENDING ON B-ODO.

ОФ ВХОДНОЙ-ФАЙЛ.

01 A.

02. А-ТАБЛИЦА.

03 А-ОДО Ш 99.

03 А-ДАННОЕ ПОВТОРЯЕТСЯ 1 ДО 10 РАЗ В ЗАВИСИМОСТИ ОТ А-ОДО.

СЕКЦИЯ РАБОЧЕЙ-ПАМЯТИ.

01 Б.

02 Б-ТАБЛИЦА.

03 Б-ОДО Ш 99.

03 Б-ДАННОЕ ПОВТОРЯЕТСЯ 1 ДО 10 РАЗ В ЗАВИСИМОСТИ ОТ Б-ОДО.

Предположим, что в приведенном фрагменте программы A-ODO (А-ОДО) установлено в 10 и B-ODO (Б-ОДО) установлено в 5. Согласно стандарту Кобо­ла для того, чтобы поместить все повторения A-ITEM (А-ДАННОЕ) в B-TABL

E

(Б-ТАБЛИЦА), нужно было бы сначала поместить A-ODO (А-ОДО) в B-ODO* (Б-ОДО). Таким образом, следующие последовательности операторов Кобола эквивалентны:

По настоящему стандарту Кобола

MOVE А ТО В.

READ INPUT-FILE INTO В.

ПОМЕСТИТЬ А В Б.

ЧИТАТЬ ВХОДНОИ-ФАЙЛ В Б.

MOVE A-ODO ТО B-ODO.

MOVE А ТО В.

READ INPUT-FILE.

MOVE A-ODO TO B-ODO.

MOVE A TO B.

ПОМЕСТИТЬ А-ОДО В Б-ОДО.

ПОМЕСТИТЬ А В Б.

ЧИТАТЬ ВХОДНОИ-ФАЙЛ ПОМЕСТИТЬ А-ОДО В Б-ОДО.

ПОМЕСТИТЬ А В Б.

По ГОСТ 22558

Некоторые реализации позволяют, чтобы за таблицами переменной длины в записи следовали другие данные. В следующем примере A-TRAILER (А-ОСТА- ТОК) и B-TRAILER (Б-ОСТАТОК) в некоторых реализациях динамически раз­мещаются во время выполнения программы в соответствии со значениями A-ODO» (А-ОДО) и B-ODO (Б-ОДО).

FD INPUT-FILE.

01 А.

02' A-TABLE.

03 A-ODO РІС 99

03 А-ІТЕМ OCCURS .1 ТО 10 TIMES DEPENDING ON A-ODO;

OS A-TRAILER РІС XX.

WORKING-STORAGE SECTION.

01- B.

021 B-TABLE.

03 B-ODO PIC 99.

03 B-ITEM OCCURS 1 TO 10 TIMES DEPENDING ON B-ODO.

02 B-TRAILER РІС XX.

ОФ ВХОДНОИ-ФАЙЛ.

01 A.

02 А-ТАБЛИЦА.

03 А-ОДО Ш 99.

03 А-ДАННОЕ ПОВТОРЯЕТСЯ 1 ДО 10 РАЗ В ЗАВИСИМОСТИ ОТ А-ОДО.

02 А-ОСТАТОК Ш XX.

СЕКЦИЯ РАБОЧЕЙ-ПАМЯТИ.

01 Б.

02 Б-ТАБЛИЦА.

03 Б-ОДО Ш 99.

03 Б-ДАННОЕ ПОВТОРЯЕТСЯ 1 ДО 10 РАЗ В ЗАВИСИМОСТИ ОТ Б-ОДО.

02 Б-ОСТАТОК Ш XX.

Если значение A-ODO (А-ОДО) равно 10 и значение B-ODO (Б-ОДО) рав­но 5, то, согласно ГОСТ 22558, поместить A-TABLE (А-ТАБЛИЦА) в B-TABLE (Б-ТАБЛИЦА) значило бы поместить только пять вхождений А-ІТЕМ (А-ДАН- ЙОЕ), a B-TRAILER (Б-ОСТАТОК) остался бы без изменения. По правилам, настоящего стандарта вхождения A-ITEM (А-ДАННОЕ) от 6 до 10 было бы то­же помещено, и B-TRAILER (Б-ОСТАТОК) было бы перекрыто.

Если значение A-ODO (А-ОДО) равно 5 и значение B-ODO (Б-ОДО) равно 5, то согласно ГОСТ 22558 поместить A-TABLE (А-ТАБЛИЦА) в B-TABLE (Б-ТАБЛИЦА) значило бы поместить только пять вхождений А-ІТЕМ (А-ДАН- НОЕ), a B-TRAILER (Б-ОСТАТОК) осталось бы без изменения. По правилам настоящего стандарта вхождения В-ІТЕМ (Б-ДАННОЕ) от 6 до 10 будут запол­нены пробелами, и B-TRAILER (Б-ОСТАТОК) изменится.

На программы, соответствующие ГОСТ 22558, это изменение правила пере­сылки не повлияет.

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

4. Символ Р (М) шаблона (1 ЯДР). При ссылке на данное, описанное шаблоном, содержащим символ Р(М.), цифровые позиции, указанные символом Р(М), означают нули в следующих операциях: (1) любой операции, требующей числовое посылаемое данное; (2) операторе MOVE (ПОМЕСТИТЬ), в котором посылаемый операнд является числовым и строка литер его шаблона содержит символ Р(М); (3) операторе MOVE (ПОМЕСТИТЬ), где посылаемый операнд является числовым редактируемым и строка литер его шаблона содержит сим­вол Р(М) и принимающий операнд является числовым или числовым редакти­руемым; (4) операции сравнения, в которой оба операнда являются числовыми.

Обоснование

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

Это разъяснение согласуется с текущими реализациями для общих примене­ний литеры Р(М) в шаблоне в цифровых контекстах и дает согласующиеся ре­зультаты для числовых и буквенно-цифровых пересылок, где посылаемое данное является числовым. Например, в результате пересылки данного, описание кото­рого PICTURE 9Р VALUE IS 10 (ШАБЛОН 9М ЗНАЧЕНИЕ 10), в данные с PICTURE 99 (ШАБЛОН 99) и PICTURE XX (ШАБЛОН XX) в принимающих полях будет 10 в обоих случаях. В более непонятных случаях, где числовые дан­ные не требуются, как и в случае, когда данное сравнивается с буквенно-цифро­вым данным, будет использоваться значение литеры. Таким образом, данное, опи­сание которого PICTURE 9гР (ШАБЛОН 9М) и VALUE IS 10 (ЗНАЧЕНИЕ 10), при сравнении равно данному с PICTURE XX (ШАБЛОН XX) и VALUE IS «1» (ЗНАЧЕНИЕ «1») (за цифрой 1 следует пробел).

Предполагается, что эти изменения стандарта коснутся немногих программ.