The first example has no debug tool variables (strings that begin with a %); debug tool seems to be happy with explicit names in various combinations, it's only when you attempt to use a debug tool variable that it gets fussy. The only time I found a problem with explicit names (not sure it qualifies as a problem) was when I specified the load module name (either explicitly named, or via %LOAD) and the variable name, with no intervening compile unit or block names. In that case, debug tool was unhappy.

Hunter Cobb
The Trainer's Friend, Inc.
-----------------
Thomas Berg wrote:
-----Ursprungligt meddelande-----
Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Hunter Cobb
Skickat: den 5 mars 2008 21:28
Till: IBM-MAIN@BAMA.UA.EDU
Ämne: Re: SV: SV: Debug Tool know how...

Thomas,

Some experiments with AT CHANGE confirm Don's observations about qualified names in COBOL. I've found that the Debug Tool 7.1 seems to allow at most one variable-based name, provided it's the first name reference in a series of name references. E.g., for a variable named xyz, in block blk1, in compile unit comp1, in load module lm1, you can successfully follow AT CHANGE with:

lm1::>comp1:>blk1:>xyz               [no debug tool variables]
%block:>xyz                                [block qualification variable]
%cu:>blk1:>xyz                           [compile unit qualification variable]
%cu:>xyz                                     [compile unit qualification, 
omitting block specification
%load::>blk1:>xyz                        [load module qualification, with block 
name]
%load::>comp1:>xyz                    [load module qualification, with compile 
unit name]
%load::>comp1:>blk1:>xyz          [load module qualification, with both compile 
unit and block name]

Any attempt to precede a debug tool variable reference with either another debug tool variable reference, or an explicit load module / compile unit / block name seems to fail. I'm not sure whether this is a feature or a problem; as you've noted, the documentation leaves some room for interpretation.

This seems to contradict Your first ("succesfully") example ?
Or do I missinterpret You ?

For what it's worth, in COBOL, the compile unit name is the first PROGRAM-ID in the source module. The block name is the same as the compile unit name, unless you are referencing variables defined in nested programs. A variable defined in a nested program's DATA DIVISION would have the block name of the nested program's PROGRAM-ID, but would have the compile unit name of the outermost program's PROGRAM-ID. Most typically (i.e., in the absence of nested programs), compile unit name and block name are the same, and you would normally only specify one of the two. Load module name is, of course, the member name of the executable program in the load library.

Hope this helps,

Hunter Cobb
The Trainer's Friend, Inc.

Many thanks for the help!

(With the use of "AT ENTRY" I made some progress...)
But how do ordinary cobol qualification work ?
Like "xyz OF abc OF ghi" etc.
I don't seem to get it right, despite "profreading" the variable names and quals in the program. Do DT require ALL quals for a variable ? Like "xyz OF abc OF def OF ghi OF jkl" despite that "xyz OF abc OF ghi" would be enough unique for COBOL.

(It's now quite late here, I will continue tomorrow.)

A part of my log:

...
* The ENTRY SISGB10 ::> SISGB10 breakpoint is replaced. AT ENTRY SISMB10 PERFORM QUALIFY CU SISMB10 ; AT CHANGE WB20-CLNR-XX OF WB20-IMPORT-AVTAL-EV OF SISMB20-DS PERFORM LIST WB20-CLNR-XX OF WB20-IMPORT-AVTAL-EV OF SISMB20-DS ; END-PERFORM ; AT CHANGE WB20-CLNR-LIKV-XX OF WB20-IMPORT-EV OF SISMB20-DS PERFORM LIST WB20-CLNR-LIKV-XX OF WB20-IMPORT-EV OF SISMB20-DS ; END-PERFORM ; AT CHANGE CLNR-LIKV OF MOD-BUFFER PERFORM LIST CLNR-LIKV OF MOD-BUFFER ; END-PERFORM ; END-PERFORM ; * The Entry breakpoint command for SISMB10 :> SISMB10 has been * deferred until the CU appears. * The ENTRY SISMB10 breakpoint is replaced. * *** Commands file commands end *** GO ; GO ; * The variable WB20-CLNR-XX is undefined or is incorrectly * qualified. GO ; * The variable WB20-CLNR-LIKV-XX is undefined or is incorrectly * qualified. GO ; * The variable WB20-CLNR-XX is undefined or is incorrectly * qualified. GO ; * The variable WB20-CLNR-LIKV-XX is undefined or is incorrectly * qualified. GO ; GO ; * The variable WB20-CLNR-XX OF WB20-IMPORT-AVTAL-EV OF SISMB20-DS * is undefined or is incorrectly qualified. * An attempt to automatically restore an AT CHANGE breakpoint * failed. * The variable WB20-CLNR-LIKV-XX OF WB20-IMPORT-EV OF SISMB20-DS * is undefined or is incorrectly qualified. * The variable CLNR-LIKV OF MOD-BUFFER is undefined or is * incorrectly qualified. GO ; * CLNR-LIKV OF MOD-BUFFER = X'40000000' GO ; * CLNR-LIKV OF MOD-BUFFER = ' ' GO ; ...

Thomas
_____________________________________________________________
Thomas Berg Specialist IT Utveckling Swedbank AB (Publ)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to