I am trying to write a cobol program which should read mvs control block and list the modules/programs executed so far as part of the current job step. Can anyone guide me in selecting correct mvs control block for this?
I have started referring 6 volumes of 'IBM MVS Data Areas'. However, I still cannot conclude which variables to use to get this info.
Problem summary:
We have a common cobol program that does some MQ operations as part of its logic. This program is being called by different programs from mulitple applications. Currently this program is issuing MQCONN in its each call. Recently this program was called by a huge volume job. Performance team reported high EXCP counts on SCQAUTH libs. They advised us to remove MQCONN (in other words use MQCONN only once) as it might be the root cause. When we commented MQCONN, we noticed another job failing with S0C4. Cobol programs from that failed job was issuing MQDISC in between which made our common module to fail since HCONN referred invalid address. To resolve this, I thought of checking control blocks to see atleast one invocation of MQDISC happened in the current jobstep.
This common program is supporting large number of programs..It is running fine for calling programs with or without MQDISC.
So I cannot ask those existing applications to remove MQDISC on their code. Also those application programs might be having valid business reasons for issuing MQDISCs on their side.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Please, if using Control Blocks in a program which is "time critical" (ie, you're up the creek if you are unable to run it within 24 hourss), then 1) don't do it, 2) if you instist use Assembler.
IBM provides Assembler Macros for the Control Blocks. If the Control Blocks change due to an Operating System change, then IBM supplies new (and tested) Macros.
IBM provides nothing for COBOL. Notjhing. Nada. Zip. Zilch. Zero. If IBM changes the Control Blocks, then you have to change, and test, the COBOL program.
Oh, and get the Sysprogs to write it. They will be aware first of changes to the Macros, so it makes some sense that they'd be responsible for the code. Then you get the problem of mixed-responsibility for the code. You see, even with nothing else, there are problems inherent in your suggested approach, which do not lead to a stable Prodcution environment.
Now, what you want is possible. However, since the root of the problem is a poor design, and the solution to a particular symptom of the problem is not even proven, then doing such a "fix-up" on the fly is, to my mind, asking for trouble anyway.
Each thing you have so far tried simply broke something somewhere else. Listen to what that tells you, and bear in mind that you'll hear nothing if you "fix it" on the fly.
From your description, the "common COBOL program" is doing the work of three programs (at least). You have an actual "common part", and two (at least) different parts logically before that which need to be used depending on what is needed.
You know what is needed. You can distringush the two (or more) actual routes to the "common program".
Now, you may not want/be able to change every CALL statement so that the correct thing is done. But, you know which programs need to take Route A, and which Route B. Perhaps you'll also find other routes, or other problems, if you actually look.
Within one step, is only one "route" needed?
At the end of the day, someone in a Management position is going to have to make a decision on this. So give at least one good option, and hope they can realise that the Control Blocks idea sound. Yes, expedience sometimes gets into it, but that is not a decision for you. It is one for the IT Director. Don't go getting all "clever" and drop your system deep into the mire somewhere down the line.
