Introduction

This space is a reference for Code Debug TSO and Code Debug IMS primary and line commands. Syntax, keywords, usage, and examples are provided for the commands, which are listed alphabetically.

Intended Audience

This space is written for application programmers engaged in program development and maintenance. A working knowledge of COBOL, Assembler, PL/I, C language, and your local system environment is assumed.

Accessing Other Products

Code Debug TSO and Code Debug IMS are fully integrated with BMC’s File-AID for Db2 and Abend-AID. From the Code Debug TSO Primary Menu, you can access a CICS region where you can use other tools, such as Code Debug CICS and Abend-AID for CICS. From the Code Debug TSO Primary Menu, you can also access (if installed), File-AID/MVS and File-AID for IMS.

About This Space

This space describes all Code Debug TSO and Code Debug IMS commands. Some commands are only valid for certain languages, and in some cases a command will operate slightly different across languages. Throughout the book are boxes that identify the language for which information is valid. An example of these boxes is shown as follows:

Notation Rules

• Uppercase characters are used in text for commands, keywords, and function keys.
• Screen titles appear in text with initial capitals.
• Information that the user enters is shown in boldface.
• Screen information quoted in the text is shown in boldface.
• Occasional data set and library member names are shown in boldface type for emphasis.
• Valid abbreviated forms of primary commands and keywords follow a general rule.
  • Long abbreviations consist of the first three characters, except where a longer abbreviation is more meaningful. For example, the abbreviation of the keyword STATEMENT is STATE.
  • Short abbreviations consist of the first character, except where another character better represents the word. For example, the short abbreviation of the primary command EXCLUDE is X.
  • Where the single character abbreviation would be the same for two commands, the less frequently used command has only a long abbreviated form.
• Commands are not case sensitive; they can be typed in all lowercase in the command area.

VisualAge PL/I:

The compiler for VisualAge PL/I is somewhat different in the way it handles certain aspects of the language. One such difference involves the method by which statements are identified. Traditionally, each PL/I statement was given a unique statement number for identification in the various elements of the compiler output. Under VisualAge PL/I compilation, however, the identification is less finite, with only the file and line number being used to discern between language constructs.

Because this mechanism is somewhat awkward when using Code Debug, the BMC Language Processor instead associates each file and line number combination with a single sequential line number. It is this generated line number which is used by  Code Debug with VisualAge PL/I programs as the replacement notation for statement number under previous PL/I compilers.

As a result, references to the term “statement” in Code Debug documentation, messages and panels actually refer to the line construct (which may contain multiple statements) in a VisualAge PL/I environment.

Common Parameters

location

A place where breakpoints can be set or deleted. You can specify a valid location list separated by spaces or commas, or a range; for example, statement-number THRU statement-number. THRU is a required keyword when a range is specified.

Valid locations are:

ALL xref

One of the following specifications:

• ALL DLI type

Sets or removes breakpoints on all EXEC DL/I calls within the program. For COBOL and PL/I programs, the breakpoints are set or removed on the generated CALL verb. If the EXEC DL/I statement is not GENned in COBOL, the breakpoint is set or removed on the EXEC statement. For Assembler programs, the breakpoints are set or removed on the BALR 14,15 instruction that branches to the DL/I stub.

You may further qualify the type of EXEC DL/I calls by using the type parameter. For example, ALL DLI GU will set or remove breakpoints on all DL/I GU calls.

• ALL SQL type

Sets or removes breakpoints on all EXEC SQL calls within the program. For COBOL and PL/I programs, the breakpoints are set or removed on the generated CALL verb. If the EXEC SQL statement is not GENned in COBOL, the breakpoint is set or removed on the EXEC statement. For Assembler programs, the breakpoints are set or removed on the BALR 14,15 instruction that branches to the SQL stub.

You may further qualify the type of EXEC command by using the type parameter. For example, ALL SQL SELECT will set or remove breakpoints on all EXEC SQL SELECT calls.

• ALL MQ type

Sets or removes breakpoints on all IBM MQ for z/OS (formerly MQSeries and WebSphere MQ) calls within the program. For COBOL and PL/I programs, the breakpoints are set or removed on the CALL verb. For Assembler programs, the breakpoints are set or removed on the BALR 14,15 instruction that branches to the MQ stub.

You may further qualify the type of CALL command by using the type parameter to set or remove breakpoints on a specific type of MQ call. For example, ALL MQ MQOPEN will set or remove breakpoints on all MQOPEN calls. Other valid types are MQBACK, MQDISC, MQCLOSE, MQCMIT, MQCONN, MQPUT1, MQSET, MQGET, MQINQ, and MQPUT.

• ALL variable

Sets or removes breakpoints on all statements where the variable is referenced.

statement-number

A program statement number.

line-number

A SEQNBR of a line in the compile listing.

label-name

The entry in the name field of an Assembler or PL/I language statement or the name field of a C language line.

paragraph-name

A COBOL paragraph name in the current module.

CSECT-name

An Assembler CSECT name in the current module. A colon (:) is used to delimit procedure names.

procedure-name

A PL/I procedure name in the current module.

function-name

A C language function name in the current module.

