InterTest™ and SymDump ® 11.0
To set or remove replacement options, access the appropriate Monitoring subenu to which the monitoring option applies:
Option Used For Monitoring
2.1 Programs
2.2 Transactions
2.3 Terminals
Set Replacement Options
On the Monitoring submenu, enter the program names, transaction codes, or terminal names and the user ID option for
whom the entry will be monitored. Then select the Replace  option using S, and press Enter. The Replacement Options
screen appears.
Specify the following options. The equivalent option used in CNTL transaction-based commands is specified in
parentheses.
Replace program name (RPC)
Lets a program name be replaced. Specify the original program name and the new name.
Replace file name (RFC)
Lets a file name be replaced. Specify the original file name and the new name. The sample screen shown previously
specifies that program COBDEMO use file TFILE instead of PFILE.
Replace TD queue name (RTD) Lets a transient data queue name be replaced. Specify the original TD queue name and
the new name.
TS selection mask; TS replacement mask (RTS) Lets a temporary storage ID be replaced. Specify the original
temporary storage ID in the TS selection mask field and the new temporary storage ID in the TS replacement mask field.
Specify both masks as eight bytes in either character (Cdata) or hexadecimal (Xdata) format.
Example
STORAGE2 replaces STORAGE1 in all temporary storage requests issued by the program.
 TS selection mask:   C'STORAGE1'
 TS replacement mask: C'STORAGE2'

Limit monitoring (TON)
Specifies that the program be monitored and that replacement options, if specified, take effect only when the
program executes at the current terminal (*), a specific terminal (termid), or without a terminal (.NO).


User ID (or .ANY) who will execute the program
Specifies that the program be monitored and that replacement options, if specified, take effect only when the
program is executed by any user (.ANY) or a specific user (a CICS user ID).
When you have specified the required information, press Enter. You are returned to the monitoring submenu where you
selected the Replace option.
Remove Replacement Options
This section describes how to remove replacement options from a status report or from the menu.
From a Status Report
To remove a replacement option, access the Monitoring Status display (2.4), scroll to the monitoring entry for which you
specified the option, and locate the specific replacement option. Type r next to the option and press Enter.
 1062


InterTest™ and SymDump ® 11.0
From the Menus
Alternatively, use the same menus and screens you used to set the option, but instead of entering s next to Replace, enter
r next to Replace. Specify the information exactly as you entered it.
To remove all replacement options of a specific type, use the menus and enter .ALL  in the appropriate field on the
Remove Replacement Options screen. This example removes all file replacement options previously set for the
transaction DEMC.
Protection Options
Set options to override the InterTest for CICS default protection rules for modifying main storage, the CSA, and load
modules. Remove the protection options to re-instate the default protection rules.
NOTE
Because the protection options can potentially damage your CICS system if misused, exercise caution in
specifying them. These options are password protected unless your site removed this restriction.
To set or remove protection options, access the appropriate Monitoring submenu to which the monitoring option applies:
Option Used For Monitoring
2.1 Programs
2.2 Transactions
2.3 Terminals
Set Protection Options
On the Monitoring submenu, enter the program names, transaction codes, or terminal names and the user ID option
for whom the entry will be monitored. Then select the Replace  option using s, and press Enter. The Protection Options
screen displays.
Specify the following options on the previous screen. In the description of each option, the command syntax equivalent for
each monitoring option is specified in parentheses.
Bypass storage protection (BYP)
Permits a specified section of program code to do the following:
•Modify any area of main storage
•Issue SVC instructions
•Issue BALR, BASSM, or BASR 14,15 or 14,14 instructions
Specify the beginning and ending program addresses or program offsets. Specify addresses as six- to eight-hexadecimal


digits, and offsets as one- to five-hexadecimal digits.
If you specify .ANY in the From field and an address or offset in the To field, InterTest for CICS suspends monitoring when
any BALR, BASSM, or BASR 14,15 or 14,14 instruction passes control to the specified location. Monitoring resumes when
the routine executed by the instruction returns control to the next byte after the instruction.
At a breakpoint, specify * in the From field and leave the To field blank to instruct InterTest for CICS to bypass the current
instruction.
Unprotect CSA (CSA)
Permits a program to modify areas in the CSA. Specify the offset and the length in hexadecimal.
Unprotect CWA (CWA)
Permits a program to modify areas in the CWA. Specify the offset and the length in hexadecimal.
 1063


InterTest™ and SymDump ® 11.0
Unprotect main storage area (LET)
Permits a program to modify a designated area of storage. Specify the beginning address as six to eight
hexadecimal digits. Specify the length of the area in hexadecimal.
Unprotect load module (LET)
Permits a program to modify a load module.
Protect main storage area (PRO)
Prevents a program from modifying a designated area of storage not protected by InterTest for CICS. Specify the
beginning address as six- to eight-hexadecimal digits. Specify the length of the area in hexadecimal.
Limit monitoring (TON)
Specifies that the program be monitored and that the protection options, if specified, take effect only when the
program executes at the current terminal (*), a specific terminal (termid), or without a terminal (.NO).
User ID (or .ANY) who will execute the program (USR)
Specifies that the program be monitored and that protection options, if specified, take effect only when the
program is executed by any user (.ANY), or a specific user (a CICS user ID).
Once you have specified the required information, press Enter. You return to the monitoring submenu where you selected
the Protect option.
Remove Protection Options
This section describes how to remove protection options from a status report or from the menu.
From a Status Report
To remove a protection option, access the Monitoring Status display (2.4), scroll to the monitoring entry for which you
specified the option, and locate the specific protection option. Type r next to the option and press Enter .
From the Menus
Alternatively, to remove protection options, access the Monitoring submenu, specify monitoring entry, (program,
transaction, or terminal and user ID), type R next to the Replace option and press Enter. Then enter the information
exactly as you originally defined it.


exactly as you originally defined it.
To remove all options of a specific type, enter  .ALL  in the appropriate field of the Protection Options menu.
Example
To remove all Bypass Storage Protection options, enter .ALL  in the first Bypass Storage Protection field.
Special Options
Set special options to alter the standard InterTest for CICS monitoring procedures. Remove the special options to
reinstate the default monitoring rules.
To set or remove protection options, access the appropriate Monitoring submenu to which the monitoring option applies:
Option Used For Monitoring
2.1 Programs
2.2 Transactions
2.3 Terminals
 1064


InterTest™ and SymDump ® 11.0
Set Special Options
On the Monitoring submenu, enter the program names, transaction codes, or terminal names and the user ID for whom
the entry will be monitored. Then select the Special option using S, and press Enter. The Special Options screen opens.
You can specify many options on this screen. The equivalent option used in CNTL transaction-based commands is
specified in parentheses.
Source Listing Breakpoint (SLB)
Specifies that the Source Listing Breakpoint screen be displayed rather than the detailed breakpoint display
screen.
No file updating (NUP)
Specifies that a monitored program not update any files. This option only affects VSAM and BDAM files;
databases are unaffected.
Reentrancy check (RNT)
Prevents a program from modifying its own code.
Follow monitoring (FOL)
Instructs InterTest for CICS to continue monitoring a program even if it branches directly to another program (wild
branch). All monitoring options remain in effect. Specify the following:
•ON when control passes to a program that does not have a PPT entry
•The name of the program when control passes to a program that has a PPT entry
•NOPPT instead of ON to reduce overhead when a program often branches to a program that does not have a
PPT entry
Note: The FOL option should not be specified if control is passed to a program by a LINK or XCTL instruction.
Such a program is monitored only if monitoring was specified for it.
Number of times to be monitored (MUS)
Limits the number of times a program should be monitored.
Limit total size of CICS storage (MXS)
Limits the amount of storage, including program storage, a program acquires.
Limit total number of CICS requests (MXR)


Limit total number of CICS requests (MXR)
Limits the number of requests a transaction issues. This option is useful when a program is in a loop that includes
a CICS request.
Setting for Structure Display Format (SDF)
Use this option to override, by program, the global default setting. Specify the following:
HEX
Display data in hexadecimal / character format.
DATA
Display data in Structure Display Format
Set local automatic breakpoint (ABP)
Activates the automatic breakpoint facility for a particular program, transaction, or terminal.
Specify the terminal to receive automatic breakpoint displays. An asterisk, *, routes the display to the current
terminal. A termid routes the display to a particular terminal. .ANY routes the display to all terminals. OFF  instructs
InterTest for CICS to abend the task instead of halting it at an automatic breakpoint.
Note:  This option is useful when you do not want the breakpoint display routed to the terminal where the program
is running or when the display cannot  be routed to that terminal (for example, a non-terminal task or a task
running on a non-3270 terminal). In those cases, specify the terminal to which breakpoint displays should
be routed. The local automatic breakpoint option is also useful in a production environment when the global
Automatic Breakpoint facility is disabled and you want to monitor a specific program, transaction, or terminal.
 1065


InterTest™ and SymDump ® 11.0
Limit monitoring (TON)
Specifies that the program be monitored and that the special options, if specified, take effect only when the
program executes at the current terminal (*), at a specific terminal (termid), or without a terminal (.NO).
User ID (or .ANY) who will execute the program (USR)
Specifies that the program be monitored and that special options, if specified, take effect only when the program
is executed by any user (.ANY) or a specific user (a CICS user ID).
Once you have specified the required information, press Enter . You are returned to the monitoring submenu where you
selected the Protect option.
Remove Special Options
This section describes how to remove special options from a status report or from the menu.
From a Status Report
To remove a special option, access the Monitoring Status display (2.4), scroll to the monitoring entry for which you
specified the option, and locate the specific special option. Type R next to the option and press Enter.
From the Menus
To remove special options, access the same monitoring menu and specify R next to Special, complete the Special
Options menu by enter an x next to the options you want to remove, or enter the information exactly as you originally
defined it.
Disconnect, Reconnect, and Purge Active Tasks
This section describes how to disconnect or reconnect a terminal to InterTest for CICS.
Disconnect a Task
To disconnect a terminal from InterTest for CICS while at a breakpoint, use Breakpoint Primary Menu Option 7 Disconnect.
This option lets non- InterTest for CICS or non-CICS functions be performed at the terminal.
Reconnect a Task
To reconnect a terminal to the InterTest for CICS breakpoint, use the ITST Monitoring Menu to reconnect a task.


Monitoring Menu Option 5 Active-Tasks, lets you reconnect, disconnect, and purge active tasks. From CICS, enter ITST
2.5 and the Active Tasks menu displays.
Type an R next to a task you want to reconnect to your terminal, or type a P next to a task you want to purge.
NOTE
For more information, see Special Considerations for MRO Support for reconnection considerations for tested
transactions in implicit routing sessions in MRO environments.
View and Set System-Wide Options
Set certain options on a system-wide basis from the Monitoring System-Wide Options submenu (2.6).
NOTE
These options are password protected unless your site has removed this restriction.
There are six options to select from on this screen. The equivalent option used in single-line commands is specified in
parentheses. Type S next to the option to select it, and then complete the following screen. In many cases, you enter ON
to set an option and OFF to remove it.
 1066


InterTest™ and SymDump ® 11.0
ABP Option: Automatic breakpointing  sets the Automatic Breakpoint Facility for the entire system. Default. Breakpoint
displays are routed to the terminal where the program is running. Specify a terminal ID to indicate where breakpoint
displays should be routed for non-terminal attached tasks and for tasks executing from non-3270 terminals.
If you specify OFF for the ABP option, you might want to use the Special Options from the Program Monitoring submenu
(2.1) to set the local Automatic Breakpoint option for one or more programs. The local Automatic Breakpoint option
overrides the system Automatic Breakpoint option.
CKPT Option: Option Checkpointing  instructs the Checkpoint Recording Facility to periodically record the status of
InterTest for CICS monitoring so that you can use the restart feature. The first checkpoint occurs when the option is
specified. Subsequent checkpoints occur at the end of the interval, specified in hours and minutes in hhmm format. The
minimal time interval is ten minutes.
ITTRACE Option: InterTest for CICS  tracing instructs InterTest for CICS to write trace records to the CICS trace during
monitoring.
Purge breakpointed tasks (PURGE)  instructs InterTest for CICS to periodically purge tasks halted at a breakpoint for
longer than the specified interval. The first purge occurs when the option is specified. Subsequent purges occur at the end
of the interval, specified in hours and minutes in this format hhmm . The minimal time interval is 20 minutes.
Work With Recorded Debug Sessions
Use option 7 of the InterTest for CICS MONITORING MENU (ITST 2.7) to display monitor logging records of debug
sessions that were previously recorded.
The index record for each recorded debug session is displayed. You can sort and filter records using the command areas


above each column header. Use the command area to the left of each record to browse, cancel, delete, load, or stop the
recording session. If a debug session is currently active, the menu display shows the date as "*ACTIVE" and the time as
"------".
You can use the following line commands in the action field:
B
Browse the command file member
D
Delete the command file member, if it is not active
L
Load the command file member into the current debug session
S
Stop the active debug session
C
Cancel the active debug session
                   CA InterTest for CICS SAVED DEBUG SESSIONS          U11IC9N4
 COMMAND ===>

   Type B to browse session   L to load session    D to delete session
        S to stop session     C to cancel session
                                                                       More:   +
   *        *        *        *       *      *
   Session  Userid   Applid   Date    Time   Description
 _ .ANYTEST CICSUSER U11IC9N4 2016260 101947
 _ ACTVLOAD CICSUSER U11IC9N4 2016288 160607
 _ APPLID   CICSUSER U11IC9N4 2016245 144837 DESCRIPTION USERID TIME DATE SESSIO
 _ BIGDEMO  CICSUSER U11IC9N4 2016218 113302 EVEN BIGGER SESSION
 _ BIGSESS  CICSUSER U11IC9N4 2016204 102613 TEST LARGE NUMBER OF RECORDS
 1067


InterTest™ and SymDump ® 11.0
 _ BROWETST CICSUSER U11IC9N4 2016239 150803
 _ COBDEMO  CICSUSER U11IC9N4 2016218 105545
 _ DATANEW  CICSUSER U11IC9N4 2016274 082857 ANOTHER DATAPGM SESSION TEST
 _ DATAPGM  CICSUSER U11IC9N4 2016195 152741
 _ LOADACTV CICSUSER U11IC9N4 2016288 143051
 _ MSGTEST  CICSUSER U11IC9N4 2016302 115332 TEST MISSING MESSAGE
 _ OTHERACT CICSUSER U11IC9N4 2016288 143421

 PF1 Help       2 Refresh    3 End        4 Return     5            6 RFind
 PF7 Backward   8 Forward    9           10           11           12
Filter
Lets you to specify criteria to filter the subprograms that are displayed on the Composite Support screen.
SORT
Use the SORT command on the Debug Sessions screen to sort sessions by the values in a specific column in an
ascending or descending order. The command has the following format:
SORT [ columnname ] [ order | A | D ]
columnname
(Optional)
Specifies the name of the column that you use as the restrictive criteria for sorting. Values: Session, Userid,
Applid, Date, Time, Default: Session
order
(Optional)
Specifies the order that you use for sorting. Values: ASCENDING, DESCENDING Default: ASCENDING
Example:
The following command sorts sessiosn by the Session column in a descending order:
SORT Session D
Special Monitoring Situations
Special Monitoring Situations


SORT Session D
Special Monitoring Situations
Special Monitoring Situations
This article describes the following special monitoring situations:
•Monitoring programs with LE/370 condition handlers
•Monitoring dynamically called COBOL II and COBOL/370 programs
•Production environment monitoring
•Monitoring tasks that execute without terminals
•Monitoring tasks that execute at non-3270 terminals
•Use segmented monitoring to handle special situations
•Use programmed breakpoints
•CICS/ESA 3.3 FEPI applications monitoring
Segmented monitoring applies to users of HOGAN Systems software and the MSA Corporation's DCI Interface.
Programmed breakpoints are used primarily by PL/I users who want to display data areas that InterTest for CICS normally
cannot display or who do not have symbolic information for their programs.
 1068


InterTest™ and SymDump ® 11.0
Monitor Programs with LE/370 Condition Handlers
LE/370 condition handlers do not receive control in the same manner as a normal CICS COBOL program. Therefore, they
must be monitored using the InterTest Segmented Monitoring and ABI=OFF options.
To monitor COBOL/370 programs containing calls to enable or disable LE/370 condition handlers, perform these steps:
1.Use normal monitoring.
2.Specify ABI=OFF for the main program, and if there is a composite module, for all subprograms.
NOTE
Do not specify ABI=OFF for the LE/370 condition handler module if you want InterTest for CICS to intercept
abends that occur within the LE/370 condition handler. ABI=OFF is needed for all programs except the
condition handler to prevent  InterTest for CICS from intercepting the abend before  the LE/370 condition
handler is invoked.
Because LE/370 condition handlers do not receive control the same way a normal CICS program does, you must start
and stop monitoring for the condition handler routine or program by using the Segmented Monitoring breakpoint options
(+ and -). For example, use the Source Listing facility to display the condition handler routine or program, and then set a
start monitoring (+) breakpoint at the first statement number, which causes InterTest for CICS to begin monitoring when
the condition handler is invoked by LE/370. Set normal breakpoints, such as unconditional, conditional and so on, in the
condition handler program. For more information on segmented monitoring, see Segmented Monitoring to Handle Special
Situations.
You must set a stop monitoring breakpoint (-) before or at the GOBACK statement of the condition handler or
unpredictable results might occur.
Monitor Dynamically Called COBOL Programs
The monitoring and debugging of dynamically called COBOL programs is handled as follows:


The monitoring and debugging of dynamically called COBOL programs is handled as follows:
•In the same way as other CICS COBOL programs without necessarily monitoring higher level programs
•Using the FOL=PPT option
Request monitoring for dynamically called COBOL programs through the Source Listing and CNTL facilities the same way
you request monitoring for first level CICS COBOL programs.
Production Environment Monitoring
At times, use InterTest for CICS to monitor programs running in a production environment.
Example
You might want to monitor recently installed or modified applications until you are sure they are free of errors, or even
monitor the entire production system if you have errors that cannot otherwise be isolated.
When you use InterTest for CICS in a production environment, you should consider the following items:
•Where to route automatic breakpoint displays
•How many times to monitor a program
•Whether to restrict monitoring to a single terminal or user ID
•What to do if you must monitor the entire system
Control Automatic Breakpoint Displays
When you monitor a program in a production environment, you usually do not want the breakpoint display to appear at the
operator's terminal because the information is meaningless. Instead, InterTest for CICS either abends the task or routes
the Breakpoint Display.
 1069


InterTest™ and SymDump ® 11.0
Abend the Task
If you want InterTest to abend the task before it damages CICS and writes a transaction dump (INTE), deactivate the
global automatic breakpoint facility. This facility instructs InterTest for CICS to generate a breakpoint each time it detects
an error in a program that it is monitoring.
To deactivate this facility, select System-Wide Options from the Monitoring Menu (Primary Menu Option 2.6), and enter
OFF in the Automatic Breakpoint field, or enter the command:
 CNTL=ABP,OFF

When the global automatic breakpoint facility is deactivated, you might want to specify the local automatic breakpoint
option for certain programs, transactions, or terminals.
Route the Breakpoint Display
To route breakpoint displays to a programmer's terminal, specify the local automatic breakpoint option and direct the
breakpoint displays to a programmer's terminal. The local automatic breakpoint option instructs InterTest for CICS to
generate a breakpoint each time it detects an error in the specified program, transaction, or terminal, and it overrides the
global automatic breakpoint facility.
To specify this option, select Special Options from the Monitoring submenus (2.1, 2.2, or 2.3) and specify the programs,
transactions, or terminals. Then specify the terminal to which breakpoint displays should be routed. You could also enter
the command:
 CNTL=ON,promid,ABP=termid

Control the Number of Times a Program Is Monitored
When a new or modified program goes into production, limit the number of times InterTest for CICS monitors it. The
MUS option lets you specify the number of times InterTest for CICS should monitor a program. To specify the MUS


option, select Special Options from the Monitoring submenus (2.1, 2.2, or 2.3) and specify the programs, transactions, or
terminals. On the Special Options menu, specify the number of times monitoring should occur in the MUS field. You can
also enter this command:
 CNTL=ON,promid,MUS=nnn

Monitor a Program for a Single User ID
When a program fails in the production system, use InterTest to monitor it so you can find and correct the error. In a
secure CICS region, restricting monitoring to a single user ID means you test the program thoroughly without  interfering
with the work of other users.
All monitoring methods let you specify a single CICS user ID when setting monitoring. This limits monitoring to only that
user, but permits the user to go to any terminal. Monitoring by user ID can be the default in your system. If it is not, you
must specify the user ID each time you set monitoring or a monitoring option. If you are using the Source Listing facility
or the menus to set monitoring, press PF1 to get help on how to monitor by user ID. If you are using CNTL commands,
specify the USR option when you set monitoring, as follows:
 CNTL=ON,promid,USR=userid

 1070


InterTest™ and SymDump ® 11.0
Monitor a Program at a Single Terminal
When a program fails in the production system, use InterTest for CICS to monitor it to find and correct the error.
Restricting monitoring to a single terminal means you test the program thoroughly without  interfering with the work of other
users.
If you are using the CNTL Monitoring Command Builder menus, limit monitoring to a single terminal on the Replacement
Options, Protection Options, and Special Options screens. If you are using commands, specify the TON option when you
set monitoring, as follows:
 CNTL=ON,promid,TON=termid

