Regarding requirements:

As with any requirement, it needs to be evaluated both for technical 
validity (the ones mentioned in this thread seem valid) and also for their 
likelihood of bubbling to the top of a prioritized list given limited 
resources. Surely this is the case for every company. A request that is 
rejected / declined may be for either reason. 

I cannot speak for SDSF in this regard. But you always have to ask whether 
the product would be better off having implemented this as opposed to 
spending those resources implementing something else. For an individual, 
the answer might be "yes" but not necessarily for the broader community. 
And I make no judgment on the specific thing mentioned for SDSF.

If you want my guess about "dirty getmain" being implemented on a per-job 
basis the answer will be "no". It really is not valid to be used in a 
production environment (because even an application does not in general 
control 100% of what runs, so even an implementation that does this on a 
job or task basis only for problem state user key requests might be 
dangerous and might break things not under your control ). By the way, is 
there anything that is documented to be used only in a test environment 
along with "don't call us if something breaks as a result unless you know 
that it is due to something that that something is not allowed to expect? 
An example of a case that dirty getmain would break that is not truly a 
program error is for a program that runs only as EXEC PGM= and does its 
very first getmain for less than 4K and does not clear the area before 
using it. It will be zeroes without dirty getmain. It will not be zeroes 
with dirty getmain (which has no information available about "first or 
not"). Is it stupid of the program to have such a dependency? Sure? Wrong? 
Not necessarily. 

In general, FWIW, IBM has changed a lot of code over the years to 
accommodate the undocumented option. And we'll likely continue to do. If 
for no other reason than that the option is useless if something normal 
"breaks" because of this, thus inhibiting it from being used at all due to 
its whole-system scope.

If you have a test system, why not try it? It's hardly a secret.

Peter Relson
[email protected] 

Reply via email to