I'm having a problem, or rather, *not* having a problem, when executing JCL with mis-spelled or missing DD statements for COBOL program output files. I remember encountering this back in the mid-80's (ouch!) when our MVS systems group changed something. I thought it was a compile or link option, but I cannot find any differences when comparing output from a program compiled/linked on a system where this will cause an abend (message IGZ0035S There was an unsuccessful OPEN or CLOSE of file XXXXXXXX in program XXXXXXXX) and the output from a program compiled/linked on a system where this does not cause an abend.
Note - when executing the JCL on the system where the problem does not occur, the system dynamically allocates a VIO dataset to the missing/mistyped DD name(s).
You're right about using File Status to detect this condition; I had forgotten that was a short-term fix we did until we could figure out a global solution via MVS (at that time) support.
Unfortunately, it's not unusual in our environment to have different OS configurations on the two mainframes I work on, because one of the mainframes was part of an acquisition, and had to remain unchanged. I'll go ahead and contact our systems support and see what they can do, and until then, start using File Status again.
Your mention of using File Status set off some memories so I searched the web with different key words, this time with success!
The problem I'm having (or lack of it) is due to an IBM LE default for a run-time parameter called CBLQDA. The default has this parameter with a value of "ON", which means certain files, such as QSAM output files, will be dynamically allocated to temporary, VIO file, for the duration of the job step. And it does all of this without any messages being posted except to the job log where all of the other messages are written to!!!
According to the information I can gather, this can be overridden via the EXEC statement, or can be changed globally by OS/systems support. I dread to think how many productions jobs will fail if I can convince the client to change this default, but it's better than trying to find a dataset that was never created.