EQUALS was not specified in my SORT parms, but it was listed in the OPTIONS display of the output as EQUALS=Y. I am in the process of getting the program rerun with NOEQUALS specified.
C- On Thu, Jan 12, 2023 at 6:06 PM Sri h Kolusu <[email protected]> wrote: > >> 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
