I'm starting to experiment with the many posibilities DFSORT has to offer, and i need to do something, but i have an error
I have a FB Input data set with a Record length of 300 bytes.
The file has multiple fields, but for this issue, I'll break it down to this:
From position 1 to position 112, alphanumeric characters
from position 113 on, there are four ZD fields with a length of 15, that is:
113:15,ZD
128:15,ZD
143:15,ZD
158:15,ZD
Then one indicator byte at position 173 is a character, a C letter or a blank space, and finally, the rest ar alphanumeric characters
I'm using a combination of IFTHEN/BUILD/OVERLAY/AREXP to multiply by minus 1 (-1) any of the ZD fields if the Indicator charater at position 173 is a C. Since i have to perform another operations afer that, I'm using icetool. Here is my code:
IDENTIFIER FROM CALLING PROGRAM IS 0001
BLOCKSET COPY TECHNIQUE SELECTED
VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
- CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R5 - 12:06 ON FRI MAR
SORT FIELDS=COPY
OUTREC IFTHEN=(WHEN=(173,1,CH,EQ,C'C'),
BUILD=(1,111,
(113,15,ZD,MUL,-1),TO=ZD,LENGTH=15,128))
END OF STATEMENTS FROM CTL1CNTL - PARAMETER LIST STATEMENTS FOLLOW
DEBUG NOABEND,ESTAE
OPTION MSGDDN=DFSMSG,LIST,MSGPRT=ALL,RESINV=0,SORTDD=CTL1,SORTIN=E1FIC
IS,SORTOUT=S1DCMISC,DYNALLOC
SORT FIELDS=COPY
RECORD TYPE IS F - DATA STARTS IN POSITION 1
INCONSISTENT *OUTREC IFTHEN 1 REFORMATTING FIELD FOUND
C5-K26318 C6-K90007 C7-K90000 C8-K23476 E7-K24705
END OF DFSORT
And executed correctly, however, the output file wasn't right. The fields in each record were all out of place. I think that since i need to check a character that is in one reformated output field (position 128 and ahead)the DFSORT util doesn't knows what to do.
Since that didn't work, then i tried to change the BUILD by an OVERLAY option, in order to change only the fields affected by the arithmetic operation, however, i have errors and i don't know what is wrong with this:
Code:
OVERLAY=(113,15,ZD,MUL,-1,TO=ZD,LENGHT=15))
However, i can't seem to make Overlay function. This is the result i get ater a CC 16
Code:
IDENTIFIER FROM CALLING PROGRAM IS 0001
BLOCKSET COPY TECHNIQUE SELECTED
VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES
- CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R5 - 12:39 ON FRI M
SORT FIELDS=COPY
OUTREC IFTHEN=(WHEN=(173,1,CH,EQ,C'C'),
OVERLAY=((113,15,ZD,MUL,-1),TO=ZD,LENGHT=15))
$
SYNTAX ERROR
END OF STATEMENTS FROM CTL1CNTL - PARAMETER LIST STATEMENTS FOLLOW
DEBUG NOABEND,ESTAE
OPTION MSGDDN=DFSMSG,LIST,MSGPRT=ALL,RESINV=0,SORTDD=CTL1,SORTIN=E1F
IS,SORTOUT=S1DCMISC,DYNALLOC
SORT FIELDS=COPY
C5-K26318 C6-K90007 C7-K90000 C8-K23476 E7-K24705
END OF DFSORT
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
ojdiaz,
The first control cards did not have the length parameter specified for the field at 158 and that is the cause of the error
The second time you have the length misspelled.
Since your intention is to just modify a few fields use overlay instead of build. Here is the DFSORT JCL which will multiply the quantities at 113,128,143,158 by -1 if the value at pos 173 is 'c'
Well, Actually i?ll sort the fields and then i'll do multiply operation, however, I usually test my sorts before with a SORT FIELDS=COPY
Therefore, in this case i think that i't won't matter, however, if I reformat one of the fields in the sort fields key, if I do it in the inrec or the outrec, i believe it changes the outcome, right?
I mean, If i change the fields in the inrec, the sorted records would be in a different order than if i changed them in an outrce, right?
I think i readed in the manual that Inrec is executed before any other operations specified in a sort card
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
I said
Quote:
Since you are dong a COPY operation, you can use INREC or OUTREC interchangeably.
If you are doing a SORT operation, that's different. INREC is processed before SORT and OUTREC is processed after SORT. So for a SORT operation, the use of INREC or OUTREC can make a difference since SORT refers to the records reformatted by INREC.
Here's a Figure that shows the order of processing for DFSORT control statements:
Thanks a Lot Frank. That, indeed, would make a huge difference if the reformated fields were part of the sorted fields.
Anyway, I'll keep looking at the docs, I usually find answers there, but sometimes the documents are confusing
The next thing i need to find out is if it is possible to validate if a DATE field is logical, i mean, 2009-01-01 is ok, but 2009-01-32 is not logical. I'll keep looking into it, i think it has something to do with the different date formats
