Page 1 of 2

DFSORT/ICETOOL

PostPosted: Wed Mar 13, 2013 2:12 am
by kgv70
Hi,

I have a requirement, I have huge file with fixed record length of around 10000 and most of the fields are comp-3 fields. I need to unpack all the comp-3 fileds. Is DFSORT/ICETOOL right option for that?

I greatly appreciate your reply.

KGV

Re: DFSORT/ICETOOL

PostPosted: Wed Mar 13, 2013 2:50 am
by BillyBoyo
There is a DFSORT part of the forum. The topic will be moved there after you reply.

To what extent are the COMP-3 fields "contiguous"? If you unpack everything, your record is going to be close to 20,000 bytes, which is even less "efficient" at utilising disk space than your existing 10,000 byte records.

Why do you need to do this?

Re: DFSORT/ICETOOL

PostPosted: Wed Mar 13, 2013 3:02 am
by kgv70
It is almost till the end. I am expecting close to 16000 after unpacking all. It is basically client requirement.

Re: DFSORT/ICETOOL

PostPosted: Wed Mar 13, 2013 5:10 am
by BillyBoyo

Re: DFSORT/ICETOOL

PostPosted: Wed Mar 13, 2013 5:42 am
by BillyBoyo
If you want "Zoned Decimal" output, with an "overpunched" right-most digit for the field which contains F-and-digit or C/D-and-digit, this can also be done with FINDREP, which can also "close up" the intervening byte created by the "separate sign" of the HEX.

You'll need to HEX the different "areas" containing packed data, the number of "areas" depending on how "contiguous" the groups of packed fields are.

  FINDREP=(INOUT=(C'0C',X'0C',C’1C’,X’1C’,C’2C’,X’2C’...)


This will replace the two characters with one byte, reducing the length of the record. You'd need to use this on each "area", using STARTPOS and ENDPOS, in reverse order (last area first, first area last).

The FINDREP values can be "generated" (saves typos). The new "areas" after the HEX can be calculated by multiplying the length HEX'd by two.

A problem you may face is if you have COMP-3 PIC 9(6). This would be converted to a PIC 9(7). If that is no good for you, as you need PIC 9(6), you'd have to include code to get rid of the leading digit (which would always be zero). FINDREP for C'0',C'' with a STARTPOS of the leading byte and DO=1 would get those, but you'd have to work out which need changing, a manual task.

If you have Cobol record-layouts for both files it may be more simple to write a Cobol program, with a MOVE for each non-group item (you'd have to code for identifying which to use in any REDEFINES in the record-layouts).

The MOVEs (I guess there would be a "few" of them) could be generated with an editor macro, or DFSORT.

Re: DFSORT/ICETOOL

PostPosted: Thu Mar 14, 2013 4:07 am
by kgv70
Thank you for your reply.

Currently I am using the JCL with following control card. I tried for only couple of fields and it works fine. I have to repeat this for more than 3000 fields.

OPTION COPY
INREC BUILD=(1,200,
201,4,PD,TO=ZDF,LENGTH=7,
205,4,PD,TO=ZDF,LENGTH=7,
209,4,PD,TO=ZDF,LENGTH=7,
213,4,PD,TO=ZDF,LENGTH=7,
217,4,PD,TO=ZDF,LENGTH=7,
218,4,PD,TO=ZDF,LENGTH=7, ..... so on.

I have a file layout out for old file. I can create a new layout for unpacked fileds and write the COBOL programs.

If my old field is with PIC S9(05)V99 COMP-3, is it O.K to define the unpacked field as PIC S9(05)V99. and move and write.
Do I need to follow any extra steps?

Re: DFSORT/ICETOOL

PostPosted: Thu Mar 14, 2013 10:03 pm
by BillyBoyo
Are your packed fields signed or unsigned? If signed, you'd need ZDC. The method I referred to would work, I think, without an enormous amount of code, but if you have many packed-decimal fields actually having an even number of digits (including decimal digits) then there'd be extra, and you'd still have to ensure everything matched the new Cobol layout.

In Cobol, you'd just need to the the MOVE, the compiler will handle the rest. All the data will, for definite, match the record layout (watch out for any REDEFINES). It's still lots of source, but all the MOVE statements can be generated (more that one way to do this), then copied into your program.

Re: DFSORT/ICETOOL

PostPosted: Thu Mar 14, 2013 11:30 pm
by kgv70
You asked "Are your packed fields signed or unsigned?" Do mean in the data? Is there any way to find out?

When I check in the file-aid, it appears like this in fmt mode.

10 INCOME-AMT 4/PS 1762.08

Re: DFSORT/ICETOOL

PostPosted: Thu Mar 14, 2013 11:56 pm
by Akatsukami
kgv70 wrote:You asked "Are your packed fields signed or unsigned?" Do mean in the data? Is there any way to find out?

Browse the data set with HEX ON. All but the low-order nybble of the field will be decimal digits (0-9). If that low-order nybble is F, the field is unsigned; otherwise, it is signed.

Re: DFSORT/ICETOOL

PostPosted: Fri Mar 15, 2013 2:22 am
by kgv70
My first records looks like below when I HEX ON. Looks like it is signed. So it will be same signed for all the records or it can be mixed?

 Î ð À   À   Íhæ Íhæ Î ð   * Î ð  n           a    Øäð  Øäð    ð    ð   
072806110611078907890728003507280291000004440080100848008480030800308000                               
160C147C147C158C158C160C002C160C105C0000C0000814C0703C0703C0892C0892C000
Code'd