Проблема с форматом чисел COBOL COMP-3

Не существует такой вещи, как COBOL "tape format", хотя эта фраза может что-то значить для человека, который предоставил вам данные.

Ключ к разгадке вашей проблемы в том, что вы можете читать текст. Подключите это к тегу EBCDIC и вашей ссылке на C #.

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

COBOL не имеет встроенной поддержки BCD.

Какая-то добрая душа сделала для вас "преобразование" данных из EBCDIC в ASCII. Иначе вы даже не узнали бы «текст».

К сожалению, это означает, что для любых двоичных или упакованных десятичных или полей с плавающей запятой (вы не увидите большую часть последних, но это COMP-1 / COMP-2), это то, что "convert" означает "потенциально зашифрованные", потому что покрытие принимает отдельные байты с простыми байтовыми значениями, тогда как все эти поля имеют обычное кодирование, либо через несколько байтов, либо через значения не-EBCDIC, либо и то, и другое.

Итак: КОМП-3 ПИК 9 (9). Как вы говорите, пять байт. Он беззнаковый, поэтому крайний правый полубайт будет F (все биты включены). Вы немного теряете свои позиции из-за того, что позиция знака занята, даже для поля без знака.

На мэйнфрейме он содержит значение X'020140317F'. Только это поле целиком может иметь какое-либо значение в отношении его значения. Однако преобразование EBCDIC в ASCII сделало его X'0201209122 '.

Как?

Найдите значение EBCDIC X'02' и X'01'. Они не меняются. Найдите значение X'40', упс, это пробел, измените его на ASCII X'20'. Найдите значение X'31'. На самом деле ничего особенного там нет, и он преобразован во что-то более высокое, чем X'7F', но если вы посмотрите на используемую таблицу перевода, я думаю, вы поймете, почему это происходит. X'7F' - это двойные кавычки, поэтому заменяется на X'22'.

Другие ценности, которые вы показываете, страдают той же проблемой.

Вы должны всегда получать данные с мэйнфрейма только в символьном формате. Здесь есть много ответов на этот вопрос, вы должны посмотреть на related справа.

Взгляните на этот недавний вопрос: Преобразование COMP и COMP-3 Packed Decimal в читаемое значение с помощью C

Хорошо, давайте посмотрим на ваш первый пример. Учитывая формат и значение, исходный BCD-контент должен был быть чем-то вроде

02 01 40 31 7F

При преобразовании этого из EBCDIC в ASCII мы сталкиваемся с проблемами с первым, вторым и четвертым байтами, потому что они являются управляющими символами, поэтому здесь нам понадобятся некоторые дополнительные сведения о том, как работал конвертер ASCII-> EBCDIC. Глядя на два оставшихся байта, они будут изменены

EBCDIC     ASCII     CHARACTER
40      -> 20        (blank)
7F      -> 22         "

Предполагая, что первые два байта остаются неизменными, а третий преобразуется как 31->91, мы получаем

02 01 20 91 22

что у вас есть. Похоже, что произошло какое-то преобразование EBCDIC-> ASCII. Если это так, возможно, вы не сможете восстановить данные, поскольку преобразование не может быть однозначным и, следовательно, необратимым.

Рассматривая второй пример и используя

EBCDIC     ASCII     CHARACTER
25      -> 0A        (LF)
3C      -> 14        (DC4)

вы бы начали с 25 3C, который соответствовал бы формату, но не указанному вами диапазону.

В третьем примере исходный 01 20 0C может быть преобразован в 01 80 0C, поскольку 20 также является управляющим символом EBCDIC без прямого эквивалента ASCII.

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

РЕДАКТИРОВАТЬ: вы можете найти список из нескольких кодовых страниц на основе EBCDIC и ASCII здесь или посмотрите здесь за то же, что и один pdf.

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

Во-первых, посмотрите, сможете ли вы заставить ваши компоненты мэйнфрейма преобразовывать все несимвольные (то есть двоичные числовые и упакованные десятичные) данные в формат отображения (например, PIC X), прежде чем загружать его. Тогда вам нужно будет иметь дело только с «печатаемым» диапазоном числовых символов, представляющих от 0 до 9. Преобразование кодовой страницы только для печатных символов является довольно стандартным и, как правило, не так сильно ошибается. Переформатирование данных в тетрадке - не сложная перспектива для любого, кто разбирается в среде мэйнфреймов. К сожалению, иногда вы получаете «обходной путь», и заявляют, что это чрезвычайно дорого или требует специального программного обеспечения, или любого из сотни других поддельных оправданий.

Если вы получили «обходной путь», то лучше всего будет загрузить файл в двоичном формате и выполнить собственное преобразование кодовой страницы для символьных данных (довольно просто). Затем займитесь двоичными данными на основе определений из вашей тетради. С помощью нескольких Google вы сможете найти достаточно информации для преобразования данных PACKED-DECIMAL (COMP-3) во все, что вам нужно.

Вот пара ссылок, с которых можно начать:

Числовые форматы данных

Packed Decimal

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

Хорошо, спасибо обоим людям, которые ответили и указали мне правильное направление. Это действительно проблема представления ASCII / EBCDIC. BCD хранится в EBCDIC. Использование таблицы преобразования ASCII в EBCDIC дает правильно отформатированные цифры BCD:

Я использовал эту ссылку для сопоставления данных: http://shop.alterlinks.com/ascii-table/ascii-ebcdic-us.php

My data:    0A 14
Converted:  25 3C  (turns out that 253 is a valid value, spec was wrong) C = +, all good

My data:    01 80 0C  (excluding leading zeros)
Converted:  01 20 0C  12.00  C = +, implied 2 digits in format, all good

My data:    02 01 20 91 22
Converted:  02 01 40 31 7F     2014/03/17  (F is unused nibble), all good

Еще раз спасибо за два приведенных выше ответа, которые привели меня в правильном направлении.

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