Совместимость с Cobol v6.2 NUMCHECK

Question

Мы не можем отключить опцию NUMCHECK для нашего нового компилятора COBOL V6.2, потому что мы не можем доверять содержимому наших числовых переменных. Проблема в том, что когда мы включаем его, он не полностью совместим с COBOL 4, который мы имели ранее в нашей организации. В частности - когда переменная без знака содержит X'123C', COBOL 4 принял бы его и продолжил, но COBOL 6.2 с NUMCHECK(PAC,ABD) завершается и только желает принять X'123F'. Это реальная проблема для нас в отношении ассемблера, вызывающего COBOL, или чтения из файлов и т. Д. Есть ли другой вариант или, возможно, даже PTF, который исправляет это поведение? Можете ли вы указать нам на другие несовместимости, такие как эта, когда NUMCHECK включен, если они существуют? Спасибо! Зоар

Answer 1

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

Обратите внимание, что опция установки NUMCLS для IBM COBOL 6.2 управляет поведением теста класса IF NUMERIC, неявная версия которого генерируется опцией компиляции NUMCHECK. Если ваши упакованные данные определены без знака, т.е.

77  XYZ  PIC 999 COMP-3.

затем в документации указывается, что клев знака x'F'- единственный клев знака, который пройдет тест класса IF NUMERIC. Любое другое значение для знака клев считается недействительным.

Формулировка документации для опции NUMCLS для IBM COBOL 4.2 определенно отличается.

Возможно, вы захотите проверить по адресу http://www-01.ibm.com/support/docview.wss?uid=swg27041164 чтобы узнать, применимы ли какие-либо из PTF к вашей ситуации.

Вы могли бы попытаться поднять проблему с IBM, но вот проблема: если у вас есть неподписанные данные, то можно привести аргумент, который имеет знак клев, указывающий на положительный (x'C') или отрицательный (x'D') знак является недействительным. Я подозреваю, что это одна из причин, почему опция NUMCHECK работает так, как она работает.

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

Все зависит от того, какое поведение вы желаете. Вы говорите, что не можете доверять содержимому ваших числовых переменных. Если это означает, что у вас иногда есть положительный знак x'A'вместо x'C' для положительного значения, вы можете использовать NUMPROC(NOPFD), если действует NUMCLS(ALT).

Другое возможное решение вашей ситуации, если действует NUMCLS(ALT), - это скомпилировать с NUMPROC(NOPFD) и использовать подписанные поля для первоначального хранения ваших данных. Согласно документации, перемещение данных в поле без знака приведет к исправлению знака. Обратите внимание, что NUMPROC(NOPFD) не работает так же хорошо, как NUMPROC(PFD).

Следующее расширение моего понимания документации, знак которой приводит к тому, что тест IF NUMERIC является истинным. У меня нет возможности проверить это, это просто моя попытка перевести неявный язык документации в явную таблицу. Он подчеркивает различия между IBM Enterprise COBOL 4.x и IBM Enterprise COBOL v5 и более поздними версиями.

                      SIGN   COBOL 5+ COBOL 4
