In doing some research I stumbled over the obvious fact that many of my SyncSort jobs are creating their output with really bad BLKSIZE factors.
From SYSOUT of a Sync Sort Step:
WER108I SORTIN : RECFM=VB ; LRECL= 3854; BLKSIZE= 32760
WER110I SORTOUT : RECFM=VB ; LRECL= 3854; BLKSIZE= 32760
BLKSIZE is NOT coded anywhere in the JCL. The SMS Compression utility that we use is forcing this blocking factor on the file. This has lead to some odd results:
This particular file has a 90% compression ratio - so it is compressing the file quite well. 41,000 cylinders down to 3450.
If I force an optimal BLKSIZE on the Output of this SORT step the file utilizes 800 less cylinders and DASD and 1/3 less SORTWK areas.
If I force an optimal BLKSIZE on the COBOL Application that creates the Input to the SORT above is doesn't use any less DASD.
I forced the Input and Output to an optimal BLKSIZE in production last night and despite the optimum BLKSIZE on the file it consumed slightly less DASD and didn't help runtimes at all.
So, does Compression show bad blocking factors but work its magic behind the scenes? Is this something I should pursue as a cycle efficiency? Is this something that is expected? Should a file that size be utilizing the MAXSORT option?