0

I'm converting some COBOL dat file to ASCII using utility vutil:

vutil -extract input.dat > output.txt

I can't get a human readable response from COMP data fields. Here's is part of my FD file

05 FAT-TIPOFT   PIC 9(4).
05 FAT-DINI     PIC 9(8).
05 FAT-DFIN     PIC 9(8).
05 FAT-IMPON    PIC S9(7)V99 COMP.
05 FAT-INPS     PIC 99.
05 FAT-IMPINPS  PIC S9(7)V99 COMP.
05 FAT-IVA      PIC 99.

And here an ASCII convertion example: 

0107200230062003 ‚p00    20  ³° 6 00     6

The convertion is fine only for the NON-COMP fields

Is there any additional command or alternative utility or technique to convert COMP fields?

Note I don't want to enter into Cobol world, I just want to convert data and get rid of it!

vard
  • 4,057
  • 2
  • 26
  • 46
FAlabi
  • 11
  • 4
  • 1
    If you don't want to enter the COBOL world, why use the COBOL tag? What encoding do you fantastically imagine it is in before you "convert" it? The system is an AcuCOBOL system. Assuming that someone is up-to-date with the license, contact Micro Focus support. I suggest re-phrasing the question to them, although, since you're paying them, they will answer, whatever stupid things you type. – Bill Woodger Aug 10 '15 at 15:17
  • 1
    I also have to wonder about the upvote on that question. There is no conversion. If you got a colleague/friend to vote for your question to make it look more interesting, it hasn't worked. Here's some documentation: http://supportline.microfocus.com/documentation/acucorpproducts/docs/v6_online_doc/gtman1/gt1332.htm. Not even the slightest hint that there is any encoding conversion (because there isn't). You'd best rewrite the question as "here's a four-byte binary field, how do I understand how the decimal part is represented, when the COBOL PICture indicates two decimal places. – Bill Woodger Aug 10 '15 at 16:00
  • Let's say you have a four-byte integer, stored in a file, by whatever language you like. Now, your task, is to take that data, and "do something" with it to "convert it to ASCII" without any reference to the original program which created that record. – Bill Woodger Aug 10 '15 at 19:50
  • How to convert a four-byte integet to ASCII will be my next attempt, if no other solution is possible. I just have few tables to convert, i hope i don't have to learn such a low level headache for this temporary issue. – FAlabi Aug 11 '15 at 08:28
  • It's not a question of hoping that you don't have to learn such a low-level headache, it is that you would be incapable of that (you have no clue about what you are speaking of). How can you convert a binary value to ASCII? It is a meaningless statement. @Bruce Martin's number three is the only reasonable way for you to proceed, because you don't know enough and you have no intention of finding out. You need to be spoon-fed, Bruce has done it. Don't, please, attempt on your own to covert those binary values to character. – Bill Woodger Aug 11 '15 at 08:55
  • You didn't specify the source of your data. Did it come from an IBM, Unisys 2200, Unisys MCP, or HP Mainframe? The data won't be the same from all COBOL sources because the encoding is different. – Kennah Aug 25 '15 at 17:53

1 Answers1

2

Possible solutions:

  1. You may not want to write a Cobol program, for one file, it will probably be the quickest & cheapest solution.

  2. There are various commercial packages that claim to read Acu Cobol files, probably expensive though.

  3. For this file, you could look at the RecordEditor, with a bit of fiddling you might (and I do mean might) get it work. For this Cobol-Copybook try importing it as a Mainframe or Open-Cobol copybook. I suspect Open-?Cobol Microfocus might be better. (Note: I am the author of the RecordEditor)

I think data might be, with out the binary file and the original data, I can not be sure.

The first 16 bytes in the supplied data look like 2 dates, so I have aligned with FAT-DINI/FAT-DFIN, this is just a guess though:

    0107200230062003  ‚p00    20
22223333333333333333008733000033
00000107200230062003002000000020

in The recordEditor I get:

enter image description here

In the RecordEditor lib directory, there is a JRecord.properties for "defining Cobol dialects".

Bruce Martin
  • 10,358
  • 1
  • 27
  • 38
  • `I don't want to enter into Cobol world, I just want to convert data and get rid of it!` so neither 1 (lots of COBOL code) nor 3 (needs that copybook) are viable :-) Number 3 is the way to go, though... – Bill Woodger Aug 11 '15 at 06:18
  • An external tool to convert data and don't think anymore about them It's the best solution for my need. I'm playing with the The recordEditor, I let you now if it wil work for me. – FAlabi Aug 11 '15 at 08:13
  • Finally IT WORKS! Thanks to Bruce Martin and his very good software, you save me loads of time. – FAlabi Aug 11 '15 at 08:49
  • Both the configuration you suggested for copybook ,"Mainframe" and "Open-Cobol" works. I just had some problem importing the copybook concerning columns (I discover Columns 1-6 in most COBOL layouts are ignored by the compiler, as is everything after column 72). – FAlabi Aug 11 '15 at 09:01
  • For s9(7)V99 comp; it is nearly always same no matter the Cobol compiler (big endian 4 byte integer). The difficulty is with positive comp and other sizes (e.g. is s99 comp one or two bytes). The RecordEditor has a JRecord.properties that let you specify new dialects (with limits of course). – Bruce Martin Aug 11 '15 at 23:21
  • 7-72 is the "normal" columns for cobol (Comes from the old punch cards). In the RecordEditor, the second field on the Cobol import screen lets you specify the copybook format – Bruce Martin Aug 11 '15 at 23:24