data

A COBOL data-name or data item.

An Assembler data-label or register (Rn).

A PL/I variable.

An IBM C variable-name.

CSR

The cursor. When valid, put the cursor on a data-item, variable, data-label, or register and press an assigned PF key, or type the command on the command line.

literal

Signed or unsigned integer or floating point number, alphanumeric string (' '), hexadecimal string (X' '), or figurative constant (spaces, zeros, high-values, or low-values).

program-name

The name of the module or the subroutine to be tested.

module-name

The name of a module or CSECT. If you are calling a module in the current load module, type the module-name followed by a single colon (:). If the called module is not in the current load module, the module-name must be preceded by the load module name and double colons (::) and followed by a single colon (:). For example:

address

A 24-, 31-, or 64-bit address.

To reference a 64-bit address, you must enter the SET MODE 64 command before entering any 64-bit commands. When typing a 64-bit address, use an underscore character to separate the high-order fullword from the low-order fullword; for example, 00000001_00000100. Code Debug allows you to enter a shortcut instead of all 17 characters of the address. Partial values are right-justified within the fullword and zero-filled to the left.

+ offset

An area in storage relative to the beginning of the area. The plus (+) sign must be followed by a valid hexadecimal number.

address-expression

A symbolic address, +/- calc, or absolute address.

symbolic address

An address expressed by Rn?, Rn%, or Rn! indirect addressing.

conditional-expression

Any valid Code Debug TSO-supported expression that compares the relationship of two items, tests the truth value of a specified condition, or checks when a program variable changes value. Subsequent action of the program is dependent on the result. The following standard operators are valid:

Rn

A general-purpose register, where n is a positive integer.

percent sign (%)

Indirect addressing in 24-bit mode. It is indicated by the general-purpose register number followed by the percent (%) sign; for example, AFTER R10%.

question mark (?)

Indirect addressing in 31-bit mode. It is indicated by the general-purpose register number followed by the question mark (?); for example, AFTER R11?.

exclamation point (!)

Indirect addressing in 64-bit mode. It is indicated by the general-purpose register number followed by the exclamation point (!); for example, MEMORY R11!. To display a 64-bit address, you must enter the SET MODE 64 command before entering any 64-bit commands.

+/- calc

Relative addressing. This feature can be used with any valid hexadecimal offset, register, and the Rn?, Rn%, or Rn! indirect addressing feature; for example, AFTER R12%+3E. To display a 64-bit address, you must enter the SET MODE 64 command before entering any 64-bit commands.

Reading the Syntax Diagrams

Syntax diagrams define primary command syntax.

A parameter is either a keyword or a variable.

All KEYWORDs are shown in uppercase characters and must be spelled exactly as shown. You cannot substitute another value. If any part of a KEYWORD is shown in lowercase characters, that part is optional.

Variables are user-specified values and are printed in lowercase italics. For example, dataset-name indicates you are to substitute a value.

The syntax for commands is described in diagrams that help you visualize parameter use. The following example shows a command and a parameter:

Read the diagrams from left to right and from top to bottom. These symbols help you follow the path of the syntax:

Required parameters appear on the horizontal line (the main path). Optional parameters appear below the main path. Default parameters appear above the main path and are optional. The command executes the same regardless of whether the default parameter is included.

Vertically stacked parameters are mutually exclusive. If you must choose a parameter, one item of the stack appears on the main path. If the parameters are optional, the entire stack appears below the main path. If a parameter in a stack is the default, it appears above the main path.

If the same parameters are used with several commands, their syntax may be documented in a separate diagram. In the command syntax, these common parameters are indicated with separators before and after the parameter name.

An arrow returning to the left indicates a repeatable item. If the arrow contains a comma, separate the repeated items with a comma.

Documentation Availability

Online Documentation

The Code Debug TSO and Code Debug IMS product installation package does not include the product documentation. Access the Code Debug TSO and Code Debug IMS documentation from the BMC Support Center in the following electronic formats:

• Release Notes in HTML format
• Product manuals in PDF format
• Product manuals in HTML format.

The product documentation is available for viewing or downloading:

• View PDF files with the free Adobe Reader, available at http://www.adobe.com.
• View HTML files with any standard web browser.

Information for Customer Solutions

If problems occur, consult your space or the Code Debug TSO and Code Debug IMS technical support representative at your site. If problems persist, please obtain the following information before calling BMC Support. This information helps us to efficiently determine the cause of the problem.

For problems occurring during compile time, request Customer Solutions for BMC AMI Common Shared Services (CSS) and provide the following information:

• Release level of compiler
• List of other vendor products used
• Abend module name
• Any messages in CWPERRM ddname
• Release of CSS.

For problems encountered before bringing up your program (front end problems):

• Sequence of events leading up to the problem
• Release and level of Code Debug product
• Any ISPF error messages, operating system messages, and information provided by the TSO PROFILE WTPMSG.

For run-time abends:

• Release and level of Code Debug product
• Any ISPF error messages, operating system messages, and information provided in the TSO PROFILE WTPMSG
• Information provided in the product session log data set at the time of the abend.

This section provides more information about the following topics: