We have a need to execute a local mode reporting program (written in house) and have it check, in real time, a flag in a control record that is updated by the operator using a CV task.
The process we had in place was working, but not reliably. The problem is/was that unless the page containing the control record is flushed from the local mode buffer pool, the program was consistently getting the record with the stop flag turned off, even though the operator had gone online and told the program to stop processing. Eventually the program either completed, or read the right mixture of records the cause the control record to be flushed so that it was read again and the program saw that it was time to stop.
We (the DBAs) wrote a program that would run in CV mode to retrieve a program's control record and return the record to the calling program for decision making.
This program dynamically changed the SYSCTL file to another name, bound a rununit, and the reset the SYSCTL file to the default. The called routine managed its rununit itself and, when it was found to be gone, say for a timeout, it would rebind itself and then continue doing its retrieval on behalf of the calling program.
This was all fine in test but failed on its first execution in production due to a security violation on the SYSCTL dataset. Seems only the production batch id, system programmers and the DBAs have access to the SYSCTL dataset in production. Learned something that day!
Okay, so I came up with an alternative method, that I don't like.
I coded up an IDMSOPTI module for each of our CVs, linked it with IDMS and called it another name (it was a polite one!).
I then cloned the protocol for BATCH and changed the CALL to IDMS to CALL the name I just created.
Change my program to use this new protocol and everything worked as before, just on SYSCTL file was used.
On the surface this is not a big issue, but here's the potential problems I have come up with:
1) If CA changes IDMS and issues an APAR, I have to remember to relink my alternate IDMS module in order to get the APAR into the special interface.
2) If we change SVCs or CV#s for a CV, I have to change my IDMSOPTI parameters, reassemble and link the special interface module.
So, My question boils down to, does anyone do anything like this, multiple rununits, one or more local and one or more CV, all in the same execution step in a batch job and if so, what did you do to get the CV mode to go to CV and, more importantly, the right CV?
Yes, I know, this is crazy, but it uses all documented features of IDMS and nothing based upon any outside knowledge, and it works!