>> Is 32 bits an optimum choice? A larger pseudo-key would have some impact on >> performance and reduce the maximum supported LRECL.
Gil, There is distinction between maximum supported LRECL (32K) and maximum supported SORT CONTROL FIELDS. The total number of bytes occupied by all sort control fields must not exceed 4092 (or, when EQUALS option is in operation, 4088 bytes). >> And Tom Brennan's fiendish test case would still break it. Perhaps "max >> records" should be a PARM option -- 2**32 is a good compatible default. Did you overlook this statement at the end my last post “Btw if you are running on Z15 and higher you can use sort accelerator(with OPTION ZSORT) which does NOT have that limit.” >> A few contributors have suggested SPLIT; SORT ...; MERGE. If EQUALS is >> (truly!?) needed, would that technique meet the need? Yes, it can. Before they go down that elaborate exercise, OP needs to answer the question “Is EQUALS really needed?” Unless OP cares about the order of duplicate records , there is NO point of having EQUALS and without equals there is no limit to what DFSORT can sort. Thanks, Kolusu DFSORT Development IBM Corporation ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
