Here is DFSORT/ICETOOL Job which will give the desired results. However there are certain limitations for the job.
1. We can compare upto a max lrecl of 9999.
2. Input files are are always FB (no variable block files)
You need to supply the LRECL of the file to be compared via SYMNAMES DD.
Code:
//SYMNAMES DD *
LRECL,+nnnn
The range of n is from +1 to +4096.
Once you supply the LRECL in STEP0100 of the job it automatically builds the control cards on the fly and the actual compare is done in step0200 using the dynamic control cards created in step0100.
Hello Skolusu, I know it's been a while now, but is the above code still valid.. I tried to run it for 380 LRECL but it failed at STEP0200 giving
Code:
ICE000I 0 - CONTROL STATEMENTS FOR 5650-ZOS, Z/OS DFSORT V2R1 - 15:08 ON TUE SE
OUTFIL FNAMES=OUT,IFOUTLEN=0380,
IFTHEN=(WHEN=(0761,0380,CH,EQ,C' '),BUILD=(01,0380,/,0381,0380)),
IFTHEN=(WHEN=NONE,BUILD=(01,0380,/,0761,0380,/,0381,0380))
ICE146I 0 END OF STATEMENTS FROM CTL2CNTL - PARAMETER LIST STATEMENTS FOLLOW
DEBUG NOABEND,ESTAE
OPTION MSGDDN=DFSMSG,LIST,MSGPRT=ALL,RESINV=0,SORTDD=CTL2,SORTIN=M1,SO
TOUT=OUT,DYNALLOC
SORT FIELDS=COPY
ICE221A 1 INVALID FIELD OR CONSTANT IN OUT IFTHEN 1 CONDITION 1
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Did you attempt to look at the diagnostic message, ICE221A? Poke that into a search and the first hit should be one at IBM, click and you should go to the Knowledgecentre and it should show the full explanation of the record. If you ignore the bits which are obviously, from the actual content of the message in your case, not relevant, then the first line you will come to describes your problem.
Did you attempt to look at the diagnostic message, ICE221A? Poke that into a search and the first hit should be one at IBM, click and you should go to the Knowledgecentre and it should show the full explanation of the record. If you ignore the bits which are obviously, from the actual content of the message in your case, not relevant, then the first line you will come to describes your problem.
Hello Bill, Thanks, I did had a look at the error message, but interesting part is that the same job work perfectly well with 80 bytes of data. However when I used the data with 380 LRECL it failed. I compared the card which are generated in both the cases and they both appear to the same [just the offset values were adjusted accordingly]
I saw that there is a limitation of 9999 LRECL and the file must be FB but that doesn't seem to be true any more... based on the error i received.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
You didn't notice a 256 byte limit?
Quote:
ddname and n>0 indicates that an IFTHEN WHEN, BEGIN or END operand of an OUTFIL statement caused the error. ddname identifies the first data set in the associated OUTFIL group. n identifies the number of the associated IFTHEN clause (starting at 1 for the first IFTHEN clause in the OUTFIL statement).
One of the following errors was detected:
the length for a field with a format other than SS was greater than 256
the length for a PD field not used with NUM was 256
the length for a PD0 field was less than 2 or greater than 8
the length for a CSF or FS field not used with NUM was greater than 32
the length for a UFF or SFF field was greater than 44
the length for a CSL, CST, ASL, or AST field was 1
the decimal constant for an FI field was greater than +9223372036854775807 or less than -9223372036854775808
the decimal constant for a BI field was greater than 18446744073709551615 or less than +0
the number of digits (including leading zeros) in the decimal constant for an FI or BI field was greater than 31
the length for a Y2 field was not 2 for Y2C, Y2Z, Y2P or Y2S, or 1 for Y2D or Y2B, or 3–6 for Y2T or Y2W, or 2–3 for Y2U or Y2X, or 3–4 for Y2V or Y2Y
a Y2 field was compared to another Y2 field with a different number of non-year digits
a Y2 field was compared to a Y constant with a different number of non-year digits
a Y2 field other than Y2S, Y2T or Y2W was compared to Y'LOW', Y'BLANKS' or Y'HIGH'
a Y2 field was compared to a constant that was not a Y constant.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
I think rajatbagga was trying to highlight this point here.
Skolusu wrote:
dr.ostman,
Here is DFSORT/ICETOOL Job which will give the desired results. However there are certain limitations for the job.
1. We can compare upto a max lrecl of 9999.
2. Input files are are always FB (no variable block files)
Not sure if the solution was tested with a dataset as long as 380 bytes back then. Regardless, there had been valid points raised about if this is the right tool to be used for such a requirement.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
The limit mentioned referred to the LRECL, not to the length of a comparison field which was changed eight-and-a-half years later and which couldn't have been predicted at the time.
To compare longer than 256 for a single field, just have it as multiple fields adding up in length to the desired size and use AND.
If after eight-and-a-half years they have a newer release of DFSORT, there's probably a different way to do the whole shebang.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
Bill Woodger wrote:
The limit mentioned referred to the LRECL, not to the length of a comparison field which was changed eight-and-a-half years later and which couldn't have been predicted at the time.
Bill,
Kolusu's dynamic sort as I understand, is to compare each byte of the record since the original 80-byte requirement stated so. So if the SYMNAMES have LRECL=200, it generates control statements to compare each byte from pos-1 to pos-200. However if anyone trying to use this to compare any datasets longer than 256 lrecl to do a byte-by-byte comparison is going to end up with ICE221A error.
Even though I am not so in favor of a SORT approach to handle this, rajatbagga has a point that the '9999 LRECL limit' does not really hold good for comparisons beyond 256.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Yes, but it is not that part which is failing. Take the IFTHEN out and 380 is not a problem (except for with the results). Just changing the IFTHEN should get the thing rumbling again. When giving someone directions to find a place, you don't have to say "remember to wear your trousers!" do you? There's things people should know/be able to work out without being spoon-fed everything.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
All are welcome to take the directions provided here and build on it to achieve what they want. At the same time if something is overlooked, I think we got to admit that too.