Using Code Debug IMS effectively
Some information in the following areas can help you run MPP, BMP, and IFP debugging sessions effectively:
- MPP test setup
- Scheduling difficulties
- Interrupting a debugging session
- Fast Path considerations.
MPP test setup
For an MPP debugging session, if a PSB is defined to your IMS system as capable of handling more than one transaction, you must enter the specific transaction code you want to debug.
Scheduling difficulties
There are two Code Debug IMS capabilities that can help if you are unable to schedule a transaction or program:
- The Intercepts display invoked by the INTER command on your test screen
- The session log.
When you cannot schedule a particular transaction, another person may be using it. The transaction a user sets up, either by entering a transaction code (MPP, BMP, or IFP) or through the PSB name (IFP) or program name (MPP), is allocated to that user for the duration of the session. The Intercepts display tells you the transactions that are allocated and the users to whom they are allocated.
Code Debug IMS records in the session log many conditions that prevent a transaction or program from being scheduled. If, after setting intercepts, you still receive the test screen, browse the session log for more information. Code Debug IMS can determine whether a program or transaction is locked or stopped, or not able to be scheduled for other reasons. Code Debug IMS can also capture IMS scheduling abends, which are noted in the session log. Without Code Debug IMS, these conditions can cause your IMS terminal to lock or not respond, requiring master terminal operator intervention to find the cause of the problem.
Stopping the Code Debug IMS dependent region
An Code Debug IMS Dependent Region is categorized as one of the following:
- An MPP region
- A BMP region
- An IFP region.
There are several different ways of stopping an Code Debug IMS Dependent Region. The circumstances depend on whether the dependent region is stopped at an Code Debug breakpoint, the dependent region is in a CPU loop, or the dependent region is waiting for the next input message.
If the region is stopped at an Code Debug breakpoint, you may enter the Code Debug EXIT command to stop the Code Debug IMS dependent region. Before entering the EXIT command, you may roll back any/all uncommitted IMS database updates, Db2 table updates, and system generated messages by issuing the following command:
If the Code Debug TSO terminal session is not available, the region may be stopped by using the Code Debug IMS Detach Region Facility. See to Code Debug IMS Detach Region Facility.
If the region is in a CPU loop, you may use the ATTN key to stop the Code Debug IMS dependent region. You may press the ATTN key once and wait for Code Debug IMS to process the attention interrupt. Attention key processing can be delayed under certain pre-defined conditions. For example, if the ATTN key is pressed while the Code Debug IMS dependent region is executing a DL/I database call or waiting for an input message, attention processing is deferred.
If an MPP or IFP region is waiting for the next input message, the Code Debug IMS dependent region may be stopped by using either the Code Debug Stop Region transaction, trancode XPST, or the Code Debug Stop Region BMP procedure XPSTOP.
To stop the region from an IMS terminal, enter trancode XPST. Transaction XPST displays a formatted screen. On the screen, a field is displayed for entering the Jobname or TSO ID to be stopped. When the screen is displayed, this field will contain your IMS logon id, since many users logon to IMS with their TSO ID. If the installation allows it, you may override the default Jobname shown on the screen with a completely different Jobname of an Code Debug MPP or IFP region. When you press Enter while accessing the formatted screen, the transaction will issue the following IMS Automated Operator Interface command: /STOP REG reg# where reg# is the region identifier associated with the specified Jobname.
To stop the region from a TSO terminal, submit a job which executes your site’s BMP procedure to run the XPSTOP program. The Code Debug jobname or TSO Userid of the region to be cancelled is specified on either the IMS APARM or in the first eight bytes of a control card in a file with DDNAME XPPARM. The APARM technique is usually more convenient; however, releases of IMS prior to IMS 3.1 do not support APARM.
The following JCL examples may be used to invoke a BMP job to stop the TSO Userid TSOUSR1. IMSBATCH is an IBM supplied IMS procedure that is included in the IMS PROCLIB. Your Systems programmer may have created a version of this procedure which is modified for your site. In both cases, the programs executed by XPSTOP must be made available to the region by placing the program code in a library pointed to be the STEPLIB DD statement. This can be done by copying XPSTOP, ADSIM015, and ADSRA093 from the Code Debug TSO LOADLIB to a user library included in STEPLIB or by adding the Code Debug TSO LOADLIB to the STEPLIB concatenation.
The two JCL examples are displayed as follows:
//stepname EXEC IMSBATCH,MBR=XPSTOP,PSB=XPSTOP,IN=XPSTOP,
// APARM=TSOUSR1
//procedurestepname.STEPLIB DD (existing DD statement)
// DD DSN=CPWR.XT.SLXTLOAD
//XPPRINT DD SYSOUT=*
//
or
// Your jobcard
//stepname EXEC IMSBATCH,MBR=XPSTOP,PSB=XPSTOP,IN=XPSTOP
//procedurestepname.STEPLIB DD (existing DD statement)
// DD DSN=CPWR.XT.SLXTLOAD
//XPPRINT DD SYSOUT=*
//XPPARM DD *
TSOUSR1
//
Fast path caution
If your IMS system includes a Fast Path exit routine to route transactions to programs not originally genned to handle these transactions, you can experience the following difficulties:
- The program being executed can receive a transaction you did not enter.
- A transaction you entered can be routed to another program in another region. In this case, no source code displayed. If the other program is active, the transaction is processed or rejected with an appropriate message.