I was trying to merge 3 records into one record.I used the approach mention by Ronald in
ibmmainframes.com/viewtopic.php?t=53716&highlight=111x
but when I am using it, it is giving error INVALID DATA SET ATTRIBUTES SPECIFIED SORTIN LRECL. Lrecl of my input dataset is 80.I overrided it with 240 as I have 3 records.
THe post was related to syncsort. Can we override the LRECL in DFSORT.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
If you have the latest DFSORT PTF (Oct, 2010), you can actually use the RESIZE operator of DFSORT's ICETOOL to do this kind of thing quite easily without having to mess with the LRECL. For details and examples, see:
However, if you don't have that PTF, you can override the LRECL with DFSORT. I would have to see your actual JES log (JCL, messages) to help you figure out what you did wrong.
Two reasons that come to mind that might cause this error using the technique I suggested are:
a) the input file RECFM is V or VB (the technique will NOT work for Variable Length files).
b) if SORTIN was a concatenation of files and you did NOT override the LRECL on EACH of the files in the concatenation
Without seeing the JCL, the File attributes (obtainable via ISPF 3.4), and the JES log, it is difficult to guess what actually caused the error. Obfuscate DSN's, data, etc. that are proprietary/ personal/rivate, as necessary.
Enrico, I believe that you have exposed the probable cause.
My fault for not having mentioned the blksize caveat in the prior thread, and in this one.
As an aside, I created an 80 byte dataset containing 6 records (which ended up being blocked at 27920, just as you surmised) and the subsequent SORT failed with the same error indicated by rgupta71. I then re-created the SORTIN dataset with a blksize of 480 and the sort worked like a charm.
0 EXCP ACCESS METHOD USED FOR SORTOUT
0 EXCP ACCESS METHOD USED FOR SORTIN
5 I/O ERROR, DD SORTIN , DEV A83E, ECB 41, CSW 0C40, SENSE 0000
1 EF-K49534 F0-K30362 E8-K51706
0 END OF DFSORT
If an input dataset RECFM is FB, the LRECL can only be overridden as long as the existing BLKSIZE is an exact multiple of the revised LRECL, since LRECL is really just a "logical" attribute - that is, LRECL stands for LOGICAL record length. For example, a BLKSIZE of 400 could contain either 4 100-byte LOGICAL records, or 5 80-byte LOGICAL records, or 8 50-byte LOGICAL records, or 10 40-byte LOGICAL records, etc.
However, an input dataset's BLKSIZE is a "physical" attribute, and it can NOT be successfully overridden. The actual size of every block of an FB dataset must be equal to the (implicit or explicit) BLKSIZE except for the LAST block in the dataset, which can be a "short" block. But whether an FB dataset's block is "standard" or "short", it must always be an exact multiple of the LRECL (whether implicit or explicit).
If your input dataset BLKSIZE is not a multiple of your override LRECL, then the dataset must be reblocked to a BLKSIZE that IS a multiple of your override LRECL before you can use the LRECL override technique. Perhaps the easiest way to do this is by copying/reblocking the original dataset with an IEBGENER step, as follows (note, in a very many shops, a straightforward IEBGENER copy step (i.e. SYSIN is DUMMY) invokes the SORT product under the covers):
