IBM Mainframe Forum

This is my first post on this forum, so my greetings to you all.

I'm processing an unloaded DB2 table, in which all the VARCHARS have been padded to their full length, but still have the length field in the first two bytes. So my input record looks like:

rdwfixedfixedfixedllvarchardatapaddedwithx'40'llvarchardatapaddedwithx'40'fixedfixed

So my input fields are all in fixed positions, which is easy enough to process. What I want to do is reformat the output record so that it loses the padding from the VARCHAR fields, so I end up with something considerably shorter, looking like:

rdwfixedfixedfixedllvarchardatallvarchardatafixedfixed

All the information needed to do the reformatting is in the input record, and although I've RTFM'd I can't see a way to get DFSORT to produce the output I want. Does anybody know how to make it produce variable length output fields (kind of like parse, but in reverse I guess).

TIA

Steve

Steve,

The best option is used CHAR function along with IFNULL function on all the varchar columns so that you will have a fixed length output without the special indicators. Parsing would be difficult as you can have embedded spaces in between and every varchar field will have a variable length.

for ex:

Thanks, but I don't want an alternative solution, because the input file format is a given; its creation is not under my control. I have to sort these records in any case, so if I can do the reformat in the same step that would be a bonus. What I need to know is can DFSORT read the input I've got and produce the output I want, or should I look elsewhere to another tool like SAS, SELCOPY or even COBOL?

OK, I can't find anything in the manual that does remotely like what I want, with the possible exception of an E35 exit. I can write one fairly easily, but can anyone please answer the following before I dust off the assembler skills?

1. I already have some INREC processing going on that does IFTHEN OVERLAY processing on my input records. From the flowchart, it looks like this processing will complete before the record gets passed to my E35. Is this correct?

2. I have some OUTFIL BUILD too - does the E35 completely replace this, or does the OUTFIL BUILD get done before the E35 is called?

Thanks

1. Yes, INREC is processed before the E35. The reformatted INREC records are passed to the E35.

2. OUTFIL is processed after the E35. The records returned from the E35 are passed to OUTFIL.

Thanks, Frank

In that case is there an exit point after OUTFIL where I can modify the record? Unless there is an alternative way to produce variable length fields in the output it looks like I will be using some other utility for this...

is there an exit point after OUTFIL where I can modify the record?

No, you would have to have OUTFIL use a temporary data set and then use the temporary data set as input for another pass.

OK, that sounds like it would work - I'll give it a try and post back with the results. May not be today though...

Thanks, Frank

I'd assumed that I would be able to read the input file, process the INREC, write the OUTFIL to a temporary work dataset and then COPY it back with an E35 to shorten the VARCHARs all in one job step. As I can't, then it didn't make sense to use SORT to do the copy and then write an E35 exit to do the reformatting - in this case SORT would only be doing the I/O for me (which might have made sense if I'd had squillions of records - SORT uses EXCP so it might make a performance difference), so I wimped out and used a different utility after my existing SORT which did the job in about ten lines of code.

Well, DFSORT has a lot of function, but it DOES NOT have every possible function (no utility does).