View previous topic :: View next topic
|
Author |
Message |
Vijaya Kommuri
New User
Joined: 22 May 2009 Posts: 2 Location: Pune
|
|
|
|
I have a CICS program. I am analyzing to find out whether we can scratch the program if it is not being used by any other transactions or programs. So please specify is there a way to list all the transactions that use that particular program |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Your software configuration management tool would be the place for that information. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
So please specify is there a way to list all the transactions that use that particular program |
No. Depending upon the logic in the program, there could be a program name built in a program that is then used in an EXEC CICS LINK or EXEC CICS XCTL command -- so looking at code will not tell you.
You could run a STAT and see if the program was used during that CICS execution -- but if the program is only used once in a while, you easily could miss the program execution unless you looked at a lot of STAT runs over time. |
|
Back to top |
|
|
Stefan
Active User
Joined: 12 Jan 2006 Posts: 110 Location: Germany
|
|
|
|
You can use the CEMT utility transaction to find all transactions that point to your program. Just enter CICS and type "CEMT IN TRA(*) PROGRAM(ABCDEFG)" to see a list of transactions for program ABCDEFG.
But the more complicated part of your investigations is checking the source of all CICS programs for direct references to your program (as mentioned by Robert Sample in a previous post).
You could also put the load module into a separate library and let the system guys monitor each invocation. I'm not sure if they really will get the transaction that causes the load. You should investigate on this.
A more "brute force" method I've seen a while ago was to delete the load module from the active load libraries. If there is still a calling program, this will lead to a severe error in CICS which can easily be trapped, especially because most application programmers won't have any error handling for PGMIDERR error condition which will raise when linking to a nonexistent program. |
|
Back to top |
|
|
|