On Fri, 13 Jan 2023 00:05:44 +0000, Sri h Kolusu wrote: > >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). > Is that affected by LOCALE? The best-performing way to deal with some natural language locales is probably to translate any string to a single case after suffixing a bitmap indicating the original case of characters. The length of such a mask would need to be included in the total key length.
Does DFSORT use strcoll() for such locales? DFP keys? >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.” > I confess I shot from the hip without reading it. The Ref. has a page of usage notes on ZSORT where I don't see LOCALE mentioned. Some years ago, I went to SR reporting that DFSORT gave correct results for EN_CA but incorrect for EN_US, compared with a desktop sort. SR and I agreed that the problem was in LE, not DFSORT. I went to LE which rebutted with "of course the desktop results are different: desktop is ASCII; DFSORT is EBCDIC." I didn't waste more time arguing with a fool. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
