HP OpenVMS Systems Documentation

The following paragraphs describe where you can set breakpoints (or tracepoints) in specifications, using line numbers.

The RPG II program cycle determines the order in which program lines are processed. When setting breakpoints or tracepoints, you can reference the line numbers that RPG II assigns to your program and appear in a listing file or in a debugger source display. The line numbers you specify in columns 1 through 5 of a specification are not used.

The compiler assigns line numbers only to certain specifications at specific points in the logic cycle; therefore, you can specify a breakpoint or tracepoint at these points in the program:

• A breakpoint at a File Description specification occurs before an input or update file is opened or just before an output file is created. The line number of this breakpoint corresponds to the File Description specification for this file.
• A breakpoint at an Input specification occurs before the fields are loaded with data from a record. The line number of this breakpoint corresponds to the record definition in an Input specification.
• You can set two breakpoints for each Calculation specification. The first breakpoint occurs just after testing control-level indicators, if used, and just before testing conditioning indicators. The second breakpoint occurs just before executing the operation code. Use the following syntax:

  SET BREAK line-number.statement-number

  
  For example, assume that a Calculation specification begins with line number 25. The SET BREAK 25.1 command enables you to test indicators. The SET BREAK 25.2 command puts a breakpoint just before the operation code is executed. If a Calculation specification has no conditioning indicators, the SET BREAK 25 command puts a breakpoint just before the operation code is executed.
  You can specify statement numbers only with Calculation specifications that have conditioning indicators.
• A breakpoint at an Output specification occurs after the output buffer has been built but before the record is output. The line number of the breakpoint corresponds to the record definition in an Output specification.

You can specify an RPG II label as a breakpoint or a tracepoint. The following RPG II labels, which correspond to specific points in the logic cycle, are provided in addition to user-defined tags. Note that these labels do not appear in the source code but are accessible from the debugger. The labels do appear in the machine code listing.

For example:

DBG> SET BREAK *TOTL

The EXAMINE command enables you to look at the contents of a variable, the current table entry, an array element, or the I/O buffer.

To examine an array variable, use array syntax as in the following example:

DBG> EXAMINE ARR3(9)    ! Display element 9 of array ARR3
DBG> EXAMINE ARRY(1:7)  ! Display elements 1-7 of array ARRY

Specifying a table name enables you to examine the entry retrieved from the last LOOKUP operation.

To display the contents of the I/O buffer, specify the name of the input file, update file, or output file, followed by the string $BUF. For example, the following command displays the contents of the I/O buffer for the input file INPUT:

DBG> EXAMINE INPUT$BUF

The following command displays the ASCII equivalent of the string STRING, which is 6 characters long:

DBG> EXAMINE/ASCII:6 STRING

To examine a variable which contains the at sign (@), use %NAME as follows:

DBG> EXAMINE %NAME 'ITEM@'

To examine a nonexternal indicator, precede it with the string *IN. For example:

DBG> EXAMINE *IN56
*IN56:  "0"

If an indicator is set off, 0 is displayed. If an indicator is set on, 1 is displayed.

You cannot examine external indicators in this manner. To examine external indicators, you must first link the program with the /NOSYSSHR qualifier; then, use the CALL command, as in the following example which displays the value of U5:

DBG> CALL RPG$EXT_INDS(5)
value returned is 0

Note the following points when using the DEPOSIT command:

• You can deposit a single value into an element of an array using array syntax as in the following example, which deposits the value 150 into element 2 of array ARR:

  DBG> DEPOSIT ARR(2) = 150

• You can deposit multiple values into an array of character strings, by using the /ASCII qualifier with the DEPOSIT command. For example, assume PARTS is an array of 10 elements in program INV.RPG, each a character string of length 3. The following DEPOSIT command deposits the strings P04, P05, and P06 into elements 4, 5, and 6, respectively, of array PARTS:

  DBG> DEPOSIT/ASCII PARTS(4) = "P04P05P06" DBG> EXAMINE PARTS(4:6) INV\PARTS (4): 'P04' (5): 'P05' (6): 'P06'

• Values deposited into numeric fields are aligned on the decimal point. Shorter fields are padded with zeros to the left and right of the decimal point.
• Values deposited into character fields are left justified. If the value contains fewer characters than the character field, the field is padded on the right with spaces.
• To set a nonexternal indicator on or off with the DEPOSIT command, precede the indicator with the string *IN. Depositing the value 1 or 0 sets the indicator on or off, respectively. For example, the following command sets indicator 56 on:

  DBG> DEPOSIT *IN56 = "1"

The EDIT command invokes the RPG II editor rather than the Language-Sensitive Editor.

C.16 SCAN (VAX Only)

The following subtopics describe debugger support for SCAN.

C.16.1 Operators in Language Expressions

Supported SCAN operators in language expressions include:

Supported constructs in language and address expressions for SCAN follow:

Supported SCAN predefined symbols follow:

Supported SCAN data types follow:

There is no specific support for the following data types:

FILE
TOKEN
GROUP
SET

You can use the names of the following SCAN constructs in debugger commands:

procedures
macros
constants
variables
labels

Note the following points about SCAN breakpoints, tracepoints, and watchpoints.

C.16.6.1 Breakpoints and Tracepoints

You can set breakpoints and tracepoints on procedures, trigger macros, syntax macros, and labels, as well as line numbers. For example:

DBG> SET BREAK find_keyword    ! break on a trigger macro
DBG> CANCEL BREAK exit         ! cancel break on label
DBG> SET BREAK compare_trees   ! break on a procedure

Conventional breakpoints and tracepoints are not especially convenient for monitoring SCAN's picture matching. Where do you set a breakpoint or tracepoint to observe the tokens built by your program? There is no statement in your program on which to set such a breakpoint.

To solve this problem, VAX SCAN defines several events. By setting breakpoints or tracepoints on these events, you can observe the picture matching process.

The following event keywords are defined for SCAN programs:

Use these keywords with the /EVENT qualifier of the following commands:

(SET,CANCEL,ACTIVATE,DEACTIVATE) BREAK
(SET,CANCEL,ACTIVATE,DEACTIVATE) TRACE

For example, the following command sets a breakpoint that triggers whenever a TOKEN is built:

DBG> SET BREAK/EVENT=TOKEN

Recognition of SCAN events is enabled automatically by the debugger if the main program is written in SCAN. If you are debugging a program written in another language that calls a SCAN routine, proceed as follows to set up the SCAN environment:

1. Enter the SET LANGUAGE SCAN command to enable recognition of language-dependent operators, expressions, and other constructs (see the SET LANGUAGE command).
2. Enter the SET EVENT_FACILITY SCAN command to enable recognition of SCAN events (see the SET EVENT_FACILITY command). The SHOW EVENT_FACILITY command identifies the current facility and its events.

Note the following points about SCAN watchpoints:

• Variables declared at MODULE level are static by default.
• Variables declared at PROCEDURE or MACRO level are automatic (nonstatic) by default.
• DYNAMIC STRING variables are dynamically built. The storage used to hold the value of the string can change when the value of the string changes. Thus, the storage the debugger is watching may not be the correct storage if the string's value is changed.

The following subtopics explain how to examine and deposit into the following SCAN variables:

STRING
FILL
POINTER
TREE
TREEPTR
RECORD
OVERLAY

If you deposit into a FIXED STRING variable, truncation will occur if the deposited string is longer than the size established by the declaration of that variable.

If you deposit into a VARYING STRING variable, truncation will occur if the deposited string is longer than the maximum size established by the declaration of that variable.

If you deposit into a DYNAMIC STRING variable, truncation will occur if the deposited string is longer than the current size of the variable.

With FIXED and DYNAMIC STRING variables, if the deposited string is shorter than the current size of the variable, the unfilled portion of the variable will be blank padded to the right, with the new string left justified in the variable.

In the case of VARYING STRING variables, the current size of the variable storage space will be adjusted to the size of the deposited string.

C.16.7.2 FILL Variables

Examining a FILL variable causes the contents of the specified variable to be displayed as a string, by default, and so may have little meaning. If the characteristics (or type) of the fill are known, the appropriate qualifier applied to the command will produce a more meaningful display. The following command example shows a fill x that is known to be a single floating number:

DBG> EXAMINE/FLOAT x

You can examine a POINTER by name to find the address of the variable it points to. Use the operator that combines the minus sign and the greater than symbol (->) to examine the variable that is based on the POINTER.

Consider these declarations and assignments:

TYPE symnode: RECORD
                 ptr:  POINTER TO symnode,
                 vstr: VARYING STRING( 20 ),
              END RECORD;

DECLARE x   : symnode;
DECLARE xptr: POINTER TO symnode;
xptr        = POINTER(x);
x.vstr      = 'prehensile';

The following command displays the value of the vstr component of x:

DBG> EXAMINE x.vstr
POINTER\MAINPOINTER\X.VSTR: 'prehensile'

The following command displays the value of vstr based on the POINTER:

DBG> EXAMINE xptr->.vstr
POINTER\MAINPOINTER\XPTR->.VSTR: 'prehensile '

You can examine the contents of the nodes in a tree using the following syntax:

EXAMINE tree_variable([subscript],...)

You cannot deposit into a TREE variable.

If you specify the name of a tree with the EXAMINE command, the debugger displays the contents of all nodes and leaves of the tree. For example:

DBG> EXAMINE voters

You can specify an interior node by entering the subscript for that node. For example:

DBG> EXAMINE voters('salem')

You can examine the leaf node in a tree by specifying all subscripts leading to the desired leaf. For example:

DBG> EXAMINE voters('salem',ward2)

If you examine a TREEPTR variable, such as cityptr or wardptr, the debugger displays the address of that tree node. You examine what a TREEPTR variable is pointing to as follows:

DBG> EXAMINE cityptr->

If you specify a RECORD by name with the EXAMINE command, all components of the RECORD are presented. To examine individual components of the RECORD, specify the full name of each component.

The general format is as follows:

EXAMINE recordname

EXAMINE recordname.componentname.componentname...

You examine an OVERLAY in the same way. All components are again presented; thus, if a four-byte region is a FILL(4), an INTEGER, and a VARYING STRING(2), the four bytes will be displayed three different ways.

C.17 Language UNKNOWN

The following subtopics describe debugger support for language UNKNOWN.

C.17.1 Operators in Language Expressions

Supported operators in language expressions for language UNKNOWN follow: