Cobol over/under code

gmburcin · Post by **gmburcin** » Wed Mar 11, 2009 9:33 am

We are using datastage as an ETL tool. We have both server and parallel jobs. We use server because we could write a function to translate the Cobol over/under punches. We want to use the DSJOB report to generate an XML file that we can put job statistics into an Audit table. This, we have working for parallel jobs. However, the DSJOb report XML file is different for server jobs. Is there a way to handle the Cobol over/under punch in parallel?

chulett · Post by **chulett** » Wed Mar 11, 2009 9:48 am

Well... not sure what all of the dsjob comments have to do with the subject line. The PX Sequential File stage has the ability to read those zoned decimal / overpunched fields without needing any special function like Server does.

Set the decimal field Packed attribute to 'Yes' and then a sub-property will become available to specify the fact that it is overpunched. FYI - documented on page 5-26 (in my 7.x version) of the Parallel Job Developer's Guide pdf.

pneumalin · Post by **pneumalin** » Wed Mar 18, 2009 12:41 pm

George, I believe you are asking two questions:
1. Using DSJOB to generate a XML or Text and then parsing the record count info is one of the options. However, there are some other decent ways you can consider to take such as calling DSGetLinkInfo to collect the count.

2. Cobol Over Punch function can be simulated using Basic/PX Routine or a set of Stage Variables. I have done that last year when I helped my client convert the COBOL/PL1 program to DataStage. I will need to dig it out if you need it.

Pneuma.

gmburcin · Post by **gmburcin** » Wed Mar 18, 2009 12:58 pm

I would appreciate looking at your routine.
Thanks
George

chulett · Post by **chulett** » Wed Mar 18, 2009 2:35 pm

I'm wondering why you would need a routine when the stage will (allegedly) handle this for you... are people finding that not to be the case?

Mike · Post by **Mike** » Wed Mar 18, 2009 2:52 pm

The stage handles it just fine if the file has been properly transferred in binary mode. I just created a parallel routine to undo the "corruption" caused by an ascii transfer. That overpunch character has meaning at the nibble level. The meaning is lost in an EBCDIC to ASCII character conversion.

Mike