Monitor the Entire Production System
You usually want to avoid monitoring the entire production system because of the high overhead involved. But what if your
production system has a serious error and you cannot isolate the problem program? In that case, instruct InterTest for
CICS to monitor all the programs in the production system for every user or for a specific user only.
If your system is experiencing sporadic problems that are difficult to isolate, you might want to monitor all programs
executed by the user experiencing the problems. In a secure CICS region, use the following global monitoring command
with the user ID option for the user experiencing the problem:
 CNTL=ON,PROG=.ALL,USR=cics-userid

NOTE
Ensure that each user signs on to CICS before executing programs.
While InterTest is monitoring all of the programs, use the Active Tasks display (Primary Menu Option 2.5 Monitoring
Active Tasks) to check for problems. When InterTest for CICS finds that a program is about to commit an error, it halts the
program at an automatic breakpoint and automatically creates a Monitoring Table entry for that program. The monitoring


program at an automatic breakpoint and automatically creates a Monitoring Table entry for that program. The monitoring
status report provides that information. As soon as you see that InterTest for CICS has identified the problem program,
turn monitoring off for the system and monitor the problem program for a single user or at a single terminal until you
resolve the error.
Alternatively, monitor a certain percentage of your programs until InterTest for CICS finds the problem program.
Example
You might monitor 10 percent of your programs one week, another 10 percent the next week, and a third 10 percent the
following week.
This approach minimizes overhead, and takes advantage of the ability of InterTest for CICS to track down problems that
are otherwise very difficult to resolve.
Monitor Tasks That Execute Without Terminals
Special steps must be taken when InterTest for CICS monitors tasks that execute without a terminal. This includes tasks
that are automatically initiated by an interval control request or a transient data trigger.
Unconditional, Conditional, and Request Breakpoints
If you set unconditional, conditional, and request breakpoints and you want to see the breakpoint display, you must
indicate that the task is running without a terminal. Specify the terminal to receive breakpoint displays.
If you specify .ANY  for the terminal at which the task must be executing, the breakpoint occurs at all terminals -- even
when the task runs without a terminal. If you specify .NO, the breakpoint occurs only when the task executes without a
terminal.
 1071


InterTest™ and SymDump ® 11.0
Specify the ID of the terminal to receive breakpoint displays. If omitted, it defaults to the terminal at which the breakpoint
was set. Do not specify .ANY for the terminal to receive breakpoint displays.
NOTE
If you set a breakpoint, the local automatic breakpoint option is automatically set for the program.
Automatic Breakpoints
If the global automatic breakpoint facility is on and a program is executing without a terminal, the task abends. To prevent
this, route automatic breakpoint displays to 3270-type terminals. Use the global or local automatic breakpoint terminal
options to identify the terminal to receive automatic breakpoint displays.
To identify a terminal to receive breakpoint displays for a specific program or transaction, select Special Options on the
Monitoring Submenu for the Program (2.1) or Transaction (2.2). Specify a terminal ID for the local automatic breakpoint
option on the Special Options menu. For more information, see Monitoring Menu Options.
To identify a terminal to receive breakpoint displays for all non-terminal attached tasks and for tasks executing from
non-3270 terminals, select System-Wide Options from the Monitoring Menu (Primary Menu Option 2.6, Breakpoint Menu
Option 1.2.6). On the System-Wide menu, specify a terminal ID for the global automatic breakpoint option.
Set Monitoring for Non-Terminal Execution
Monitor a task only when it executes without a terminal. Specify this by selecting Replacement Options, Protection
Options, or Special Options from Monitoring submenus (2.1, 2.2, or 2.3). Specify .NO in the Limit Monitoring field. You can
also enter the following command:
 CNTL=ON,promid,TON=.NO

Monitor Tasks That Execute at Non-3270 Terminals
Monitoring commands for tasks executing at non-3270 terminals must be entered at 3270-type terminals.


Set Monitoring for Non-Terminal Execution
Monitor a task only when it executes without a terminal. Specify this by selecting Replacement Options, Protection
Options, or Special Options from the Monitoring submenus, and then specify .NO in the Limit Monitoring field. For more
information, see Monitoring Menu Options. You can also enter this command:
 CNTL=ON,promid,TON=.NO

Automatic Breakpoints
When a task is running on a non-3270 terminal, route automatic breakpoint displays to a 3270-type terminal. Use the
global or local automatic breakpoint terminal options, described previously in MonitorTasksThatExecuteWithoutTerminals,
to identify the terminal to receive automatic breakpoint displays.
Unconditional, Conditional, and Request Breakpoints
If you set unconditional, conditional, and request breakpoints and you want to get the breakpoint display, you must
specify .ANY or a terminal ID for the terminal at which the task must be executing for breakpoints to take effect.
Route breakpoint displays to a specific terminal. To change the terminal ID: use the Source Listing Profile, and change the
setting prior to setting any breakpoints.To see your current terminal's ID, enter TERM  on the command line of any Source
Listing or Breakpoint display.
 1072


InterTest™ and SymDump ® 11.0
If InterTest for CICS was installed with the DFLTUSER value in IN25OPTS set to SPECIFIC, Terminal ID =.ANY is the
default terminal setting. When the DFLTUSER option is set to .ANY, the default terminal ID is the terminal used to set the
breakpoint. To view your IN25OPTS settings, use Primary Menu Option 7.12.
Segmented Monitoring to Handle Special Situations
Users of the following might require segmented monitoring:
•HOGAN Systems
•DCI Interface of the MSA Corporation
•LE/370 condition handlers
•Some composite programs
InterTest for CICS normally controls whole application programs. Segmented monitoring provides a way for InterTest for
CICS to control only small portions (code segments) of application programs.
Use segmented monitoring sparingly for special debugging needs, such as when only certain pieces of code should be
monitored because of excessive overhead or because they get control directly from programs (or interfaces) that must not
be monitored by InterTest for CICS.
WARNING
Improper use of segmented monitoring options could damage your CICS system because InterTest for CICS
places invalid machine instructions in application programs at the segmented monitoring locations specified by
the user. Before you use segmented monitoring, see Notes and Warnings .
Segmented Monitoring Situations
The monitoring problems that follow are solved with segmented monitoring.
HOGAN Systems Users
Problem:
InterTest for CICS must not monitor most of the HOGAN Systems code. However, you need to monitor and test
the application code that you wrote. This code does not receive control from CICS in the usual way.
Solution:
Place a MON option to start InterTest for CICS monitoring at the beginning of your application program's


Place a MON option to start InterTest for CICS monitoring at the beginning of your application program's
Procedure Division. Monitoring begins at the MON location and continues until an activity #1 PEM call is
encountered. The InterTest for CICS IN25UEX routine for HOGAN applications detects this call and stops the
monitoring. Set breakpoints within this segment of code. When you execute the transaction, InterTest for CICS
monitors the specified code segment.
You must also set the InterTest for CICS option USH=ON to prevent automatic breakpoints from being triggered
when your HOGAN Application program references CICS shared-storage areas.
MSA Programs with Special Interfaces
Problem:
The application programs that hook into large packages such as MSA do not receive control directly from
CICS, and thus cannot be monitored independently from the MSA packages using standard InterTest for CICS
monitoring. Monitoring the entire load module incurs too much overhead and often results in numerous abends
because of non-standard CICS programming practices (such as passing control using direct branches).
Solution:
Monitor only the application program that you wrote by setting a MON option near the beginning of the program
and a NOM at the end of the program. Set breakpoints within this segment of code. When you execute the
transaction, InterTest for CICS monitors only the specified code segment.
 1073


InterTest™ and SymDump ® 11.0
NOTE
For MSA programs set the MON after the secondary entry point.
The Segmented Monitoring Options Monitor (MON) and No Monitor (NOM)
Segmented monitoring consists of two independent monitoring options:
•MON, an option to turn monitoring on
•NOM, an option to turn monitoring off (No Monitor)
Monitor On Option (MON)
MON turns InterTest for CICS monitoring on beginning with the machine instruction of the specified location (regardless of
how this piece of application program got control). If InterTest for CICS monitoring was already on, monitoring continues.
After a MON entry, monitoring continues unless InterTest for CICS encounters one of the following:
•A NOM entry
•An XCTL
•A RETURN
No Monitor Option (NOM)
NOM stops InterTest for CICS monitoring at the specified location and gives control to the machine instruction on which
the NOM option was specified.  If the code was not already being monitored, it continues unmonitored. After a NOM
entry, the program continues unmonitored unless InterTest for CICS encounters a MON entry or a LINK/XCTL to another
program already being monitored.
Specify these options in your program at the same type of locations you use to set individual breakpoints, such as at
COBOL paragraph names or statement numbers. Each option takes effect as it is encountered during program execution.
Each MON and NOM option is an independent   request to start or stop InterTest for CICS monitoring, regardless of the
current monitoring status.
NOTE
The MON and NOM options are not CICS user ID or terminal sensitive. An option set from one terminal applies
when the program executes from any terminal by any CICS user.
When using MON and NOM, specify breakpoints and other options in your program. If you set a MON or NOM option at


the same location   as a breakpoint or other option, the MON or NOM option executes first. This means the MON option
starts monitoring and hits the breakpoint, but since NOM drops monitoring before the breakpoint is encountered, you
never receive the breakpoint that is set where a NOM is also set.
Installation Requirements and Password Protection
The segmented monitoring option must be enabled as part of the installation and customization procedure. Enable it with
or without CNTL menu support, and with or without password protection.
To check the status of the segmented monitoring option on your system, select Primary Menu Option 7 Status/
Maintenance, and then Option  1.2 Global Options. The current IN25OPTS values are displayed alphabetically. Look for
the option MONOM.
The following are MONOM values:
MENU
Segmented monitoring is enabled for all methods: Source Listing, CNTL menus, and CNTL commands.
NOMENU
Segmented monitoring is enabled for Source Listing and CNTL command methods only.
 1074


