HP OpenVMS Systems Documentation

HP OpenVMS Debugger Manual

Supported Pascal predefined symbols follow:

Supported Pascal built-in functions follow:

Supported Pascal data types follow:

The debugger accepts Pascal set constants such as [1,2,5,8..10] or [RED, BLUE] in Pascal language expressions.

Floating-point numbers of type REAL may be represented by F_Floating or IEEE S_Floating, depending on compiler switches or source code attributes.

Floating-point numbers of type DOUBLE may be represented by D_Floating, G_Floating, or IEEE T_Floating, depending on compiler switches or source code attributes.

C.12.6 Additional Information

In general, you can examine, evaluate, and deposit into variables, record fields, and array components. An exception to this occurs under the following circumstances: if a variable is not referenced in a program, the Pascal compiler might not allocate the variable. If the variable is not allocated and you try to examine it or deposit into it, you will receive an error message.

When you deposit data into a variable, the debugger truncates the high-order bits if the value being deposited is larger than the variable; the debugger fills the high-order bits with zeros if the value being deposited is smaller than the variable. If the deposit violates the rules of assignment compatibility, the debugger displays an informational message.

You can examine and deposit into automatic variables (within any active block); however, because automatic variables are allocated in stack storage and are contained in registers, their values are considered undefined until the variables are initialized or assigned a value.

C.12.7 Restrictions

You can examine a VARYING OF CHAR string, but you cannot examine the .LENGTH or .BODY fields using the normal language syntax. For example, if VARS is the name of a string variable, the following commands are not supported:

DBG> EXAMINE VARS.LENGTH
DBG> EXAMINE VARS.BODY

To examine these fields, use the techniques illustrated in the following examples.

The following subtopics describe debugger support for PL/I.

C.13.1 Operators in Language Expressions

Supported PL/I operators in language expressions include:

C.13.2 Constructs in Language and Address Expressions

Supported PL/I data types follow:

Variables of the following storage classes are allocated statically:

STATIC
EXTERNAL
GLOBALDEF
GLOBALREF

Variables of the following storage classes are allocated nonstatically (on the stack or in registers):

AUTOMATIC
BASED
CONTROLLED
DEFINED
PARAMETER

The following subtopics give examples of the EXAMINE command with PL/I data types. They also highlight aspects of debugger support that are specific to PL/I.

C.13.5.1 EXAMINE Command Examples

The following examples show use of the EXAMINE command with a few selected PL/I data types.

• Examine the value of a variable declared as FIXED DECIMAL (10,5):

  DBG> EXAMINE X PROG4\X: 540.02700

• Examine the value of a structure variable:

  DBG> EXAMINE PART MAIN_PROG\INVENTORY_PROG\PART ITEM: "WF-1247" PRICE: 49.95 IN_STOCK: 24

• Examine the value of a pictured variable (note that the debugger displays the value in quotation marks):

  DBG> EXAMINE Q MAIN\Q: "666.3330"

• Examine the value of a pointer (which is the virtual address of the variable it accesses) and display the value in hexadecimal radix instead of decimal (the default):

  DBG> EXAMINE/HEXADECIMAL P PROG4\SAMPLE.P: 0000B2A4

• Examine the value of a variable with the BASED attribute; in this case, the variable X has been declared as BASED(PTR), with PTR its pointer:

  DBG> EXAMINE X PROG\X: "A"

• Examine the value of a variable X declared as BASED with a variable PTR declared as POINTER; here, PTR is associated with X by the following line of PL/I code (instead of X having been declared as BASED(PTR) as in the preceding example):

  ALLOCATE X SET (PTR);

  
  In this case, you examine the value of X as follows:

  DBG> EXAMINE PTR->X PROG6\PTR->X: "A"

Note the following points about debugger support for PL/I.

You cannot use the DEPOSIT command with entry or label variables or formats, or with entire arrays or structures. You cannot use the EXAMINE command with entry or label variables or formats; instead, use the EVALUATE/ADDRESS command.

You cannot use the EXAMINE command to determine the values or attributes of global literals (such as GLOBALDEF VALUE literals) because they are static expressions. Instead, use the EVALUATE command.

You cannot use the EXAMINE, EVALUATE, and DEPOSIT commands with compile-time variables and procedures. However, you can use EVALUATE and DEPOSIT (but not EXAMINE) with a compile-time constant, as long as the constant is the source and not the destination.

Note that an uninitialized automatic variable does not have valid contents until after a value has been assigned to it. If you examine it before that point, the value displayed is unpredictable.

You can deposit a value into a pointer variable either by depositing another pointer's value into it, thus making symbolic reference to both pointers, or by depositing a virtual address into it. (You can find out the virtual address of a variable by using the EVALUATE/ADDRESS command, and then deposit that address into the pointer.) When you examine a pointer, the debugger displays its value in the form of the virtual address of the variable that the pointer points to.

The debugger treats all numeric constants of the form n or n.n in PL/I language expressions as packed decimal constants, not integer or floating-point constants, in order to conform to PL/I language rules. The internal representation of 10 is therefore 0C01 hexadecimal, not 0A hexadecimal.

You can enter floating-point constants using the syntax nEn or n.nEn.

There is no PL/I syntax for entering constants whose internal representation is Longword Integer. This limitation is not normally significant when debugging, since the debugger supports the PL/I type conversion rules. However, it is possible to enter integer constants by using the debugger's %HEX, %OCT, and %BIN operators, because nondecimal radix constants are assumed to be FIXED BINARY. For example, the EVALUATE/HEXADECIMAL 53 + %HEX 0 command displays 00000035.

C.14 RPG II (VAX Only)

The follow subtopics describe debugger support for RPG II.

C.14.1 Operators in Language Expressions

The following operators are supported in language expressions when the language is set to RPG II:

Supported constructs in language and address expressions for RPG II follow:

Supported RPG II data types follow:

With RPG II programs, you can set breakpoints using source line numbers, logic cycle labels, user-defined tag names, and subroutine labels. Debugging RPG II programs is somewhat different from debugging programs in other languages, and the additional topics explain where and how you can set breakpoints or tracepoints.

C.14.4.1 Specifications

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