Author: Robert Sample
Posted: Wed Sep 07, 2016 7:48 am (GMT 5.5)
What do you mean by "maximum level of detail" -- it is not clear if you're talking at the program level or CSECT level or what?
Furthermore, what you are wanting to do is EXTREMELY complicated and the specifics change from release to release of z/OS (there's a reason why MAINVIEW, OMEGAMON and such tools cost a LOT of money). As Bill said, you'll need to understand z/OS control blocks, CICS control blocks, CICS internal flow, and a lot more just to start writing the code.
And unless you devise a way to turn your code on and off by transaction, you'll need to write very efficient code since it will be getting executed for every transaction in the CICS region (potentially up to several million times a day).
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Posted: Wed Sep 07, 2016 7:48 am (GMT 5.5)
| Quote: |
| where can i start if I want to write a "self-made monitoring tool" to trace CICS transaction at the maximum level of detail? |
Furthermore, what you are wanting to do is EXTREMELY complicated and the specifics change from release to release of z/OS (there's a reason why MAINVIEW, OMEGAMON and such tools cost a LOT of money). As Bill said, you'll need to understand z/OS control blocks, CICS control blocks, CICS internal flow, and a lot more just to start writing the code.
And unless you devise a way to turn your code on and off by transaction, you'll need to write very efficient code since it will be getting executed for every transaction in the CICS region (potentially up to several million times a day).
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth