Resolve failures with source-level analysis

[Notilus]

Does anybody know about a tool for OpenVms that can do source level analysis incase of programs failures simply by collecting program and environmental failure information and diagnostics automatically.

Similar to the Abend Aid tool for mainframes.

[Steven Schweda]

You might get more helpful advice if you
describe an actual VMS problem than if you
ask about an analogue for some unfamiliar
tool from some unfamiliar environment.
Especially when the meaning of "source level
analysis", "program and environmental failure
information and diagnostics", and
"automatically" may be a bit cloudy.

[Hoff]

See the OpenVMS Debugger manual.

See the Programming Concepts manual.

http://www.hp.com/go/openvms/doc

The OpenVMS debugger can perform traditional interactive debugging tasks, and can be programmed to debug the program dynamically. You can launch the debugger by the program and on the program and (for instance) on the occurrence of a signal), and can issue commands to enable and display and dump output, etc.

You can also use a signal handler to capture and display context, or to log context.

You can also learn a substantial amount of data from what's included in a typical process stackdump (either assuming your application is primitively constructed and lacks signal handling, or when your signal handlers receive an unexpected signal), if you preserve the machine code listings and linker maps from the image.

As for your specific request, see the debugger manual, and see the information on performing and analyzing process dumps, and on commands such as the following:

SET PROCESS /DUMP
ANALYZE /PROCESS
etc...

Process dumps are a way to roll a process out to disk, and to roll the contents back into the debugger at a later time.

Some related details posted at the HL site:

http://labs.hoffmanlabs.com/node/1438
http://labs.hoffmanlabs.com/node/848
http://labs.hoffmanlabs.com/node/767
http://labs.hoffmanlabs.com/node/800

[Notilus]

Thank for the detailed explanation , I'll try to be more specific. When a COBOL program of mine abends unexpectedly , I want to know the values of all the variables in the WS section without explicity write the Display command inside the code. And by this save me the need to run a debugger that can cause sometimes some serious damage in the DB.

[abrsvc]

I am not aware of any external utility that does this automatically. No extermnal facility could know what you'd like to see. The error handling section of the application should be printing out what ever information is relevant to resolving the problem. This is an applications issue. You should be printing out requried variables etc.

Dan

[Steven Schweda]

> [...] The error handling section of the
> application should be printing [...]

Yup. This sounds to me like a job for an
exit handler. (Luckily, I know too little
about COBOL to make any specific
suggestions.)

[Hoff]

All of what you've added to your posting doesn't really change my answer. (Well, the use of COBOL does mean you don't have direct access to some of the tools, but it also means you're not contending with quite as many pointer constructs.)

There's no magic debugging elixir here.

There's a write-up on exception handling in the COBOL User's Guide, and you can read about on-exception and the declarative use stuff at your leisure. And the COBOL reference manual does indicate that the LIB$ESTABLISH and LIB$REVERT calls are processed by the compiler. And the COBOL user's guide manual points to this code:

CALL LIB$ESTABLISH USING BY VALUE new-handler GIVING old-handler

Lacking gonzo pointer support, COBOL is generally pretty mellow here, so (when it tips over) it tends to be due to problems with error handling upstream; cases where the return status and the IOSB was not checked, or received an unhandled condition value. It can be system service or RTL-related pointer errors, but (unlike Fortran and C and some other languages) COBOL itself doesn't do pointers.

There can be errors and signals in called code, and that can be somewhat more dicy to deal with in COBOL.

It appears that you're hacking around the edges of what is apparently a large and at least partially-COBOL quagmire, and you're clearly unwilling to wade in and fix stuff, or wade in and add on-exception handling, or wade in and add debugging, or wade in and fix the database errors.

There can be very good reasons for your hesitance to wade into any COBOL quagmire here, of course.

And most of these reasons can mean you'll also want to have a discussion with your manager about the requirements and goals and trade-offs here, and/or discussions with some technical folks that can help you code COBOL and to debug applications within this environment.

[Mike Kier]

>Thank for the detailed explanation , I'll try to be more specific. When a COBOL program of mine abends unexpectedly , I want to know the values of all the variables in the WS section without explicity write the Display command inside the code. And by this save me the need to run a debugger that can cause sometimes some serious damage in the DB.

This what the process dump mentioned by Hoff gives you (as long as you have a symbol table either in the image or in a DSF file.

Analyze /Process_Dump puts you in the debugger (not in a running program - no danger to any DB) and you can examine nearly anything you want - values in WS, Call tree, etc. as they were at the time of the abort - you even edit the source code from within the session if you have LSE.

There are logical names that control where the dump gets created - one for non-privileged programs and another for programs installed with privilege. Otherwise the dump in written in the SYS$LOGIN of the username the process was executing under.

[Hoff]

>Thank for the detailed explanation , I'll try to be more specific.

You're in COBOL, but you're not on a Mainframe, so the terms and concepts and implementations will differ.

Please go read the Debugger manual, and please read the Programming Concepts manual, and take a look at the cited page.

That'll help you sort out how VMS does this stuff.

> When a COBOL program of mine abends unexpectedly , I want to know the values of all the variables in the WS section without explicity write the Display command inside the code.

You can write a signal handler, and dump whatever the values you want. Or use the debugger on the fly, and use that to dump the values under program (program, not human) control. Or create and then read in the process dump.

While I clearly don't speak enough IBM to allow my references and my terminology to clarify it for you, what you've now asked for twice is what I've pointed to. And this gets back to why you need to read those two manuals and have a look at those web sites, as that'll give you the terms and constructs and background here.

>And by this save me the need to run a debugger that can cause sometimes some serious damage in the DB.

On re-reading this, this is indicative of a huge problem lurking somewhere here, and well beyond comparatively minor problems like application crashes. If I were in charge of IT here and responsible for this, I'd be screaming about that. Loudly. This is a huge problem with integrity and reliability. If the debugger kicks stuff over as described here, so can a system crash or a power failure or an application bug that triggers a debugger-like wedge.


There's no magic elixir here. Just slogging through the docs, and slogging through the COBOL code fixing (both run-time and what look to be design-level bugs) bugs.

[Robert Gezelter]

Notilus,

The mainframe environment (presumably IBM z/OS, possibly with a monitor such as CICS or a descendant) is dramatically different than the OpenVMS environment.

The OpenVMS Debugger, when used properly, is unlikely (correction: EXTREMELY UNLIKELY) to be the cause in a crash. Mis-use of the Debugger could expose problems in a database environment, but those need to be corrected for other reasons.

COBOL is no different than any other language in this respect. There are a variety of methods that one can use to use the Debugger to automatically take certain steps in the event of a problem. As Hoff has already mentioned, a good careful read of the Debugger manual is clearly in order. These techniques work, having used many of them throughout the years on various projects.

My OpenVMS Consultant column on OpenVMS.org has a bare introductory column on the Debugger ("The OpenVMS Consultant: OpenVMS DEBUG: Often underutilized and unappreciated", accessible at http://www.openvms.org/stories.php?story=09/02/03/2124796; I have not gotten around to writing its successors).

- Bob Gezelter, http://www.rlgsc.com