With respect to the other respondents and their literal (and correct) replies here, the PC stuff (in conjunction with the link maps and compiler listings) will get you into the general area of the loop.
Which is interesting.
But not entirely useful.
While the tools cited are all functional, it's also easily feasible to snag a few PCs via a simple SHOW PROCESS /CONTINUOUS command.
A half-dozen PCs are often enough data. Particularly if you see a repeated PC or two somewhere in P0 space, then you're usually ready to proceed.
See where those addresses exist within the application.
How to get to the source code from a virtual address? How to translate from those PCs you have? The sequence is described here:
http://labs.hoffmanlabs.com/node/800If that source code not pointing to an obvious trigger, then you can use more specific tools and techniques. In particular, run this application under the debugger. Yes, you can debug detached processes. Here's how:
http://labs.hoffmanlabs.com/node/803You won't be able to debug an installed image, but you can set up the same privileged context for the detached process and run without the INSTALL.
If necessary, you can program the debugger if you can identify a trigger but not its cause. The debugger can then run in the background, waiting for the initial conditions for the loop to be met, and you'll then have some visibility into the run-up to the trigger.
http://labs.hoffmanlabs.com/node/848If you're having difficulty with spotting the trigger with the debugger and with the debugger-level programming, then you can also build the application with the debugger activated in a signal handler, and send the debug signal over.
And if you're using the word "killed" or analogous in conjunction with this effort, then consider switching techniques and using the process dump mechanisms. Dial back the brute-force setting slightly. The debugging sequence and the preference for creating process dumps or crashdumps is analogous to using the >>> BOOT rather than the SRM crashdump command; sure, the immediate freak-out is fixed, but these tend to arise anew, and, well, you can choose to repeat the >>> BOOT or you can write a dump and go looking. In other words, capture a dump or other evidence, and +then+ restart.
As for how, you can use the SET PROCESS /DUMP command, or toss the appropriate $forcex signal over.
That signal can be allowed to cause the dump, or can captured by a signal handler. There's a simple signal handler (in C) here:
http://labs.hoffmanlabs.com/node/1438For typical non-trivial production applications, it's usually best to instrument the code, too. To integrate debugging.
And given the use of COBOL (which avoids many of the foibles of C or Macro or Bliss), my initial suspicion would be in ACMS and system service and RTL error handling; not checking the return status or IOSB, for instance. Even so-called optional IOSB arguments aren't really optional; you should always specify the IOSB, ad always check the return status and the IOSB. Otherwise, errors can tend to accrete, and get weird.
The other and ancillary question would involve why the image is installed. If it is installed for security (privilege) reasons, then subsystem identifiers can be a good alternative.
Stephen Hoffman
HoffmanLabs LLC