InterTest™ and SymDump ® 11.0
NO
Segmented monitoring is disabled.
The MONOMSEC keyword option tells you if a password is required. If MONOMSEC=YES, you need the password to set
MON or NOM using any method.
NOTE
InterTest for CICS releases prior to 5.1 do not support segmented monitoring.
Methods for Setting and Removing MON and NOM
There are three methods for setting and removing MON and NOM, as shown following:
•Source listing
•CNTL menus
•CNTL one-line commands
The Source listing method is easiest to use.
Use Your Source Listing
This method requires a listing version that corresponds to your load module. If you use an old listing version, you can
experience unpredictable results during execution -- ranging from no effect, to unexpected abends, to data corruption.
Set MON and NOM
To set a location for a MON option in your source listing, enter a plus sign, +, to the left of the statement in your listing
where you want monitoring to begin , and press Enter. Likewise, to set a location for a NOM option, enter a minus sign, -,
to the left of the statement in your listing where you want monitoring to stop, and press Enter. If a password is required,
enter the password at the prompt.
Example
The following screen shows setting MON and NOM in your source listing.
     CA InterTest for CICS   - PROTDEM FILE SOURCE LISTING DISPLAY
  COMMAND ===>
  Program= COBDEMO  Option #       Stmt #                             Margin= 01
                    Label/Search Arg=
  OPTS 1 Proc div  2 Work-stor 3 Link sect 4 D-map      5 Clst/Pmap More:   +


6 Data xref 7 Proc xref 8 Err msgs  9 Srch fwd  10 Srch bwd
  PFKS 1 Help      2           3 End        4 Profile    5 Monitor    6 Menu
       7 Backward  8 Forward   9 Next Wnd  10           11           12 Status

    _ 01057     MOVE ALL '*' TO TASKTEXT OF TASKSTRUCTURE2.
    _ 01058     GO TO SENDMAP00.
 → +  01059 INITIALIZETABLE.
    _ 01060     MOVE SUB1 TO STATENUMBER (SUB1),
    _ 01061                   COUNTYNUM1 (SUB1, SUB2).
    _ 01062     MOVE ','   TO COUNTYCOMM (SUB1, SUB2).
    _ 01063     MOVE SUB2 TO COUNTYNUM2 (SUB1, SUB2).
    _ 01064
 → -  01065 DATANAME.
    _ 01066     IF  TASKSWITCH3 EQUAL SPACE
    _ 01067     MOVE 'A' TO TASKSWITCH3
    _ 01068     MOVE 'DMAP02' TO MAPNAME
    _ 01069     GO TO SENDREWRITERETURN.
 1075


InterTest™ and SymDump ® 11.0
    _ 01070     GO TO SENDMAP00.
    _ 1071 SETVARREC.

Set breakpoints within the execution path of the MON and the NOM locations in the program by using the + and - line
commands. The + line command activates or starts segmented monitoring when that program statement is executed. The
- command stops segmented monitoring when the program statement is executed. These commands will not take effect if
the program statement is never executed.
NOTE
If you specify a MON or NOM option and a breakpoint at the same location, InterTest for CICS displays the
character for the first option entered in column 1, although both options are set. To obtain a status display of the
options in effect, enter STATUS in the command line, and press Enter .
Remove MON and NOM
To remove a MON or NOM option location, overtype the plus sign, +, or minus sign, -, with an X. Press Enter , and the
option is removed.
To quickly remove all segmented monitoring options for a program, turn monitoring off for the program, remove the options
from the Monitoring Status display, or use the .ALL entry on the CNTL Segmented Monitoring ON and OFF menus.
Access the specific CNTL menu directly from the Source Listing Display by making the following entries in the Option #
field:
Option # Entry CNTL Menu Function
=14S Set segmented monitoring on
=14R Remove segmented monitoring on
=15S Set segmented monitoring off
=15R Remove segmented monitoring off
The CNTL Menus
When segmented monitoring is enabled with MENU support, set and remove segmented monitoring for programs directly
from the following CNTL Function Selection Menu, using Options 14 (Segmented Monitoring On) and 15 (Segmented
Monitoring Off).
Notes:


Monitoring Off).
Notes:
•If Options 14 and 15 do not display on the Function Selection menu, menu support for segmented monitoring is not
available to you.
•If segmented monitoring is password protected, you are prompted to enter the password.
•Specifying NOM options with the menus is tricky because of double negatives:
–Use 15S to set a segmented monitoring off, or NOM, location.
–Use 15R to remove a segmented monitoring off, or NOM, location that you previously set.
Specify segmented monitoring locations like you would specify individual breakpoint locations on the Segmented
Monitoring On and Off screens.
CNTL Function 14S Set Monitor On Screen
The following screen is used to set the monitor on locations in COBOL programs. The sample entry (→) specifies that
monitoring begins (or continues) whenever user CARAR01 executes the first executable statement in the paragraph A-
TEST.
 1076


InterTest™ and SymDump ® 11.0
    CA InterTest MONITORING COMMAND BUILDER  SEGMENTED MONITORING LOCATIONS  14

   SET `monitor on' option for  PROG=COBDEMO in any of the following fields:
    (For qualification by nested program name, specify 'Programid:Label')
 → Paragraph A-TEST_______________________     _______________________________
      Names: _______________________________     _______________________________
             _______________________________     _______________________________
   Statement
    Numbers: _____    _____    _____    _____    _____   _____    _____    _____

    Offsets: _____    _____    _____    _____    _____   _____    _____    _____

             user ID (or .ANY) who will execute the program:             CARAR01

There are similar versions of this menu for Assembler and PL/I users. Specify multiple monitors on locations on this menu.
Valid locations are as follows:
•COBOL (paragraph names, statement numbers, or hexadecimal offsets)
NOTE
You cannot specify COBOL data names as segmented monitoring locations.
•Assembler (labels or hexadecimal offsets)
•PL/I (PL/I labels, statement numbers, or hexadecimal offsets)
Press Enter  after specifying the locations.
CNTL Function 14R Remove Monitor On Screen
Remove any option directly from the Monitoring Status display. For more information, see Menus and Displays. Specify
individual locations to be removed exactly as you set them or by the ID number shown on the InterTest for CICS status
display. To quickly remove all locations at once, enter .ALL  in the first field as shown on the menu (→) and enter the same
user ID (or .ANY) used to set the options.


user ID (or .ANY) used to set the options.
The following screen is used to remove the monitor on locations that were previously set in the program for user ID
CARAR01.
     CA InterTest MONITORING COMMAND BUILDER  SEGMENTED MONITORING LOCATIONS  14

     Remove `monitor on' option for  PROG=COBDEMO in any of the following fields:
    (For qualification by nested program name, specify 'Programid:Label')
 →Paragraph .ALL___________________     _______________________________
     Names:  _______________________________     _______________________________
             _______________________________     _______________________________
   Statement
    Numbers: __    _____    _____    _____    _____   _____    _____    _____

    Offsets: _____    _____    _____    _____    _____   _____    _____    _____

            user ID (or .ANY) who will execute the program:             CARAR01
 To remove by ID # shown in status display enter ID # s: -------------

 1077


InterTest™ and SymDump ® 11.0
After specifying the locations, press Enter .
CNTL Function 15S Set Monitor Off Screen
The following screen is used to set locations for no monitoring in COBOL programs; it specifies two locations:
•Specifies the first executable statement in paragraph A-TEST-EXIT.
•Indicates statement number 125 in the program.
Program monitoring is dropped (or continues unmonitored) whenever these locations are executed.
   CA InterTest MONITORING COMMAND BUILDER  SEGMENTED MONITORING LOCATIONS  14

     SET `monitor off' option for  PROG=COBDEMO in any of the following fields:
    (For qualification by nested program name, specify 'Programid:Label')
 →Paragraph A-TEST-EXIT___________________     _______________________________
     Names:  _______________________________     _______________________________
             _______________________________     _______________________________
   Statement
 →  Numbers: 125__    _____    _____    _____    _____   _____    _____    _____

    Offsets: _____    _____    _____    _____    _____   _____    _____    _____

            user ID (or .ANY) who will execute the program:             CARAR01

NOTE
There are similar versions of this menu for Assembler and PL/I users.
Specify multiple monitor off locations on this menu. Valid locations are as follows:
•COBOL (paragraph names, statement numbers, or hex offsets)
NOTE
You cannot specify COBOL data names as segmented monitoring locations.
•Assembler (labels or hex offsets)
•PL/I (PL/I labels, statement numbers, or hex offsets )
After specifying the locations, press Enter .
CNTL Function 15R Remove Monitor Off Screen


After specifying the locations, press Enter .
CNTL Function 15R Remove Monitor Off Screen
Specify individual locations to be removed exactly as you set them, or by the ID number shown on the InterTest for CICS
status display. To quickly remove all locations at once, enter .ALL  in the first field on the menu and the same user ID
(or .ANY) used to set the options. The Monitoring Command Builder Segmented Monitoring Locations screen is used to
remove the monitor off locations that were previously set in the program using the ID number shown in the status report.
Press Enter  after specifying the locations.
CNTL Commands
Before using command syntax to specify segmented monitoring, see Notes and Warnings.
Set MON and NOM Options
To set one or more MON options; use either of the commands shown next. To set one or more NOM options; use NOM
instead of MON in these commands.
 1078


InterTest™ and SymDump ® 11.0
 CNTL=ON,PROG=progname,MON=locn
 CNTL=ON,PROG=progname,MON=(locn1,locn2, ...,locn9)

progname
Indicates one program.
locn
Specifies an address (from six- to eight-hexadecimal digits), offset (from one- to five-hexadecimal digits),
statement number (a decimal number preceded by #), COBOL paragraph name, Assembler or PL/I label
(enclosed in apostrophes).
To specify a location, use the same format as for breakpoints.
At a breakpoint display, enter the abbreviated command form to see this Monitor Table entry:
 CNTL=ON*,MON=... or  CNTL=ON*,NOM=...

Other options, including breakpoints, precede or follow within the same CNTL command.
Remove MON and NOM Options
To remove one or more MON options, use one of the following command forms. To remove all NOM options, use NOM
instead of MON in these commands
 CNTL=OFF,PROG=progname,MON=ID=id
 CNTL=OFF,PROG=progname,MON=locn
 CNTL=OFF,PROG=progname,MON=ID=(id1,id2, ...,id9)
 CNTL=OFF,PROG=progname,MON=(locn1,locn2, ...,locn9)

progname
Indicates the name of one program.
id
Indicates same number as the ID= number displayed by the InterTest for CICS Inquiry Report (obtained by
CNTL=INQ or, at breakpoint, by pressing PF3).
locn


CNTL=INQ or, at breakpoint, by pressing PF3).
locn
Specifies an address (from - to eight-hexadecimal digits), offset (from one to five hexadecimal digits), statement
number (a decimal number preceded by #), COBOL paragraph name, Assembler or PL/I label (enclosed in
apostrophes).
To specify a location, use the same format as for breakpoints.
Specify up to nine IDs or locations, separated by commas and enclosed in parentheses.
To remove all MON options for a Monitor Table entry, use the form:
 CNTL=OFF,PROG=progname,MON=.ALL

At a breakpoint, use the abbreviated command form to see this Monitor Table entry:
 CNTL=OFF*,MON=...
 CNTL=OFF*,NOM=...

Other options, including breakpoints, precede or follow within the same CNTL command.
 1079


InterTest™ and SymDump ® 11.0
NOTE
The command CNTL=OFF,PROG=progname  does not remove the MON or NOM entries for a program. To
remove the MON and NOM options, you must explicitly specify them.
Examples
The following are command examples of specifying MON and NOM options.
To selectively monitor the program COBPROGA from paragraph A-TEST to the paragraph name A-TEST-EXIT, specify:
 CNTL=ON,PROG=COBPROGA,MON='A-TEST'

This command declares a MON option for the first machine instruction in A-TEST. InterTest for CICS monitoring starts
when the first machine instruction at A-TEST is executed.
The following command declares a NOM option for the first machine instruction in statement 123. InterTest for CICS
monitoring stops prior to the execution of this statement.
 CNTL=ON,PROG=COBPROGA,NOM=#123

The following command declares a NOM option for the first machine instruction in the paragraph A-TEST-EXIT.
 CNTL=ON,PROG=COBPROGA,NOM='A-TEST-EXIT'

The following command declares the same options as the three preceding commands.
 CNTL=ON,PROG=COBPROGA,MON='A-TEST',NOM=(#123,'A-TEST-EXIT')

The following command selectively removes the two NOM options that were displayed by an Inquiry Report with ID=
numbers 02 and 03.
 CNTL=OFF,PROG=COBPROGA,NOM=ID=(02,03)
 CNTL=OFF,PROG=COBPROGA,MON=.ALL,NOM=.ALL,LET=.ALL

NOTE


NOTE
Any non-sequential passing of control (such as PERFORM, GO TO, and so on), executed between the MON
location at A-TEST and the NOM location at
A-TEST-EXIT could result in InterTest for CICS monitoring outside the designated range.
Notes and Warnings
The following information contains notes and warning that you should be aware of when using InterTest for CICS.
Location Restrictions
The following bullets list location restrictions:
 1080


InterTest™ and SymDump ® 11.0
•Regardless of how they are set (Source Listing, Menu, or single-line command); each of these options must be placed
on the first byte (the op-code) of a machine instruction that resides in non-store-protected virtual storage. Because the
code must not be store-protected, the application programs must not reside in the LPA, ELPA, or ERDSA.
•Regardless of how they are set (Source Listing, Menu, or single-line command); each of these options must be placed
on the first byte (the op-code) of a machine instruction that resides in non-store-protected virtual storage. Because the
code must not be store-protected, the application programs must not reside in the LPA, ELPA, or ERDSA.
•Any piece of code with these options must remain resident at the same virtual storage address until the options are
removed.
•These options cannot be placed on sequential statement numbers or instruction addresses; that is, these options must
be separated by at least one machine instruction.
•In Command Level CICS applications within code generated by an EXEC CICS, these options must not be placed on
the LOAD 15 that precedes the BALR 14,15 or on that BALR.
Usage Notes and Restrictions
The following bullets list usage notes and restrictions:
•Declare other InterTest for CICS options, such as breakpoints, bypasses, and so on, at the same locations as the MON
and NOM options
•MON and NOM options are not remembered by the InterTest for CICS checkpoint, nor are they restored by the
InterTest for CICS restart (CNTL=RESTART).
•The InterTest for CICS New Copy function does not work until all MON and NOM options are removed from the


affected program. The CEMT SET PROG (xxxxxxxx) NEWCOPY must not be performed until all MON and NOM
options have been removed.
•RELOAD=YES cannot be used for a Program Definition if the program will be debugged using MON or NOB options.
•You cannot use the CICS installation parameter 'RENTPGM=PROTECT' if you plan on using MON or NOM options for
any program that is linked as RENT, AMODE=31 and RMODE=ANY.
•There is a limit of 255 MON or NOM options per CICS region.
•A MON option causes InterTest for CICS monitoring, regardless of the InterTest Exclusion Table.
•Use these options to control application programs only. InterTest for CICS will accept them outside the scope of
applications programming, such as CICS Exits or subsystem interfaces, but the results are unpredictable.
•Do not place MON entries in programs that are used in PLT shutdown processing.
•InterTest for CICS monitoring for a program cannot be removed until any MON and NOM options declared for the
program are removed. To remove all MON and NOM options, specify:
 CNTL=OFF,PROG=progname,MON=.ALL,NOM=.ALL

Programmed Breakpoints Usage
Programmed breakpoints (PBP) are intended primarily for users of PL/I who want to display data areas that InterTest
for CICS normally cannot display or who do not have symbolic information for their programs. Incorporate programmed
breakpoints into COBOL and Assembler code.
Programmed breakpoints differ from other InterTest for CICS breakpoints because they are actually coded by the
programmer into the tested program. A programmed breakpoint occurs because it was written into the monitored
program in the form of a special CALL statement that identifies the data areas to display. The Detailed Breakpoint display


automatically shows, in dump format, up to three data areas named in the CALL statement parameters. There is no need
to enter CORE commands to display these areas. However, if there are more than three data areas, use the command
CORE=ARGnn to display them.
If you are using the Source Listing Breakpoint facility, InterTest for CICS stops the program at the programmed breakpoint.
Press  PF3 DET BKPT to display the Detailed Breakpoint screen to view the requested data areas.
 1081


InterTest™ and SymDump ® 11.0
The programmed breakpoint will not occur unless the automatic breakpoint facility is active. If this facility is not active,
the programmed breakpoint CALL has no effect  on program execution. The programmed breakpoint also does not affect
program execution if the program is not monitored by InterTest for CICS (the called routine only does a return). However,
a small amount of overhead is added to the program's execution. For this reason, programmed breakpoints should be
removed before the program is put into production.
Programmed Breakpoints Coding
To execute a programmed breakpoint, add a special CALL statement to the program source code at the location where
you want the breakpoint to occur. The CALL statement passes control to an entry point named PBP. Code the CALL
statement according to the rules of the programming language being used. It also passes a number of arguments or
parameters. Include a literal that describes the location of the programmed breakpoint as the first parameter so that the
user, especially the PL/I user, identifies the breakpoint easily.
When control comes to the program location where the programmed breakpoint should occur, InterTest for CICS executes
the programmed breakpoint just like an automatic breakpoint, except that in the data portion of the display 16 bytes of the
first three passed parameters are automatically displayed. In addition, a CORE command keyword is provided to display
the parameters.
The small Assembler programmed breakpoint load module, which is identical for all programming languages, must
be prepared by your systems programmer and assembled and link-edited into the proper language library so that it is
automatically included in your module as a result of the CALL. The program follows:
 PBP CSECT
     SR  15,15
     BR  14
     DC  C'PBPINTERTEST'
     END PBP


DC  C'PBPINTERTEST'
     END PBP

Declare a Programmed Breakpoint in a PL/I Program
A PL/I program with a programmed breakpoint must be coded to define the entry point as passing parameters in
Assembler fashion, as shown next:
 DCL PBP ENTRY OPTIONS(ASSEMBLER);

Once this is done, code the calls in the usual manner.
Example
 WRITE_RESPONSE:
   RESPONSE = ERROR CODE;
   CALL PBP ('WRITE_RESPONSE',RESPONSE,ADDR(REC_SIZE));

At this programmed breakpoint, the breakpoint display shows the following data areas:
•The characters WRITE_RESPONSE tell you which programmed breakpoint (if many was coded) is being executed
•The first 16 bytes of the field named RESPONSE
•The full word that contains the address of the field named REC_SIZE
NOTE
If you do not include parameters in the CALL statement, a programmed breakpoint still occurs but no data is
displayed.
 1082


InterTest™ and SymDump ® 11.0
Declare a Programmed Breakpoint in a COBOL Program
The CALL statement that sets up a programmed breakpoint in a COBOL program is coded in the standard manner as
follows:
 WRITE-RESPONSE.
   MOVE ERROR-CODE TO RESPONSE.
   CALL 'PBP' USING RESPONSE.

At this programmed breakpoint, the breakpoint display shows the first 16 bytes of the field named RESPONSE.
If you do not include parameters in the CALL statement, a programmed breakpoint still occurs but data is not
automatically displayed.
Declare a Programmed Breakpoint in an Assembler Program
In Assembler you must use the CALL macro, coded so that the last parameter is marked as such, or coded without
parameters. Because of the restrictions of the CALL macro, it is often practical not to code parameters. The breakpoint
display shows the location of the programmed breakpoint and the contents of the registers.
If you do not include parameters in the CALL statement, a programmed breakpoint still occurs but data is not
automatically displayed.
Remove a Programmed Breakpoint
Once you code a programmed breakpoint CALL in a program, the breakpoint occurs every time execution reaches the
programmed breakpoint's location during an interactive session. The only way to deactivate the programmed breakpoint is
to replace the BALR 14,15 instruction in the program, which is contained in the CALL statement, by a NOPR 0. When the
task is waiting at breakpoint, do this easily by issuing the command:
 CORE=CURR=CHGX'0700'

However, since this modifies the program's code, the programmed breakpoint will not occur again until the program is
reloaded by CICS.
After program testing is complete, the programmed breakpoint CALL statements should be removed for improved
performance.
Monitoring CICS/FEPI Applications


performance.
Monitoring CICS/FEPI Applications
The Front-End Programming Interface (FEPI) provides terminal emulation using virtual terminals defined to a CICS region.
These virtual terminals, called nodes, communicate with back-end processes that run either in the same CICS region or
in a remote region. Front-end processes, which are coded with EXEC CICS FEPI commands, communicate with both real
and virtual terminals.
InterTest for CICS lets both front-end and back-end processes be tested. However, the terminal IDs must be properly
specified when breakpoints are set.
Set Monitoring and Breakpoints for a Front-End Process
Set monitoring and breakpoints as usual when testing a front-end process only.
Set Monitoring and Breakpoints for a Back-End Process
Turn on monitoring as usual for a back-end process running in a local CICS region.
 1083


InterTest™ and SymDump ® 11.0
To set breakpoints for a back-end process running in a local region, specify both the terminal at which the process is
running and the terminal to receive breakpoints, as follows:
•Term ID where breakpoints take effect: (F=)
The virtual terminal assigned by CICS. Specify either an actual virtual terminal name or .ANY if the terminal is
assigned from a pool and its name is not known.
•Term ID that receives the breakpoints: (T=)
The real terminal to which breakpoints should be sent.
It is important that breakpoints  not be sent to a virtual terminal because this could disrupt the application dialog screen
flow.
If the back-end process is running in a remote CICS region, turn on monitoring in the remote region and ensure that the
terminal that receives breakpoints is a real terminal connected to the remote region.
Set Breakpoints for Both Front-End and Back-End Processes
To set breakpoints for both front- and back-end processes that are running concurrently, follow the steps outlined in
the previous sections. However, make sure that  two real terminals are available for receiving breakpoint displays: one
for breakpoints from the front-end process, and one for breakpoints from the back-end process. For example, if both
processes are running in the same CICS region, you might enter the following commands from TER1:
 CNTL=ON,PROG=FRONTEND,UBP=#1
 CNTL=ON,PROG=BACKEND,UBP=((#1),F=VIR1,T=TER2)

Breakpoint displays for program FRONTEND are sent to TER1, the terminal at which the command was issued.
Breakpoint displays for program BACKEND are sent to TER2.
If the back-end process is running in a remote CICS region, perform these steps:


If the back-end process is running in a remote CICS region, perform these steps:
1.Set monitoring and breakpoints for the front-end  process in the local region.
2.Set monitoring and breakpoints for the back-end  process in the remote region from any real terminal.
TIMEOUT Values
If a TIMEOUT(seconds) parameter is specified on an EXEC CICS FEPI command when InterTest for CICS is monitoring
a back-end process, all breakpoint activity must be completed within the specified time. Otherwise, the front-end virtual
terminal session times out and the back-end process could abend. To avoid this, it is strongly recommended that the FEPI
TIMEOUT value be set to zero during testing. Change it to an appropriate value when testing is completed.
InterTest for CICS with the IBM EDF (EXEC Debugging Facility)
The EDF facility, which is activated by the CEDF transaction and described in the IBM CICS/VS Application Programmer's
Guide Command Level , does not interfere with EDF, except when EDF presents the EDF breakpoint display of the
program being monitored by InterTest for CICS. EDF incorrectly indicates the location of the command since commands
are issued by InterTest for CICS, not by the program.
Advantages of InterTest for CICS Over EDF
InterTest for CICS offers many advantages over the EDF facility, including the following benefits:
 1084


InterTest™ and SymDump ® 11.0
•The ability to set breakpoints anywhere in the program (not just at EXEC CICS commands).
•Data display/modification by symbolic names. This means the programmer does not need the most recent listing of the
tested program, as long as the data names or paragraph names (labels in Assembler) remain the same.
•Monitoring with the ability to detect any illegal action of the program between CICS commands. CICS abends are
intercepted by EDF, but damage might have occurred on the way to the abend, and EDF might not give any specifics
on the problem.
•The ability to declare an unconditional or conditional breakpoint at a specific location -- the EXEC CICS call at the point
when the EXEC CICS call parameters are already formatted. At that time change the parameters (for example, by
issuing the CORE=ARGnn command) before you let the command execute.
•The ability to set request breakpoints for a particular type of CICS command, regardless of where in the program
it occurs, or for all EXEC CICS commands, or for all except some EXEC CICS commands. For example, with one
specification set breakpoints at all File Control commands or at all READ or WRITE commands.
Using InterTest for CICS with EDF
If you want to use InterTest for CICS with EDF, turn on EDF before you begin monitoring a program with InterTest for
CICS. Moreover, when a monitored program is stopped at a request breakpoint for an EXEC CICS command, activate
EDF by entering any character in the field marked EDF in the lower right corner of the Detailed Breakpoint display.
When InterTest for CICS and EDF are being used on the same task, be aware of the following points:


•If an InterTest for CICS breakpoint is set at an EXEC CICS command, the InterTest for CICS breakpoint occurs before
the command is passed to CICS.
•At the breakpoint, the programmer reviews and changes any parameters of the command before telling InterTest for
CICS to continue with the task.
•InterTest for CICS checks the parameters and, if necessary, halts the task at an automatic breakpoint.
•If that does not happen, the command is passed by InterTest for CICS to CICS for execution; that is, to the EXEC
Interface.
•Subsequently, EDF presents the before a command breakpoint. The EDF facility, however, is in control at that time and
any changes by you during the EDF breakpoint cannot be checked by InterTest for CICS.
•Only after the command is executed, the EDF breakpoint display opens, and EDF is told to continue with the task can
InterTest for CICS resume control and continue monitoring.
CNTL Commands and Menus
The primary task of InterTest for CICS is to monitor programs so that it detects and prevents errors. The InterTest for CICS
CNTL transaction performs all monitoring functions.
NOTE
The CNTL Monitoring Command Builder menu topics are included here as a reference for InterTest for CICS
users familiar with this method of performing monitoring functions from previous releases.
CNTL Capabilities
Use the CNTL transaction to perform these functions:
•Monitoring
•Breakpoints
Monitoring
Set and remove monitoring for one or more programs, all the programs executed by a transaction, or all the programs
executed from a terminal.
 1085


InterTest™ and SymDump ® 11.0
Breakpoints
Set and remove unconditional or conditional breakpoints.
Set and remove request breakpoints prior to CICS commands, calls to DL/I or DB/2, and calls to database software.
Monitoring Options
With the InterTest for CICS CNTL feature, you can:
•Set and remove statement tracing options for COBOL programs, including data monitoring
•Dynamically replace one or more CICS resources (programs, files, temporary storage, transient data queues) used by
a program
•Override default protection rules
•Set and remove special monitoring options, such as limiting the number of times a program is monitored or preventing
a program from updating a file
•Provide symbolic support for programs that consist of separately compiled modules brought together when the
program is link-edited (composite support)
•Set and remove non-interactive monitoring sessions for a program executed by a transaction, or for all programs
executed from a terminal
Status Display, Utility, and System Options
With the InterTest for CICS CNTL feature, you can:
•Display the status of monitored programs, transactions, or terminals
•Display the contents of InterTest for CICS tables and files
•Reset monitoring for a recompiled program
•Establish monitoring options for the entire system
Resume Task Execution
With the InterTest for CICS CNTL feature, you can resume execution of a task halted at a breakpoint.
NOTE
Use the CNTL menus and screens or CNTL commands to perform all of the functions listed in the previous two
sections. Additional options, specified by commands, are available to perform more specialized functions.
Initiate Monitoring
InterTest for CICS provides many ways of initiating monitoring and performing other CNTL functions:
•Source listing facility
•ITST menus and fill-in screens
•CNTL menus and fill-in screens


•ITST menus and fill-in screens
•CNTL menus and fill-in screens
•CNTL commands
With the CNTL facility use one method exclusively or use the mix-and-match method -- even during one test session,
depending on your specific testing needs.
Example
Use the source listing facility to initiate monitoring and set breakpoints, the CNTL menus and screens to set special
options, and a single-line command to resume execution of a task.
The easiest way to turn on monitoring and set breakpoints for a single program is to use the source listing facility. For
a new or infrequent user, this method is strongly recommended. Turn on monitoring by pressing a PF key, and set a
 1086


InterTest™ and SymDump ® 11.0
breakpoint by entering a single keystroke directly on your program's source listing. For more information about this facility
and what to do when your program halts at a breakpoint, see Source Listing Facility for InterTest.
To take advantage of the full range of InterTest for CICS monitoring capabilities, use the CNTL Monitoring Command
Builder menus and screens or enter CNTL commands. Nearly all the monitoring functions are implemented either way, so
select the method that suits you best.
The CNTL Monitoring Command Builder menus and screens make it easy for you to specify the necessary information
without worrying about command syntax. All you have to do is select the function you want and enter the data -- InterTest
for CICS creates the right command for you. Online Help is available from every screen using PF1 to provide you with
more information.
If you prefer, enter single-line CNTL commands to specify monitoring functions. More experienced users often find it faster
to enter commands directly.
To access online Help when entering single-line commands, type Help on a clear screen. InterTest for CICS displays the
Transaction Codes screen. Press Enter  and InterTest for CICS displays the help facility master menu. Two main topics
(program monitoring and breakpoints) and their associated subtopics provide information on CNTL commands.
Monitor Command Building Menus and Screens
This section describes how to use the CNTL Monitoring Command Builder menus and screens to perform the following
CNTL functions. The order in which CNTL functions are described corresponds to their order on the Function Selection
Menu.
Function Selection Menu
The main menu for selecting CNTL functions.
Setting and Removing Monitoring
Begin and end monitoring for programs, transactions, or terminals.
Setting and Removing Unconditional Breakpoints
Set and remove unconditional breakpoints.
Setting and Removing Conditional Breakpoints


Set and remove unconditional breakpoints.
Setting and Removing Conditional Breakpoints
Set and remove conditional breakpoints.
Setting and Removing Request Breakpoints
Set and remove request breakpoints before CICS commands, calls to DL/I, DB2, and SQL/DS, and calls to
database software.
Setting and Removing Statement Trace Options
Set and remove statement tracing and data monitoring for COBOL programs.
Setting and Removing Replacement Options
Dynamically change CICS resources: programs, files, transient data queues, temporary storage.
Setting and Removing Protection Options
Bypass InterTest for CICS rules that protect main storage, the CSA, and load modules.
Setting and Removing Special Options
Modify monitoring rules (for example, prevent a program from updating a file, allow a program to branch to
another program, limit the number of times a program is monitored).
Setting and Removing Composite Support
Provide symbolic support for a program that consists of separately compiled modules.
Status Display
Display the monitoring status of a program, transaction, or terminal.
Utility Options
Display the contents of InterTest for CICS tables and files, and reset monitoring for a recompiled program.
 1087


InterTest™ and SymDump ® 11.0
System-Wide Options
Request monitoring options on a system-wide basis.
Resume Task Execution
Resume execution of a task stopped at a breakpoint.
Access the Monitoring Command Builder Main Menu
To display the Monitoring Command Builder main menu (the Function Selection Menu), enter CNTL  on a clear screen, or
enter CNTL on the command line of any source listing, detailed breakpoint, or CORE screen.
The Function Selection Menu
The Function Selection screen is the main menu for the Monitoring Command Builder. This menu lists the different CNTL
functions detailed later.
If you select this function: Also enter this:
10 through 22 In second field, enter S or R to specify SET or REMOVE. If left
blank, it defaults to S.
10, 13, 16, 20, 21, 22, 24, or 30 Enter the program names, transaction codes, or terminal names.
Specify from one to six programs, one to nine transactions, or
one to nine terminals, but you cannot combine different types of
entries. Specify .ALL to indicate all programs, transactions, or
terminals. Also specify .OPTIONS in the Program Names field to
set options for all programs. Optionally, specify a CICS user ID,
such as MARY01, or .ANY to override the user ID default.
11, 12, 14, 15,or 23 In the Program Names field, enter one program name. Optionally,
specify a CICS user ID, such as MARY01, or .ANY to override the
user ID default.
31, 32, or 33 Do not specify program names, transaction codes, terminal
names, or a user ID value.
NOTE


names, or a user ID value.
NOTE
If a program is stopped at a breakpoint and you type CNTL  in the command line to access the Function
Selection Menu, InterTest for CICS displays the name of the monitored entry (program, transaction, or terminal)
on this screen.
When you have entered all the necessary information, press Enter . In most cases, a second screen opens. If you have
specified multiple programs, transactions, or terminals, the names of all the entries display on subsequent screens.
When you set breakpoints, replacement, protection, special options, or composite support, you automatically set
monitoring for the programs, transactions or terminals that you specify. So, for example, it is not necessary to set
monitoring and set breakpoints; setting breakpoints accomplishes both functions.
However, when you remove  breakpoints, replacement, protection, special options, or composite support, you do not
remove monitoring for the programs, transactions, or terminals that you specify. Monitoring remains in effect until you
explicitly instruct InterTest for CICS to remove monitoring.
Generic Specification of Programs, Transactions, or Terminals
When you set monitoring or monitoring options for a specific program, transaction, or terminal, InterTest for CICS creates
an entry for that program, transaction, or terminal in the monitoring table. Also set monitoring or monitoring options
generically by specifying asterisks, *, and plus signs, +, to replace characters in a program name, transaction code, or
terminal name. These specifications are interpreted according to the rules for the CICS CEMT transaction.
 1088


InterTest™ and SymDump ® 11.0
•An asterisk specifies any number of characters, including no characters. Specify more than one asterisk in a program
name, transaction code, or terminal name. Do not, however, specify an asterisk by itself.
•A plus sign specifies just one character in a particular position. Specify more than one plus sign in a name or code. Do
not, however, specify a plus sign by itself.
•Combine asterisks and plus signs.
Examples
Here is how the following specifications are processed:
ABC*
Specifies all names or codes that begin with ABC, including ABC.
*ABC
Specifies all names or codes that end with ABC, including ABC.
AB*C
Specifies all names or codes that begin with AB and end with C with an unspecified number of characters in the
middle.
ABC+
Specifies all four-character names or codes that begin with ABC followed by any one character.
+ABC
Specifies all four-character names or codes that begin with any character followed by ABC.
AB+C
Specifies all four-character names or codes that begin with AB followed by any one character and C.
AB+C*
Specifies all names or codes that begin with AB followed by one character, C, and an unspecified number of
characters.
Hierarchy Rules for Monitored Entries
It is important to know the priorities InterTest for CICS observes if more than one entry in the monitoring table applies to
the same program.
•A specific or generic program entry overrides a transaction entry, a terminal entry, and an .ALL specification
•A transaction entry overrides a terminal entry and an .ALL specification
•A terminal entry (specific or generic) overrides an .ALL specification
Example
Suppose you specify monitoring options for program ABC1 and different options for transaction TRN1. ABC1 executes


as part of that transaction. When ABC1 executes, the options specified for ABC1 override the options specified for TRN1.
Similarly, it is important to understand the priorities InterTest for CICS observes when a program, transaction, or terminal
is specifically and generically declared for monitoring. A specific entry overrides a generic entry except when you request
Status Display. In this case, the generic specification takes precedence.
Suppose you specify monitoring options for program ABC1 and different monitoring options for program ABC*. The
options specified for ABC* affect all programs whose names begin with ABC except for program ABC1 (and any other
programs beginning with ABC that have their own entries in the monitoring table). Monitoring for ABC1 is controlled by the
specific entry for that program. However, if you request a status display for program ABC*, you will get monitoring status
reports for all programs that begin with ABC, including program ABC1 that has a separate monitoring table entry.
 1089


InterTest™ and SymDump ® 11.0
PF Keys
Exit from the Function Selection Menu by pressing a PF key. Most of these PF keys are also in effect on other Monitoring
Command Builder screens. The following bullets describe the function of each PF key.
PF1 or 13
Initiates the InterTest for CICS online help facility.
PF2 or 14
Unassigned
PF3 or 15
Terminates the Function Selection Menu screen and returns to the active breakpoint, if appropriate. Pressing
Clear does the same thing.
PF4 or 16
Returns to the source listing display facility.
PF5 or 17
Unassigned
PF6 or 18
Unassigned
PF7
Unassigned
PF8
Displays your previous CNTL Monitoring Command Builder screen with the specified data.
PF9 to end
Unassigned
Monitoring
Set and remove monitoring for programs, transactions, or terminals directly from the Function Selection Menu.
Specify function 10, S or R, and the program names, transaction codes, or terminal names, and press Enter. For more
information, see Function Selection Menu. This is the only screen you need to complete.
You can set a non-interactive monitoring session using CNTL options. For more information, see TFL Set Non-Interactive
Monitoring.
Set Monitoring
When you set monitoring for a:
Program
InterTest for CICS detects and prevents errors before  they occur. That means monitored programs will not abend
or commit storage violations. InterTest for CICS monitors the program from whatever terminal it executes, even
if it executes as part of a non-terminal owning task. Use the replacement, protection, or special options screen if
you want to restrict monitoring to a specific terminal.
Transaction
InterTest for CICS monitors all of the transaction's programs.
Terminal


Transaction
InterTest for CICS monitors all of the transaction's programs.
Terminal
InterTest for CICS monitors every program that executes at that terminal.
NOTE
InterTest for CICS will not monitor programs that begin with the prefix DFH (IBM CICS programs) or IN25
(InterTest for CICS programs).
 1090


InterTest™ and SymDump ® 11.0
If you set monitoring for a transaction or terminal, and a program executing as part of that transaction or at that terminal
is stopped at an automatic breakpoint, InterTest for CICS automatically creates an individual entry in the monitoring
table for that program. This lets you set breakpoints and monitoring options specifically for that program. Similarly, if
you specify .ALL in the Program Names field on the Function Selection Menu or if you specify a generic program name,
InterTest for CICS creates an individual monitoring table entry for any program monitored under that entry when it stops at
an automatic breakpoint.
Set the User ID for Monitoring
Monitoring is sensitive to CICS user IDs.
Remove Monitoring
Before you remove monitoring, you might want to produce a report of all InterTest for CICS monitoring activity to make
sure other users are not currently testing the same programs. Press PF12  Status to produce a monitoring report.
When you remove monitoring, you also remove all breakpoints and monitoring options specified for that program,
transaction, or terminal. A quick way of creating a new testing scenario for a program is to remove and then reset
monitoring with different breakpoints and options.
NOTE
Remember that you can also set monitoring by setting breakpoints, replacement, protection, special options, or
composite support. However, if you remove breakpoints, options or composite support, monitoring remains in
effect   for the specified programs until you specifically instruct InterTest for CICS to stop monitoring.
Unconditional Breakpoints
When you set unconditional breakpoints, InterTest for CICS halts the program at the specified locations. InterTest also
automatically monitors that program.
To set or remove unconditional breakpoints, specify function 11, S or R, and the program name on the Function Selection
Menu, and press Enter. For more information, see The Function Selection Menu.
Set Unconditional Breakpoints


Set Unconditional Breakpoints
Use the Breakpoint Locations screen to set unconditional breakpoints.
To set breakpoints, enter the following information:
Specify up to nine breakpoint locations in fields.
COBOL
For COBOL program, specify a paragraph name or data name, a statement number, or the hexadecimal displacement
(offset) from the beginning of the program.
ASSEMBLER
For an Assembler program, breakpoint locations are Assembler labels, datanames, or offsets.
PL/I
For a PL/I program, breakpoint locations can be offsets or, if you have the PL/I symbolic option, PL/I labels or statement
numbers.
Follow these rules when specifying information:
 1091


InterTest™ and SymDump ® 11.0
•If you specify statement #1, InterTest for CICS sets a breakpoint at the first executable instruction in a COBOL
Procedure Division, Assembler CSECT, or PL/I procedure.
•COBOL statements can contain more than one verb. In specifying statement numbers, indicate the verb at which
the breakpoint should occur. A statement number of nnn or nnn.0 indicates the first verb in the statement, nnn.1
indicates the second verb, nnn.2 indicates the third verb, and so on. For example, a statement number entered as
503.3 specifies a breakpoint at the fourth verb in statement number 503.
•If you specify a COBOL or Assembler data name, breakpoints are set at every reference to that data name.
•Enter an X in the All paragraph names field (COBOL) or All Assembler labels field to set breakpoints at all paragraph
names or all labels.
Optional specifications:
•If you set a breakpoint within a loop, specify a value in the Enter 'n' to stop only every n'th time field to set how often
the program should be halted. For example, if you specify 3, the breakpoint occurs every third time the program
passes through the loop.
•Specify the ID of the terminal where the program must be executing for breakpoints to take effect. If you leave this
field blank, it defaults to your current terminal. Enter .ANY to have breakpoints take effect at all terminals, even when
the program executes without a terminal. Enter .NO to have breakpoints take effect only when the program executes
without a terminal.
•Specify the ID of the terminal to receive breakpoint displays. If you leave this field blank, it defaults to your current
terminal. Enter .ANY to have breakpoint screens displayed at the terminal where the program is executing when


terminal. Enter .ANY to have breakpoint screens displayed at the terminal where the program is executing when
breakpoints occur.
•Specify the statement number of the indirect command that you want to invoke at the breakpoint you have set.
•Specify the user ID who must be executing the program for the breakpoint to take effect. Valid entries are .ANY or a
specific CICS user ID.
When you complete entering all the necessary information, press Enter .
Example
The following screen shows how to set unconditional breakpoints at four locations in the COBOL program COBDEMO.
CA InterTest MONITORING COMMAND BUILDER  COBOL BREAKPOINT LOCATIONS   11

    SET breakpoint locations for PROG=COBDEMO  in any of the following fields:
    (For qualification by nested program name, specify 'ProgramID:Label')

   Para/Data return-transid________________      _______________________________
     Names: _______________________________      _______________________________
            _______________________________      _______________________________
  Statement
   Numbers: 1____    136__    174.2    _____    _____    _____    _____    _____

   Offsets: _____    _____    _____    _____    _____    _____    _____    _____

            All paragraph names:  _

           Enter 'n' to stop only every n'th time:                         ____
           Term ID (or .ANY or .NO) where breakpoints will take effect:    ____
           Term ID (or .ANY) that will receive the breakpoints:            ____
           Statement no. of indirect command(s) to be executed:         ________
           user ID (or .ANY) who will execute the program              MARY01___
The information in the previous screen causes breakpoints to occur at:
 1092


InterTest™ and SymDump ® 11.0
•Paragraph RETURN-TRANSID
•Statement 1 (the beginning of the Procedure Division)
•First verb in statement 136
•Third verb in statement 174
Because the user ID field specifies a single user and the terminal ID fields are left blank, the breakpoints take effect at any
terminal under which User MARY01 is executing COBDEMO.
Remove Unconditional Breakpoints
If you indicated that you want to remove unconditional breakpoints, the Remove Breakpoint Locations screen opens.
COBOL, PL/I, and Assembler versions of the Breakpoint Locations screen are available.
To remove a breakpoint, specify the information that you originally defined on the Set Breakpoint Locations screen, or
enter its ID number on the bottom of the screen.
The ID number appears on the Detailed Breakpoint display. Press PF12 Status to request a status report for the program.
This report lists the ID of each breakpoint.
NOTE
To remove all unconditional breakpoints from a program, enter .ALL in the Para/Data field, and press Enter .
Conditional Breakpoints
When you set conditional breakpoints, InterTest for CICS halts the program at the specified locations only  if a condition is
met. Conditional breakpoints are very useful in isolating complex problems.
To set or remove conditional breakpoints, specify function 12, S  or R, and the program name on the Function Selection
Menu, and press Enter. For more information, see The Function Selection Menu.
Set Conditional Breakpoints
First, InterTest for CICS displays the Conditional Locations screen.
This screen is similar to the screen used to specify unconditional breakpoints, and you should enter the information in the
same way. For more information, see Set Unconditional Breakpoints.
A special feature lets you set a conditional breakpoint at  all instructions.
To set conditional breakpoints:


A special feature lets you set a conditional breakpoint at  all instructions.
To set conditional breakpoints:
1.Enter an x in the All Instructions field to request this option. If you request the All Instructions option and set a variable-
change breakpoint, the breakpoint takes effect whenever the value of the variable changes.
2.Specify the breakpoint locations, and press Enter  to display the Conditional Breakpoint screen.
3.Specify the condition that must be satisfied for the breakpoint to take effect on the Conditional Breakpoint screen.
There are two versions of the Conditional Breakpoint screen: a simplified version for COBOL users, and a detailed version
for PL/I and Assembler users and for those COBOL users who prefer this version.
On either version you, specify a condition in this format:
left side relational operator right side
 1093


InterTest™ and SymDump ® 11.0
Variable-Change Breakpoints
•COBOL and Assembler users set a conditional breakpoint to take effect whenever the value of a variable changes. To
do this, type x in the All Instructions field on the Conditional Locations screen.
•COBOL users must then specify the variable name on the Conditional Breakpoint screen.
•Assembler users must then specify the variable name on the Detailed Conditional Breakpoint screen, as discussed
previously in The Detailed Conditional Breakpoint screen.
The value entered in the Operator field determines if the breakpoint occurs whenever the value of the variable changes
(NE) or only when the value increases, decreases, or does not change. Whenever you re-execute the program, the initial
value of the variable is reset to its value at the beginning of program execution.
Literal Formats
Specify four types of literals for the right side of the comparison:
Character
Specify character literals for comparisons with any field except a COBOL data name defined as COMP or
COMP-3. Enter the literal as C'character data', X'hexadecimal data' , or a combination of both. For example,
C'ABC', X'0102', or C'ABC'X'0102'.
Packed
Specify packed decimal literals for comparisons only with COBOL data names defined as COMP-3. Enter the
literal as P'number' . The number can be preceded by a minus sign. For example, P'123' or P'-123'.
Halfword
Specify halfword literals for comparisons with COBOL data names defined as COMP with a length of four, as in
S9(4) COMP. Enter the literal as H'number' . The number can be preceded by a minus sign. For example, H'12' or
H'-12'.
Fullword


H'-12'.
Fullword
Specify fullword literals for comparisons with COBOL data items defined as COMP with a length of eight, as in
S9(8) COMP. Enter the literal as F'number' . The number can be preceded by a minus sign. For example, F'100'
or F'-100'.
Figurative Constants
Specify the following figurative constants for the right side of the comparison:
Valid Right Side
Specifications for the
Comparison
ZERO
ZEROS
ZEROESnumeric value 0 HIGH-VALUE
HIGH-VALUEScharacter value X' FF'
SPACE
SPACESblank (X' 40' ) LOW-VALUE
LOW-VALUEScharacter value X' 00'
Example
The following sample screen shows how to set a conditional breakpoint in a COBOL program.
           CA InterTest MONITORING COMMAND BUILDER  CONDITIONAL BREAKPOINT

   Enter LEFT SIDE
       Data Name tolen ________________________________________________________
 1094


InterTest™ and SymDump ® 11.0

      Enter OPERATOR (EQ, NE, GT, LT, GE, LE):  lt

   Enter RIGHT SIDE
       Data Name ______________________________________________________________
          OR
       Literal 80______________________________________________________________

 _ Enter  S  to Drop monitoring on a true condition

 Press PF9 to go to complex conditional screen if necessary

•The left side of the comparison specifies the data name TOLEN.
•The relational operator is LT (less than).
•The right side of the comparison specifies the literal 80.
This breakpoint takes effect only if the value in the data name TOLEN is less than 80. The breakpoint locations are all the
instructions, as previously specified on the Conditional Locations screen.
Remove Conditional Breakpoints
When you specify that you want to remove  conditional breakpoints, the Remove Conditional Locations screen opens.
The easiest way to remove a conditional breakpoint is from the Monitoring Status display. For more information, see
Menus and Displays. To remove all conditional breakpoints from a program, enter .ALL in the Para/Data field, and press
Enter.
The Detailed Conditional Breakpoint Screen
When Assembler and PL/I users want to specify conditional breakpoints complete the Conditional Locations screen and
press PF9, the screen opens. COBOL users access this screen by pressing PF9 from the COBOL Conditional Breakpoint
screen.
Specify the following values:
•The left side of the comparison must be an area of core. Enter information in  one of these four fields:
–Data name
–Register
–COBOL BLL cell
–Area identified by a CORE keyword
•The relational operator:
 1095


InterTest™ and SymDump ® 11.0
–EQ for equal
–NE for not equal
–GT for greater than
–LT for less than
–GE for greater than or equal to
–LE for less than or equal to
•(Optional) The length of the left side or right side of the comparison. For more information, see Length of the
Comparison.
•The right side of the comparison, which is an area of core or a literal. Enter information in one of these five fields: a
data name, a register, a COBOL BLL cell, an area identified by a CORE keyword, or a literal. For more information,
see CORE Keywords and Literal Formats.
•(Optional) Adjusts a CORE location by specifying offsets (displacements). Each offset must be preceded by one of the
following operands:
–+
–-
–@ (indirect addressing below the 16-megabyte line) % (indirect addressing above the 16-megabyte line; XA
systems only)
–Literals cannot be modified by offsets.
Length of the Comparison
Explicitly define how many bytes of the left side or right side specification should be compared. Certain storage locations
have implicit lengths:
•A register or COBOL BLL cell has an implicit length of four bytes
•The storage locations referred to by the CORE keywords MXR, MXS, and TAL have implicit lengths of four bytes
•The implicit length of a COBOL data name is its field length as defined in the DMAP
•The length of a literal is the number of bytes it contains; any length specification is ignored
Define both left side and right side lengths for a packed decimal (COMP-3) comparison. For all other comparisons, define
only one length. If you define both lengths, the smaller length is used.


only one length. If you define both lengths, the smaller length is used.
The maximum permissible length for the left side or right side is 16 bytes for packed decimal data and 255 bytes for all
other data types.
Literal Formats
For more information about specifying literals, see Figurative Constants.
CORE Keywords
Specify the following CORE keywords on the left side or right side of the comparison:
CMAR
First byte of the EXEC CICS Communications Area for the task
CSA
First byte of the CSA
CURR
Next Assembler instruction to be executed
CWA
First byte of the CWA
 1096


InterTest™ and SymDump ® 11.0
CWK
First byte of the COBOL program's Working-storage
DSA
First byte of the program's DSA
ITBE
First byte of the next instruction to be executed
LCL
First byte of the COBOL program's local-storage
MXR
InterTest for CICS maximum CICS request counter (implicit length = 4)
MXS
InterTest for CICS maximum storage counter (implicit length = 4)
OPFL
First byte of the optional features List
PGM=*
First byte of the monitored program
PREV
Last Assembler instruction executed
Rnn
A register ( nn is a decimal from 1 to 15) (implicit length = 4)
TAL
InterTest for CICS tally fullword (implicit length = 4)
TERM=*
First byte of the terminal table entry of the current terminal
TGT
First byte of the COBOL TGT for the monitored task
TIOA
First byte of the first TIOA of the task
TWA
First byte of the TWA of the monitored task
Request Breakpoints
Set request breakpoints to halt a program prior to CICS commands and other program calls, such as calls to DL/I, DB2,
or SQL/DS. Instruct InterTest for CICS to halt the program before every CICS command, or a type of CICS command,
such as file control or program control commands. Specify that the program halts before specific commands, such as all
READ or WRITE commands. Once the program halts, Use all of the InterTest for CICS facilities to inspect and modify
main storage or auxiliary storage or to set additional options.
To set or remove request breakpoints:
1.Specify function 13, S or R.


To set or remove request breakpoints:
1.Specify function 13, S or R.
2.Specify the program names, transaction codes, or terminal names on the Function Selection Menu, and press Enter.
InterTest for CICS displays the Request Breakpoint Selection menu. Enter an x next to the options you want to select.
You can specify any of the following breakpoints:
ALL commands
The program halts prior to all CICS commands.
 1097


InterTest™ and SymDump ® 11.0
DL/I
The program halts prior to all DL/I calls.
DB2
The program halts prior to all calls to DSNHLI (for DB2 users) or prior to all calls to ARIPRDI (for SQL/DS users).
CALLS
The program is halted prior to calls to software that InterTest has been instructed to recognize at installation time.
A second screen, where you specify the calls, displays.
NOTE
If you select a type of CICS command, InterTest for CICS displays a second screen. For example, if you select
File Control, InterTest for CICS displays the File Control screen.
NOTE
Place your cursor on a field and press F1 for a description of that field.
When you have entered all necessary information, press Enter .
To remove requested breakpoints, use the Monitoring Status display. Alternatively, enter the information exactly as you
originally defined it.
Statement Trace Options
NOTE
These options are unrelated to the backtrace facility.
Set Statement Trace options to save trace information for executed COBOL statements and to capture data values for
those statements. Remove the Statement Trace options to delete the trace data.
To set or remove Statement Trace options, follow these steps.
1.Specify function 16, S or R.
2.Specify the program names, transaction codes, or terminal names on the Function Selection Menu, and press  Enter .
The Statement Trace Options screen opens. For more information, see The Function Selection Menu.
Specify the following options on this screen. The equivalent option used in single-line commands is specified in
parentheses.
Statement tracing (TRC)
Instructs InterTest for CICS to save trace information for every executed COBOL statement.
Data monitoring (DM)