View previous topic :: View next topic
|
Author |
Message |
Bill Woodger
Moderator Emeritus
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. |
|
Back to top |
|
|
rajatbagga
Active User
Joined: 11 Mar 2007 Posts: 199 Location: india
|
|
|
|
Bill Woodger wrote: |
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.
Regards,
Rajat
Regards,
Rajat |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
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.
|
|
|
Back to top |
|
|
Arun Raj
Moderator
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. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
I hope dr.ostman hasn't been waiting 8 years for a solution. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
nope the &idiot disappeared after having complained about Skolusu skills |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
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. |
|
Back to top |
|
|
Arun Raj
Moderator
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. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3053 Location: NYC,USA
|
|
|
|
rajatbagga, Please start a new topic with new requirement. locked. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
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. |
|
Back to top |
|
|
Arun Raj
Moderator
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. |
|
Back to top |
|
|
|