COBOL COMP-3数字格式问题

Question

我有一个cobol“磁带格式”转储，它有一个混合的文本和数字字段。我以二进制数组(字节数组)的形式读取C#中的文件。我有一本书，格式在文本字段上排列得很好。还有一些COMP-3字段。这些字段中的数据似乎与任何BCD格式不匹配。我知道数据应该是什么，我有COMP-3的原始字节。我试着先改用EBCDIC，但没有取得更好的效果。对于如何在内部存储COMP-3数字有任何想法吗？以下是事先知情同意、原始数据和预期数字的三个例子。我知道我的字段位置是正确的，因为数字的两边都有alpha数据，而且所有的位置都是正确的。

第一个例子: PIC的字段是9(9) COMP-3有5个字节的数据，十六进制值是02 01 20 91 22，结果数据应该是一个日期(00CCYYMMDD)。这个具体日期应该是3-17-14。

第二个例子:字段的S9(3) COMP-3数据有2个字节，十六进制值为0A14，结果值应该在900到999之间。我的理解是，"S“意味着最后的咬口应该是0xC或0xD来表示+或-

第三个例子:该字段的S9(15)V99 COMP-3数据有9个字节，十六进制值为00 00 00 0 0 0 80 C，其结果值应为12.00。

好的，感谢那些回应我的人，他们为我指明了正确的方向。这确实是一个ASCII/EBCDIC代表问题。BCD存储在EBCDIC中。使用ASCII到EBCDIC转换表生成格式正确的BCD数字：

我使用这个链接来映射数据：http://shop.alterlinks.com/ascii-table/ascii-ebcdic-us.php

我的数据:0A14转换: 25 3C (原来253是一个有效值，spec是错误的)C= +，一切都很好

我的数据: 01 80 0 C(不包括前导零)转换: 01 20℃12.00 C= +，隐含2位格式，一切良好

我的数据: 02 01 20 91 22转换为: 02 01 40 31 7 F 2014/03/17 (F未被使用)，一切良好

Answer 1

好的，感谢两人的回应，因为他们指出了我的正确方向。这确实是一个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

再次感谢以上两个答案，这使我走向了正确的方向。

Answer 2

没有像COBOL "tape format"这样的东西，尽管这个短语对给你数据的人可能意味着什么。

你问题的线索是你能读懂课文。将其连接到EBCDIC标记和您对C#的引用。

因此，您正在读取数据，这些数据最初来自大型机，很可能是IBM大型机，它使用EBCDIC而不是ASCII。

COBOL不支持BCD。

某种灵魂为你所做的是将数据从EBCDIC“转换”到ASCII。否则你甚至都认不出“短信”了。

不幸的是，这意味着任何二进制或填充-十进制或浮点字段(你不会看到最后的多少，但它们是COMP-1/COMP-2)是“转换”意味着“潜在的置乱”，因为转换是假设单个字节，具有简单的字节值，而所有这些字段都有传统的编码，要么通过多字节，要么通过非EBCDIC值，或者两者兼而有之。

因此: COMP-3 PIC 9(9)。就像你说的，五个字节。它是无符号的，所以最右边的nybble将是F(所有位都打开)。由于符号位置被占用，即使是一个未签名的字段，您的位置也会稍微超出。

在大型机上，它包含一个值X'020140317F'。只有整个领域才能对其价值有任何意义。然而，EBCDIC到ASCII的转换使它成为X'0201209122‘。

多么?

查找X'02'和X'01'的EBCDIC值。他们不会改变。查找X'40'的值，哇，这是一个空格，将其更改为ASCII X'20'。查找X'31'的值。实际上，这里并没有什么特别之处，它已经转换成了比X'7F'更高的东西，但是如果你看一下使用的翻译表，我想你会明白为什么会发生这种情况。X'7F'是双引号，因此会改为X'22'。

您显示的其他值也会遇到同样的问题。

您应该只从大型机上获取只有字符格式的数据。这里有很多答案，你应该看看右边的related。

看看最近的一个问题：用C将COMP和COMP-3填充的十进制转换为可读的值。

Answer 3

好的，让我们看一下第一个例子。给定格式和值，原始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转换.如果是这样的话，您可能无法修复数据，因为转换可能不是一个-1，因此是不可逆的。

查看第二个示例，并使用

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

您应该从25 3C开始，这将符合格式，但不符合您提供的范围。

在第三个示例中，可以将原始01 20 0C转换为01 80 0C，因为20也是一个EBCDIC控制字符，没有直接的ASCII等效字符。

但是，考虑到所有其他例子，我假设存在一些代码页转换问题。如果您使用某种文件传输来将数据从(假设的)大型机中移动，请确保将其设置为二进制模式，并且在将文件拆分为字段之前不要进行任何字符转换，并知道什么是字符，哪些不是。

编辑:您可以找到几个基于EBCDIC和ASCII的代码页这里的列表，或者查找这里作为一个相同的pdf。