IBM Mainframe Forum

Hello,

Before anything else - my apologies for this dumb query, I somehow am unable to interpret the simple English from DFSORT Installation and Customization manual.

z/OS: 2.2
DFSORT: 2.2

Query: I am trying to modify the EXPMAX/EXPOLD/TUNE values at runtime; after a few failed attempts trying to add *PARM* options to JCL, I need to ask - is it even possible? From what I understand ICEPRM and ICEIEXIT options override the DFSORT defaults, but one needs to have requisite accesses to modify the **.PARMLIB, which I am assuming refers to SYS1.PARMLIB (or site specific PARMLIB). OPTIONS doesn't feature EXPMAX, which falls only under ICEAM1, which again is in the PARMLIB; or just as I've stated in the opening statement - I am somehow not comprehending correctly to what the manual states.

It'd be really helpful if someone can kindly show me how this can be done i.e. pass these options (EXPMAX for starters) to a DFSORT JCL at runtime (if it is possible).

Thank you.

the DFSPARM DD perhaps ?

Hello Enrico,

Thank you; that was the first thing that I'd attempted; pasting only the relevant portion of code (the SORT card has other chunk of code as well):



SYSOUT:



SORTSNAP opening lines:



Another desperate attempt adding OPTIONS statement (knowing it well that EXPMAX doesn't feature on it; just for the heck of it):




SYSOUT:



Best Regards.

Unfortunately You will have to do a bit more reading
IIRC not all the options can be overridden in the DFSPARM DD

Hello Enrico,

enrico-sorichetti wrote:IIRC not all the options can be overridden in the DFSPARM DD

You're spot on; which is what made me wonder if a programmer is even allowed to play around with these options at runtime.
Have been trying to dig around, but almost every place I've come across have quoted the manuals verbatim; rarely has anyone shown a real-time application of it.

Digging Further, Digging Further, Digging Further

the logic is that the end user can modify ONLY the options that are NOT a danger for the overall system performance and stability.

Hello Enrico,

Totally agree; but this is causing a problem.
Just the way history would have it, most of the errors are caused due to bad coding; and fixing the entire chunk of code in one-go is a behemoth; until we are fixing the entire thing, need to put in a workaround to handle the workload for the time-being. Issue is because at quite a lot of places wherein intermediate files are required to be sorted, SORTIN and SORTOUT DS are same. SORT code though is fairly simple (in a way irrelevant to the actual issue, only the COPY or FIELDS=(p,m,f,s) matter the most here):

Code:



Problem: the moment data in SORTIN DS exceeds a few Mils, the number of records being handled goes down. For example, for an input of: 1623600 records, out had only: 1443600 records; now, this is something which was working normally on DFSORT 1.12, default; 2.2, DEFAULT options, and whole thing in a way - crashed. When the storage is increased, the number of records being written, gradually increase, until we reach the threshold SPACE value for which all records are processed.

Which was why I was trying to tweak the defaults to see if modifying the values to older default or another value helps out, any guidance on how these can be overridden in JCL itself (and not the **.PARMLIB), would be really helpful.

Page 18 of this Share presentation DFSMS DFSORT: Resource Usage and Understanding states that EXPMAX, EXPOLD, EXPRES are installation options -- I would not expect them to be changeable except by a system programmer modifying PARMLIB (if then). Since they apply to all DFSORT applications executing at any given time, and not just a single invocation, it would not make sense for them to be modifiable by parameters in the JCL.

Thank you Robert, you raise a very valid point; I really hope that it is not so, else it'd be a dud. An application programmer can really not come up with a viable number for these parameters unless they go about a hit/trial with different types of data, building samples. We can recommend a number for these parms but that would be pure conjecture. Can you please recommend another way which we can use to tweak the defaults for the time-being until the application environment is modified.

Best Regards.