steve-myers wrote:I don't use Syncsort, and I do not have access to its documentation, so any advice I can give is very general, but ...
A reasonably accurate estimated record count (or an exact record count) will go a long way towards helping Syncsort run better, especially on a moderately large sort like yours. I don't know if Syncsort does this, but it might be able to deduce a record count from the DCB attributes and data set sizes if the data set is on disk, but for data sets with variable length records like yours its estimate could be way off.
Every unique field definition you specify adds a little bit of overhead for each record. If it is possible, consolidate the fields. This is something you're proposing anyway, but you might find the cost to do this is greater than any benefit you could could get in a Syncsort or DFSORT. The sort products (e.g., Syncsort or IBM's DFSORT) can almost certainly do I/O better than you or me!
I very much doubt that moving the keys within the record will have any impact on sort performance. Perhaps Ms. Margulis can provide more insight into this.The Mean Farmer wrote:... I am curious if I should focus on moving the parts of the key out in position 552, 471, and 494 closer to the front of the records? They are still on the first 1/4 of the max record length.
I just noticed this. With VB records, the start position includes the RDW, the 4 byte prefix of all V format logical records. So, FIELDS=(1,23,...) includes the RDW.The Mean Farmer wrote:...
I have about 20+ Million records a night, LRECL=2171, RECFM = VB
steve-myers wrote:I just noticed this. With VB records, the start position includes the RDW, the 4 byte prefix of all V format logical records. So, FIELDS=(1,23,...) includes the RDW.