On Thu, 25 Oct 2018 14:48:24 -0400, David Betten wrote: >If EQUALS is in effect, then DFSORT will always preserve the original order >of records with the same key value. If EQUALS is not in effect, then it is >possible for the sequence of records with the same key value to vary. One >reason this can vary is due to the amount of memory available on the system >since that can impact which sort technique is used. If an incore sort is >done, it's likely (but not definite) that records with the same key may >retain their original sequence. If work files are used (be they memory >object, Hiperspace or disk sortwk), then records with the same key value >might get dispersed to different work files and in the output phase be >merged in a different sequence. Since DFSORT adapts to available >resources, it is not surprising to see this variance. The whole reason we >have the EQUALS parameter, is for situations where maintaining the original >sequence is required. > +1
An insightful analysis. And EQUALS isn't/shouldn't be the default because it may affect performance adversely. But there shouldn't be as many installation default options as other plies have suggested. Programmer skills should be left as portable as possible. Even as I'm irritated when a site aliases "rm" to "rm -i", "mv" to "mv -i", and "ls" to "ls -F". (They're Only Trying to Help Me. Grrr.) Farther off, but somehow related, I was shocked to discover that SQL/DS (DB2 for CMS?) allows duplicate rows in a table. That can barely be described in set theoretic terms. I know; assign a unique index to prevent duplicates. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
