6

我有一个 ascii 文件，它是来自基于 cobol 的系统的数据转储。

文档说有一个字段是PIC S9(3)V9(7)..

以下是十六进制（和 ascii）字段的两个示例以及它们代表的结果数字（取自另一个来源）。

Hex                                Reported value 

30 32 38 36 38 35 38 34 35 46      28.687321
ascii : 028685845F

30 39 38 34 35 36 31 33 38 43      -98.480381
ascii : 098456138C

我正在使用 ruby​​，即使添加了隐含十进制，我似乎得到的数字也不正确。我正在尝试解析IBM Cobol Docs，但我将不胜感激。

给定“PIC S9(3)V9(7).”的隐含十进制 Cobol 字段，如何使用 ruby​​ 将其转换为有符号浮点数？

4

3 回答 3

0

Assuming the data bytes have been run through a dumb EBCDIC-to-ASCII translator, those two values are +28.6858456 and +98.4561383. Which means whatever generated that "reported value" column is either broken or using different bytes as its source.

It looks like the reported values might have been run through a low-precision floating-point conversion, but that still doesn't explain the wrong sign on the second one.

于 2012-11-20T13:21:47.313 回答
0

正如 Mark Reed 所说，我认为这些数字是 +28.6858456 和 +98.4561383。

但是您可以参考这个惊人的文档，了解 ascii 和 EBCDIC 之间的有符号数字： EBCDIC to ASCII Conversion of Signed Fields

希望对你有帮助

于 2014-05-15T19:46:41.700 回答
0 
028685845F
098456138C

It's likely that the 2 strings in ASCII was converted from EBCDIC.

These are zone numbers with a sign nibble turn into a byte at the end. Like others have said, the F and C are the sign nibbles.

Check this webpage http://www.simotime.com/datazd01.htm

  • F is for "unsigned"
  • C is for "signed positive"

The PIC S9(3)V9(7) is telling you that it's ddd.ddddddd (3 digits before decimal point, 7 digits after, the whole thing is signed.)

It's possible that the 2 "string" are of different PIC, you will need to check the COBOL source that produced the numbers.

It would be best to get the original, hexadecimal dump of the COBOL data (likely in EBCDIC), and post those. (But, I also realize this is a 7.5year old post, the OP probably moved on already.) What I wrote above is for whoever in the future that bump into this thread.

于 2020-05-30T04:16:40.753 回答