If the dataset is RECFM=F and the tape(s) statistics can be viewed in a
tape management product, the record count can be approximated with the
sum of the block counts of the tape(s) * the block size and then divided
by the LRECL. It is an approximation as it is not known many records are
actually in the last block. So it will be a slight over estimation, but
reasonable one.
If the dataset is RECFM=V, the above formula may be workable. It depends
on what the average LRECL is on the file. Knowing the data structure in
the file helps. Depending on the data, the record count computed times
four worked for the situations that we had. YMMV.
R.S. wrote:
You can try to ICEGENER whole input to DD DUMMY. It will take some
time, but you will get exact number of records and bytes.
Then you'll be able to help DFSORT by using FILSZ with correct size.
Regarding SORTLIB DD - do you need it in *any* sort job, or just this
one?
How the DFSORT was installed? Was it part of ServerPac?
BTW: I just read in documentation that SORTLIB is required when
sortworks on tape are used.
Regards
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
