The CA ADS trace facility is a debugging aid used to trace the flow of control and commands executed in an CA ADS application at runtime.
The CA ADS trace facility writes trace records to the DC/UCF system log as DEBUG records. Trace records can be viewed by using online PLOG or the batch print-log utility (PRINT LOG). Use the MESSAGES parameter to print the CA ADS trace records.
Note: The PRINT LOG TRACES parameter will not print the CA ADS trace records. For more information about online PLOG, see the CA IDMS System Tasks and Operator Commands Guide. For more information about the batch print-log utility, see the CA IDMS Utilities Guide.
Information in a Trace Facility Report
The table below describes the information contained in a trace facility report.
|
Field |
Contents |
|---|---|
|
Dialog name |
The name of the currently executing dialog. |
|
Process name |
The name of the currently executing premap or response process. ****** DIALOG-ENTRY ****** in this field documents the beginning of a dialog. |
|
Subroutine name |
The name of the process subroutine currently executing. **MAIN** in this field documents the beginning of a dialog, process, or process command that is not in a subroutine. |
|
Sequence number |
The IDD sequence number of the command currently executing. 00000000 appears in this field at the beginning of a dialog, process, or subroutine. |
|
Process command |
The process command currently executing. ENTRY in this field documents the beginning of a dialog, process, or subroutine. |
|
Command offset |
The hexadecimal offset of the command from the beginning of the dialog's fixed dialog block (FDB). |
|
Included module name |
The name of each included module. |
Format of a Trace Facility Record for a Non-SQL DML Statement
The format of a trace facility record for a non-SQL DML statement is shown below.
┌────────┬┬────────┬┬────────┬┬────────┬┬────────┬┬────────┬┬────────┬┬────────┐ │ ││ ││ ││ ││ ││ ││ ││ │ │ Blank ││ Dialog ││Process ││Sub- ││Sequence││Process ││Command ││Included│ │ ││ Name ││Name ││routine ││Number ││Command ││Offset ││Module │ │ ││ ││ ││Name ││ ││ ││ ││Name │ └────────┴┴────────┴┴────────┴┴────────┴┴────────┴┴────────┴┴────────┴┴────────┘ 0 8 17 50 61 70 79 86 118
Format of a Trace Facility Record for an SQL DML Statement
The trace facility report for an SQL statement follows the format below:
Below this information is the database message passed from the SQLCA.
Note: For more information about the SQLCA, see the CA IDMS SQL Programming Guide.
Initiating the Trace Facility
You can initiate the trace facility in one of these ways:
Specifying TRACE when initiating CA ADS results in tracing the execution of all dialogs in the application that have been compiled with a symbol table. You use TRACE and TRACE OFF in process logic to limit the trace.
The System Log
Using the CA ADS trace facility can fill the DC/UCF system log quickly. Information on the entire application is collected for each process command in dialogs that have a symbol table enabled and TRACE=ALL specified. A record is written to the system log for each command.
To avoid overloading the system log, the system log can be defined to sequential log files instead of the DDLDCLOG area. Assigning the system log to sequential log files facilitates offloading the system log when it becomes full.
Note: For more information about log files, see the CA IDMS System Generation Guide.
What You Can Do
The online debugger enables the application developer to interrupt execution of a dialog's premap or response process, display and change the contents of data fields, and restart execution from any point in the interrupted dialog. If a dialog aborts during a debugger session, the application developer can review the contents of the data fields at the time of the abend, change the contents of the data fields, and resume dialog execution at any point. For example, a breakpoint can be set at line 200 in a premap process and can specify that an interruption is to occur every second time the process command is executed at runtime.
If CA ADS encounters a potential breakpoint at runtime, it passes control to the online debugger. If the conditions for interrupting the dialog are not met, control returns to the runtime system and execution continues. If the conditions are met, the online debugger keeps control and allows the application developer to perform functions such as reviewing and modifying data fields, modifying breakpoint specifications, aborting dialog execution, and resuming execution at a specified point.
If a dialog aborts during a debugger session, the CA ADS runtime system displays a special version of the Dialog Abort Information screen and then links to the online debugger.
The special screen version allows the application developer to continue the debugging session for the dialog. The application developer can enter debugger commands at the prompt that appears on the screen.
Procedures
Procedures for debugging an CA ADS dialog are the same as those used with any other program running under DC/UCF: once the dialog is defined to the debugger with the DEBUG command, debugging procedures can take place. It is easier, however, to find dialog records or to find the command elements (CMEs) for breakpoints when the load module is generated in interpretable code and symbol recognition is in effect.
Note: For more information about debugging, see the CA IDMS Online Debugger Guide.
Recommended Steps
It is recommended that you take the following steps when debugging an CA ADS dialog:
Run ADSORPTS for the Dialog
Run the CA ADS Dialog Report (ADSORPTS) for the given dialog. Specify the PROCESS and/or FDBLIST options when submitting the report: PROCESS displays the sequence line numbers that are assigned to the process source; FDBLIST provides the line numbers (SEQ#) and the offsets of the CMEs. The address or line number of a CME can then be used to set a valid breakpoint within the premap or response process.
Issue the DEBUG Task Code
Issue the DEBUG task code to invoke the debugger.
Note: For more information on initiating a debugger session, see the CA IDMS Online Debugger Guide.
Define the Dialog to the Debugger
Define the dialog to the debugger by issuing a command similar to the one in the following example:
DEBUG> debug dialog medduins
The debugger responds to the above command with the following message:
DEBUG DIALOG MEDDUINS DEBUG> DEBUGGING INITIATED FOR MEDDUINS VERSION 1 DEBUG>
If you omit the word dialog, the debugger issues an error message:
DEBUG>
debug medduins
DEBUG MEDDUINS
DEBUG> INCONSISTENT ENTITY TYPE
- MEDDUINS VERSION 1 DEFINED AS A DIALOG
DEBUG>
This message indicates that the debugger has tried to process MEDDUINS as a program but can only find a PDE (program descriptor element) that defines MEDDUINS as a dialog. The command needs to be modified to state that MEDDUINS is a dialog:
DEBUG> debug dialog medduins
Set Breakpoints
Set breakpoints as required. Breakpoints must be set at line numbers or addresses that contain valid command instructions (valid CMEs).
Note: For more information about setting breakpoints, see the CA IDMS Online Debugger Guide.
Issue EXIT
Issue the EXIT command and leave the debugger.
Invoke the CA ADS Runtime System
Invoke the CA ADS runtime system and execute the dialog in the standard manner.
When a breakpoint is encountered during the execution of the dialog, a message appears on the screen that identifies the breakpoint. The DEBUG> prompt or menu mode screen is displayed, signalling that you are now in the runtime phase of the debugger and can enter any of the debugger commands except DEBUG.
Note: For more information on command syntax, see the CA IDMS Online Debugger Guide.
Continue Processing the Dialog
Continue processing the dialog. When the single command RESUME is issued without any qualifying parameters, processing continues from the current CME (the instruction immediately following the breakpoint). When a RESUME debug-expression is issued, processing resumes at the address specified by the expression.
When you issue a RESUME dialog-expression command from a point within the main body of the dialog process, the debug expression must resolve to an address also within the main body of the dialog. Similarly, when a RESUME dialog-expression is issued from a subroutine, the debug expression must resolve to an address within the same subroutine. Results are unpredictable when execution is not resumed in accordance with these rules.
In the Event of an Abend
In the event of an abend, you see the CA ADS Debug screen with dialog abort information, the DEBUG> prompt, and the menu mode selection area. Any valid debugger command can be entered on the prompt line or can be selected from the menu. When a selection is made from the menu, the debugger automatically operates in menu mode and displays the specified screen. A sample Debug screen is shown below. Note the DEBUG> prompt and menu selection area located at the bottom of the screen. All commands, except DEBUG, can be issued in response to the prompt or can be selected in the menu area:
CA-ADS RELEASE nn.n *** DIALOG ABORT INFORMATION *** DBUG DC175020 APPLICATION ABORTED. PGM CHECK (DATA EXCEPTION). DATE....: 91.220 TIME....: 17:10:23.55 TERMINAL....: LV81001 ERROR OCCURRED IN DIALOG......: MISINCD AT OFFSET......: 3D8 IN PROCESS.....: MIS-MAIN1 VERSION: 1 AT IDD SEQ NO. : 000000100 INTERNAL COMMAND: 2 INCLUDED MODULE : MIS-INC1 VERSION: 1 SEQUENCE NUMBER: SOURCE : 00000000 00000100 ADD 1 TO MIS-NUM. 00000200 ! THIS IS MIS-INC1 DEBUG> NEXT _ ACTIVITY OR _ HELP: _ AT _ LIST _ SET _ SNAP _ RESUME _ DEBUG _ WHERE _ EXIT _ PROMPT _ QUIT _ IOUSER HELP SCREENS: _ USAGE _ SYMBOLS _ KEYS
Issue the RESUME ABEND or a RESUME debug-expression command to continue processing the dialog.
QUIT or EXIT
Issue the QUIT or EXIT command when debugging is completed. QUIT clears the debugger control blocks and ends the debugger session; EXIT returns you to the ENTER NEXT TASK CODE prompt. but leaves the control blocks intact so that the debugger session can continue.
|
Copyright © 2014 CA.
All rights reserved.
|
|