I have a JCL that is sorting millions of records (record length of 28,704). We noticed that we were running out of workfiles (the default of 32). we recently added the parameter to override the default value of 32 work files to 255.
We found a couple of tips of the syncsort website that told us how many cylinders each workfile would use and doing out the math, it looked like we would need at least 200 workfiles. Another recommendation said to have 130% space available for maximum performance. This lead to us specifying the max amount of workfiles (255). We are aware of the extra overhead involved by adding the extra file.
To the point AKA the question
will using these parameters in our sort:
//SORT10 EXEC PGM=SYNCSORT,COND=(8,LT),
// PARM=('INCORE=OFF,DYNALLOC=(SYSDA,255)',EQUALS)
cause it to always allocate 255 workfiles, or will it allocate the minimum that is required up to a max of 255.
The Manual will be your friend (if you don't have one, you should be able to obtain one). It would also be useful to know the options that SyncSORT at your site has been installed with.
There is probably some "overhead" in establishing 255 as a default. However, even with 255, only work data sets that are required will actually be opened and used in any given step.
It would be common for a fairly small number (say six) to be established as the default, with overrides for steps which are known to require more workspace.
The best suggestion I can make is to make two queries to SyncSORT support: how to establish a reasonable number for DYNALLOC for 99.999% of our SORTs; what to specify for work space for xyz step which has this many records of this size.
If you provide to them the information they want, they will provide specific information that relates to how your site is using SyncSORT (they may even make other suggestions) and to your data.
You are paying for support. So use it. Any time you have something exceptional or which isn't behaving in reasonable way. Contact SyncSORT.
It is probably not possible for you to individually contact SyncSORT without permission from the person who has that as part of their role. So you have to find that person. If you do get nowhere with with, their website is obvious, and support email address available - but they will need a license number, and the person at your site who didn't want to make the contact, may find out about it :-)
Expect substantial resource-savings and increased robustness after considering their advice and applying what you are able to.
Anyone who is at a site which is licensed to use SyncSORT can obtain a free copy of the documentation. It will require the supply of some information. There are Terms and Conditions to its use (once you have your own copy, you are not allowed to distribute it, for instance). You want the Programmer's Guide. There are some further publications you can request at the same time: Installation Guide; Exploiting MFX: SortWriter Data Utilities Guide; Exploiting MFX: MAXSORT; Exploiting MFX: JOIN.
One thing they don't document is SyncTOOL. If you contact SyncSORT support about this, you will be referred to IBM's DFSORT documentation for ICETOOL, which is in the DFSORT Application Programming Guide.
There are over 40 options which can be set to establish how SyncSORT operates (and your Sysprogs will be dealing with tens or hundreds of IBM and ISV packages, each with their own installation/customisation and with multiple methods of applying changes). Many of the operations relating to the technicalities of operation interact with each other. It won't necessarily be clear to someone who is not extremely experienced with the innards of SyncSORT exactly what is best for your site, with the hardware, software and policies your site is running, for a particular unusual SORT.
What is an "unusual SORT"? Any SORT that isn't usual. SORTing millions of 28000-byte records is unusual. It's not something you want to take six time to get it to run, and then find it is slow (which means expensive).
Although I have a certain amount of experience, I would not hesitate to contact SyncSORT over your unusual SORT. They are far more likely to get it right than I am, in far less time.
I would hope that the installation options were chosen with support from SyncSORT. A small number of DYNALLOC files is normal and will be sufficient for most SORT steps. If something changes (new hardware, software, taking on a mass of new data, etc), and you suddenly have many steps failing, SyncSORT support is a very good choice, even after upping the DYNALLOC and all being fine. It may be fine, but 3% less efficient, which is 3% more expensive :-)
Although support contracts can have elements of individuality, I've never heard of one from SyncSORT which pays for support calls. Maybe I just don't get out enough.
One point about support calls is the amount of information you may have to provide. That can be "fun", especially for suspected bugs. But it will pay off. That is perhaps more likely the reason your technical staff are wary.
SyncSORT support will take very minor queries: trivial question directed by SyncSORT Technical Architect to SyncSORT Support.