NUMCLS NUMPROC SIGNED NIBBLE NUMERIC  NUMERIC
ALT    NOPFD   YES    X'A'   TRUE     TRUE
ALT    NOPFD   YES    X'B'   TRUE     TRUE
ALT    NOPFD   YES    X'C'   TRUE     TRUE
ALT    NOPFD   YES    X'D'   TRUE     TRUE
ALT    NOPFD   YES    X'E'   TRUE     TRUE
ALT    NOPFD   YES    X'F'   TRUE     TRUE
ALT    NOPFD   NO     X'A'   FALSE    TRUE
ALT    NOPFD   NO     X'B'   FALSE    TRUE
ALT    NOPFD   NO     X'C'   FALSE    TRUE
ALT    NOPFD   NO     X'D'   FALSE    TRUE
ALT    NOPFD   NO     X'E'   FALSE    TRUE
ALT    NOPFD   NO     X'F'   TRUE     TRUE
ALT    PFD     YES    X'A'   FALSE    FALSE
ALT    PFD     YES    X'B'   FALSE    FALSE
ALT    PFD     YES    X'C'   TRUE     TRUE
ALT    PFD     YES    X'D'   TRUE     TRUE
ALT    PFD     YES    X'E'   FALSE    FALSE
ALT    PFD     YES    X'F'   FALSE    FALSE
ALT    PFD     NO     X'A'   FALSE    FALSE
ALT    PFD     NO     X'B'   FALSE    FALSE
ALT    PFD     NO     X'C'   FALSE    FALSE
ALT    PFD     NO     X'D'   FALSE    FALSE
ALT    PFD     NO     X'E'   FALSE    FALSE
ALT    PFD     NO     X'F'   TRUE     TRUE
PRIM   NOPFD   YES    X'A'   FALSE    FALSE
PRIM   NOPFD   YES    X'B'   FALSE    FALSE
PRIM   NOPFD   YES    X'C'   TRUE     TRUE
PRIM   NOPFD   YES    X'D'   TRUE     TRUE
PRIM   NOPFD   YES    X'E'   FALSE    FALSE
PRIM   NOPFD   YES    X'F'   TRUE     TRUE
PRIM   NOPFD   NO     X'A'   FALSE    FALSE
PRIM   NOPFD   NO     X'B'   FALSE    FALSE
PRIM   NOPFD   NO     X'C'   FALSE    TRUE
PRIM   NOPFD   NO     X'D'   FALSE    TRUE
PRIM   NOPFD   NO     X'E'   FALSE    FALSE
PRIM   NOPFD   NO     X'F'   TRUE     TRUE
PRIM   PFD     YES    X'A'   FALSE    FALSE
PRIM   PFD     YES    X'B'   FALSE    FALSE
PRIM   PFD     YES    X'C'   TRUE     TRUE
PRIM   PFD     YES    X'D'   TRUE     TRUE
PRIM   PFD     YES    X'E'   FALSE    FALSE
PRIM   PFD     YES    X'F'   FALSE    FALSE
PRIM   PFD     NO     X'A'   FALSE    FALSE
PRIM   PFD     NO     X'B'   FALSE    FALSE
PRIM   PFD     NO     X'C'   FALSE    FALSE
PRIM   PFD     NO     X'D'   FALSE    FALSE
PRIM   PFD     NO     X'E'   FALSE    FALSE
PRIM   PFD     NO     X'F'   TRUE     TRUE

Answer 2

У меня пока нет репутации, чтобы добавлять комментарии, поэтому мне придется добавить еще один ответ. Хотя я один из разработчиков Enterprise COBOL, и я могу сказать, что документы V4.2 немного менее понятны, а формулировка для V6 изменена, но поведение компилятора - нет. Поведение, используемое обоими компиляторами, соответствует столбцу V5 в таблице cschneid выше.

Для числовых тестов классов беззнаковых упакованных и зонированных элементов данных всегда требуется знак x'F', независимо от настроек NUMPROC или NUMCLS. Подписанные элементы позволяют всегда использовать C и D, F с NUMPROC(NOPFD) (независимо от настройки NUMCLS) и A, B и E только для NUMCLS=ALT,NUMPROC(NOPFD). Документация в руководстве по настройке NUMCLS говорит только о подписанных тестах классов.

Что касается исходной проблемы: NUMCHECK ведет себя точно так же, как тест IS NUMERIC, и в обоих случаях знак x'C'считается недействительным для элемента данных без знака, а тест IS NUMERIC или NUMCHECK найдет значение не числовое / недействительное, Поведение, которое вы получаете для всех других операторов COBOL (сравнения, арифметики, MOVE и т. Д.) Со знаком x'C', не определено в NUMPROC(PFD) и может варьироваться между V4/V6, между уровнями OPT в V6, между ARCH уровни в V6 и т. д. В NUMPROC (NOPFD) и в некоторых случаях NUMPROC(MIG) в V4 (MIG не поддерживается в V6) знак элемента без знака переводится в 0xF перед использованием значения в этом элементе данных, поэтому это гарантирует определенное поведение, а также поведенческую совместимость. NUMCHECK, тем не менее, создан для соответствия тесту класса IS NUMERIC, а также для поиска недопустимых данных, чтобы их можно было исправить (иначе нет смысла использовать NUMCHECK, так как тесты, которые он добавляет в вашу программу, негативно влияют на производительность), поэтому он будет помечаться все недействительные данные, даже данные, которые, казалось, "работали правильно" в V4 (что на самом деле означает, что, хотя поведение в NUMPROC(PFD) не определено, оно было, по крайней мере, непротиворечивым).