Displaying a copybook with data

[MrStar]

I often use the display statement to show a fields name and value on SYSOUT, if one of my programs have to report an error/information message to the programmer.
If it's a copybook with many fields it's a lot of statements like
DISPLAY 'FIELD-XX = ' FIELD-XX
DISPLAY 'FIELD-YY = ' FIELD-YY

In the old version of Cobol there was a EXHIBIT statement, but it dissapeard in Cobol 85.

Does anybody know how I make a program that receives a 01-level and then make a display for each field (level) in it ?
Each display shall contain fieldname an field value.

 

[webrabbit]

I don't know of anything, but it wouldn't be that tough to right. I would write it as a subroutine and pass it the 01 area and the name of the copybook file. But I'm sure there is someting out there already.

 

[WMK]

I think that the "expected" replacement for EXHIBIT NAMED (and EXHIBIT CHANGED NAMED) is an

"interactive debugger"

Most of these have "monitor" facilities that show you wnen a data item changes - and what its current value is (with its name).

If you are using this for a "production" use, I sort-of wonder WHY. When would a production program want to display the field name?

Bill Klein

 

[MrStar]

I mean it is good programming to display all involved fields and their values in conjunction with a dump. If a program fail in a DB2 insert, it can be very helpful to see what th eprogram was trying to insert. I know that I just can display the whole 01-level, but then I have to compare it with the copybook (start position and length of each feld) and furthermore if it contains binary fields i have to translate them before I can se the contents.

It is much easier to code the display statements when you make the program.
And it would be very easy if I just could send the 01-level to an submodule, and let it make the displays. The problem is - how do I get the field-names to alle the filds in the 01-level ?

 

[razalas]

Bill,

I can think of two situations where the programmer may wish to display a field (or other program element) name:

1) while testing. This is mostly covered by the "interactive debugger" you mentioned.

Except that in certain conditions (i.e. long-running jobs) it would be nice to automate the display of diagnostic info. Also in some environments the debugger may not be available or not up to the level of sophistication desired.

2) when program detects an error condition. This can mostly be handed by the various "dump" facilities (e.g. symdump in OS/390).

Except that under certain conditions it would be nice to control the amount/quality of information displayed. also in some environments "dump" facilities may be nonexistent, limited or not up to the level of sophistication desired.

I have always felt that it would be nice to have a feature similar to "LENGTH OF", say "NAME OF", to provide access to the names of various program elements. This would help programmers to write programs that can "talk" about themselves.

Perhaps something like this will come from the object extensions to Cobol, or maybe its already available. If so, I would certainly appreciate hearing about it.

"Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[WMK]

If we're talking about dumps in an IBM mainframe environment, check out

"Creating a formatted dump"

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/1.13.1.1

Alternatively, add-on products such as Abend/AID do this as well.

Bill Klein

 

[stevexff]

LE/370 formatted dumps will print out the contents of variables if you compile with the right options. I haven't used it myself, but our dumps have a message

MYPROG was not compiled with the SYM suboption of the TEST option. A formatted variable dump cannot be produced.

So that looks like the option you need.

Obviously, that's only any use if your program goes wrong badly enough to produce a dump.

 

[WMK]

No, LE formatted dumps are NOT limited to times when your program abends. You can (following the link I provided above) explicitly CALL "CEE3DMP" with various options to get a formatted dump - and then continue processing (if appropriate).

FYI - when using the "SYM" option, also look at the "separate" feature so that the "symbolic" information can be stored in a separate dataset rather than in your load module.

Bill Klein