Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
MVS controlblock to fetch list of programs loaded

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
sentoganesh

New User


Joined: 08 Aug 2013
Posts: 3
Location: India

PostPosted: Thu Aug 08, 2013 5:01 pm    Post subject: MVS controlblock to fetch list of programs loaded
Reply with quote

Hi,

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.

Thanks in advance.
Back to top
View user's profile Send private message

Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1868
Location: UK

PostPosted: Thu Aug 08, 2013 6:25 pm    Post subject:
Reply with quote

Why not use SRCHFOR (3.14) against your source libraries looking for the string MQDISC?
Back to top
View user's profile Send private message
sentoganesh

New User


Joined: 08 Aug 2013
Posts: 3
Location: India

PostPosted: Thu Aug 08, 2013 7:34 pm    Post subject: Reply to: MVS controlblock to fetch list of programs loaded
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Fri Aug 09, 2013 5:37 am    Post subject: Reply to: MVS controlblock to fetch list of programs loaded
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts PLI - printing from multiple programs Pedro PL/I & Assembler 8 Fri Sep 08, 2017 6:36 am
No new posts Need DB2 query to fetch previous row ! Chandan1993 DB2 10 Sat Jun 03, 2017 10:43 am
No new posts member list compare jzhardy TSO/ISPF 6 Fri May 12, 2017 3:18 pm
No new posts Why myself doing Package Bind always ... Susanta DB2 5 Thu Mar 02, 2017 10:47 pm
No new posts SQL query to run through list of valu... Ni3-db2 DB2 14 Wed Dec 14, 2016 9:52 am

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us