BLKSIZE=32760 is not very good on DASD, but it's fine on tape. On disk it's using roughly 60% of a 3390 track. That''s just a quick mental calculation, so it could be considerably off.
There can be problems with VB if the LRECL is large compared with BLKSIZE and many real records are close to LRECL since the actual data blocks can potentially be much less than the maximum BLKSIZE. I don't think this is too much of an issue with your data, but it's worth analyzing. Most print type data in programs I write is directed to VBA data sets, so I can't say I've actually observed this problem with my programs where LRECL is typically 125 or 137 and BLKSIZE is system determined BLKSIZE, but you can potentially have this problem.
I don't know how or why SORTIN or SORTOUT BLKSIZE would impact SORTWK usage; it might be a topic worth pursuing with Syncsort support. Perhaps if the moderators would move this topic to the Syncsort section, the Syncsort tech that sporadically audits the forum might pick it up and comment.
When I want to force system determined "optimal" BLKSIZE in JCL, I always specify DSORG=PS in the JCL so the BLKSIZE is calculated when the data set is allocated, rather than in OPEN, when the value is sometimes distorted.
- These users thanked the author steve-myers for the post:
- Akatsukami (Wed Oct 10, 2012 9:06 am)