Thanks, Frank. I got it to work with the syntax you requested.
Unfortunately, the field I am overlaying is invalid data with different hex values, not always x'000000000000'. Is there a way to replace any invalid data as you would in COBOL using not numeric check.
Also, I had to first overlay data in one sort step and then bring to another step to use the edit option298,6,PD,EDIT=(STTTTTTTTT.TTT),SIGNS=(,-).
Otherwise I was getting data exception.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Also, I had to first overlay data in one sort step and then bring to another step to use the edit option298,6,PD,EDIT=(STTTTTTTTT.TTT),SIGNS=(,-).
Otherwise I was getting data exception.
You don't need two steps. You can do it all in one step/pass in several ways with INREC and OUTREC (or OUTREC and OUTFIL) or just with IFTHEN.
Quote:
Unfortunately, the field I am overlaying is invalid data with different hex values, not always x'000000000000'. Is there a way to replace any invalid data as you would in COBOL using not numeric check.
Well, I don't know COBOL, but you can use DFSORT's new NUM function in z/OS DFSORT V1R5 PTF PK90007 or DFSORT R14 PTF PK90006 to check for numerics or non-numerics and do the edit. You didn't say what you wanted to replace the bad values with, so I'll assume it's P'0'. You could use:
We now have the proper PTF. I ran using above code you gave me and my results are not correct.
See code I used:
SORT FIELDS=COPY
ALTSEQ CODE=(0040,4B40,0F40)
INCLUDE COND=(1,8,CH,EQ,C'FF000081')
INREC IFTHEN=(WHEN=(298,6,PD,NE,NUM),
BUILD=(298:+0,EDIT=(STTTTTTTTT.TTT),SIGNS=(,-)))
There are 2 records that are selected. The first record shows up fine and had correct data in position 298. The second record has low-values in position 298 and on output file the record is all spaces except for position 298 which is formated with zeroes.
Does the ifthen and build only pass that field when condition is true. If so,
I would have to include all fiedls in the inrec statement for all fields in BUILD=(...,298:+0,EDIT=(STTTTTTTTT.TTT),SIGNS,...).
The ...s are for the fields before and after the ones you're changing. You need to fill those in to use BUILD successfully (but see my discussion of using OVERLAY below).
The WHEN=(logic) condition gives you +0 in your desired format for records that do not have valid PD values. The WHEN=NONE condition gives you the PD value converted to your desired format for records that do have valid PD values.
Since you haven't specified any fields before or after the 298: item, you get blanks before 298 and then the +0 in your desired format for records that do not have valid PD values. Since you don't have WHEN=NONE, you get the original record (with its original length) for records that do have valid PD values.
Quote:
would have to include all fiedls in the inrec statement for all fields in BUILD=(...,298:+0,EDIT=(STTTTTTTTT.TTT),SIGNS,...).
Since your input field is 6 bytes and your output field is 14 bytes, you can't use OVERLAY unless you want that 14 byte field to be the last field in the record. Otherwise, you will overly the bytes after the original 6 bytes. If that converted field is, in fact, the last field you want, you can use this:
I saw your response. All fields before position 298 and are character fields. I was hoping to not have to name all fields in BUILD statement. I would like to use 2 sort steps, the first it to take input file that has invalid data in position 298 and convert all invalid data to numeric using the NUM feature. This file would be used in another SORT to edit position 298 where I would list all fields for output.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Howard,
We seem to be going around in circles.
You can't overlay a 6-byte input field with a 14-byte field output field without overwriting the 8 bytes AFTER the 6-byte field.
However, since you're doing a BUILD for all the fields anyway, you could overlay the 14-byte target output field with the converted +0 field (for non-numerics) or converted input field (for numerics). But you'd have to know where exactly you're putting the converted output field. You should be able to figure that out from your OUTREC BUILD statement.
So you're converting the 6-byte input PD value to a 14-byte output value at some position in the output record. Let's call that output position c. Once you know what that output position is, you can use these control statements to do what you want in one pass:
Code:
* Convert non-numerics to 14-byte edited +0 value starting in
* output position c.
INREC IFTHEN=(WHEN=(298,6,PD,NE,NUM),
OVERLAY=(c:+0,EDIT=(STTTTTTTTT.TTT),SIGNS=(,-))),
* Convert numerics to 14-byte edited value starting in
* output position c.
IFTHEN=(WHEN=NONE,
OVERLAY=(c:298,6,PD,EDIT=(STTTTTTTTT.TTT),SIGNS=(,-)))
* Insert converted 14-byte edited value directly into output record
* at position c:.
OUTREC FIELDS=(C'"',1,11,TRAN=ALTSEQ,C'"',C',',
...
c,14,C',',
...
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Yes, you can do it, but you have to get the syntax right and you can't overlay 298 with 14 bytes and then expect to put the next field at 304 since that is only 6 bytes away.
Here's an example of the type of DFSORT syntax you need to use:
Code:
OPTION COPY
* If 298,6 is not valid PD numerics, set it to +0.
INREC IFTHEN=(WHEN=(298,6,PD,NE,NUM),
OVERLAY=(298:+0,TO=PD,LENGTH=6),
HIT=NEXT),
* If 304,6 is not valid PD numerics, set it to +0.
IFTHEN=(WHEN=(304,6,PD,NE,NUM),
OVERLAY=(304:+0,TO=PD,LENGTH=6))
* Convert 298 and 304 to displayable format.
OUTREC BUILD=(1,297,
298,6,PD,EDIT=(STTTTTTTTTT.TT),SIGNS=(,-),
304,6,PD,EDIT=(STTTTTTTTTT.TT),SIGNS=(,-))
For the IFTHEN clauses above, HIT=NEXT is not specified for the first IFTHEN clause, so we do not continue to the second IFTHEN clause if the first IFTHEN clause is satisfied.
For the IFTHEN clauses above, HIT=NEXT is specified for the first IFTHEN clause, so we continue to the second IFTHEN clause even if the first IFTHEN clause is satisfied.
For complete details on DFSORT's IFTHEN processing, see: