6

I have an ascii file that is a dump of data from a cobol based system.

There is a field that the docs say is PIC S9(3)V9(7)..

Here are two examples of the fields in hex (and ascii) and the resulting number they represent (taken from another source).

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

I'm using ruby, and even after adding the Implied Decimal, I seem to be getting the numbers incorrect. I'm trying to parse IBM Cobol Docs but I would appreciate help.

Given an Implied Decimal Cobol field of "PIC S9(3)V9(7).", how can I convert it into a signed float using ruby?

sawa
  • 165,429
  • 45
  • 277
  • 381
macarthy
  • 3,074
  • 2
  • 23
  • 24
  • What numbers do you get? From the docs you linked to it looks to me like they should be 28.6858456 and 98.4561383 (both positive) which match the reported values to 2 and 1 decimal places (although with a sign flip in the second). The format suggests the values should have 7 decimal places, but the reported values only have 6. – matt Nov 19 '12 at 09:23
  • Yes from those docs I'm getting the same . However I know for sure that the second value should be a negative value, since these are co-ordinates. I've tried a bunch of other examples and while I get correct to a few decimal places, my conversion is not fully correct. – macarthy Nov 19 '12 at 09:28
  • 1
    The second number is positive. A sign nibble of C, A, F, or E is positive, all others are negative. Perhaps your conversion is correct and your data is wrong. – cschneid Nov 19 '12 at 12:39
  • 1
    If you get the values matt gave you, based on the Hex input, then your conversion is correct. Is it possible that your inputs are being corrupted in some way even before you get to do the conversion? – NealB Nov 19 '12 at 21:24
  • 028685845F is 28.6858456 and not 28.687321, as Neal said is the data being corrupted ???? – Bruce Martin Nov 19 '12 at 21:48
  • I'm started to think that way, myself. The data readme says it is in ASCII, EBEDIC, but I think the COBOL type would have a COMP-3 or something if it was packed somehow. Possible they are mangling the data doing the EBEDIC -> ASCII conversion ????? – macarthy Nov 20 '12 at 04:54
  • So, wait, this is signed data from a COBOL system in which the bytes have been converted from EBCDIC to ASCII as if they were plain text? – Mark Reed Nov 20 '12 at 13:10
  • 1
    You could look at the RecordEditor (http://record-editor.sourceforge.net/), You can import cobol Copybooks (use binary_type=Mainframe) and use it to display the file using the Cobol Copybook – Bruce Martin Nov 24 '12 at 22:54

3 Answers3

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.

Mark Reed
  • 91,912
  • 16
  • 138
  • 175
0

As Mark Reed says i think that the numbers are +28.6858456 and +98.4561383.

but you can refer to this amazing doc for signed numbers between ascii and EBCDIC : EBCDIC to ASCII Conversion of Signed Fields

hope it helps you

Sarabadu
  • 587
  • 2
  • 18
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.

Ka Lam
  • 381
  • 1
  • 6