Can we convert whole record from comp-3 to readable format?

Bill Woodger · Posted: Sat Sep 29, 2012 11:05 pm

You mean some sort of magic without having to code it out? No.

Probably the easiest way would be with symbols/SYMNAMES. If you have a Cobol layout, there is some REXX supplied which you can use/customise to generate the symbols. If you have some other type of layout, it shouldn't be difficult either, but at the end of the day you'll still have to code for each field, even if the symbols take care of the start-position and length for you.

kkxlnc · New User Joined: 12 Jun 2005 Posts: 44 Location: Boston

Ok. I thought there would be some sort of magic in Sort so wanted to check before I start doing it field by field. I will do it the traditional way.

Thanks for the quick response.

Bill Woodger · Posted: Sun Sep 30, 2012 12:01 am

Well, there are lots of magical things in DFSort, but giving it a lump of various packed-decimal fields and turning them into something else is not one of them :-)

dick scherrer · Posted: Sun Sep 30, 2012 12:11 am

Hello,

Do you have a cobol copybook of both the old and the new format?

If yes, your task might be as simple as a read, a move corresponding and a write . . .

I'm not aware of an automagic solution in a sort product or other utility that does Not have the equivelent of "copybooks".

enrico-sorichetti · Posted: Sun Sep 30, 2012 12:12 am

do You realize that what You posted is just plain garbage...

go to ISPF... browse the dataset object of the question
type HEX ON and paste a couple of records so that we can see
the Hex representation of Your data

USE THE CODE TAGS to preserve the proper aligment

tell the fields that You want to <display> in a readable format
position/length of each

Bill Woodger · Posted: Sun Sep 30, 2012 3:13 am

enrico, with unusual initiative, KK is doing it the "traditional" way - coding it out themselves. They are to be congratulated. No-one here is going to type-up a load of conversions of PD to ZD. If there is a problem with a particular format, an example will probably be provided or hints given as to where to look in the manual.

Dick, DFSort (and the other one) does have "copybooks" (symbols). No "MOVE CORRESPONDING" though :-)

dick scherrer · Posted: Sun Sep 30, 2012 7:43 am

Yup, the ability to use "symbols" is there but if they have not already been defined, this will take a while also. . .

And there may be problems with the initial set of definitions . . .

I've wondered for years why none of the sort products have chosen to support the datanames used in a copy book. The copybook name might be associated with the ddname and the "name" used in place of length,displacement,type?

Maybe there are reasons this would not be desirable?

d

Nic Clouston · Posted: Sun Sep 30, 2012 2:25 pm

enrico-sorichetti · Posted: Sun Sep 30, 2012 8:58 pm

See the "Create DFSORT Symbols from COBOL Copybook" Smart DFSORT Trick at:

Use [URL] BBCode for External Links

dick scherrer · Posted: Mon Oct 01, 2012 1:49 am

Hello,

@Nic
Yup, upon reflection, i agree. While "everywhere" i've ever been use COBOL the most, nearly everywhere also has the other languages available. And the "sort" is meant to be generic . . . So, i take back the question

@Enrico,
Thanks for the reminder - had completely forgotten this

d

Bill Woodger · Posted: Mon Oct 01, 2012 3:32 am

Easytrieve Plus doesn't "natively" have copybooks. It does have parameter-substitution macros. Again the Easytrieve Plus record-layouts could be generated (CA supply a little something as a possible starting point).

If "analysis/design" holds file definitions centrally, per life-cycle stage, then any and all record-layouts for any language/utility should/could be generated from there.

Across multiple languages/utilities you have the "impact analysis" problem of potentially different names. At least if held centrally, all the names should be known.

As I have mentioned before, I find the DFSort Symbols/SYMNAMES, invented by the now-retired Frank Yaeger, incredibly useful. There are "general" solutions that I can write which then only require changes to the symbols to work on completely different files with completely different data. I don't have to touch the code itself. I am stunned by the evidence in this forum of how little DFSort Symbols are used.

With generated Symbols/SYMNAMES you don't get the definition of the data wrong... many typos will not get past the basic checking by DFSort (misspelled Symbols). Unlike when coding start,length,type by hand.

Now, for the task of the TS (they are already off and running with it) symbols aid "half" of the task. Symbols always define source fields only, never the "target" in BUILD/FIELDS/OUTREC/OVERLAY/PUSH (unlike Cobol, PL/I, Easytrieve Plus). With the Symbols, the only "half" of the task remaining is the conversion or EDITing.

dick scherrer · Posted: Mon Oct 01, 2012 7:06 am

Hello,

As far as Easytrieve goes, there is a set of macros that come with the product that will convert a cobol copybook to an Easytrieve layout.

As far as i know, there is still a problem certain kinds of repeating fields, but i've not generated a new Ezt layout for a few years. I seem to remember the problem(s) had to to with ODO or possibly multi-dimension.

Skolusu · Posted: Fri Oct 05, 2012 1:00 am

kkxlnc · New User Joined: 12 Jun 2005 Posts: 44 Location: Boston

I tried this:

TRAILER000167237+000167237+000000000+000076187+000005067+000000000+000000001+000
TRAILER000136667+000136667+000000000+000056550+000004463+000000000+000000000+000

and it works like a charm. Exactly what i was looking for. Thank you very much.