Совместимость с 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

У меня пока нет репутации, чтобы добавлять комментарии, поэтому мне придется добавить еще один ответ.Хотя я один из разработчиков 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) не определено, оно было, по крайней мере, непротиворечивым).

Answer 2

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

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

77  XYZ  PIC 999 COMP-3.

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

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

Возможно, вы захотитепроверьте по http://www -01.ibm.com / support / docview.wss? uid = swg27041164 # 112918 , чтобы узнать, применимы ли какие-либо из 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