Getting Started with Xpediter/Eclipse

Transcription

1 Getting Started with Xpediter/Eclipse This guide provides instructions for how to use Xpediter/Eclipse to debug mainframe applications within an Eclipsebased workbench (for example, Topaz Workbench, Eclipse, or RDz). To become acquainted with Eclipse-based frameworks, refer to the Topaz Workbench User Guide help. To use the features of Xpediter/Eclipse, the Compuware Host Explorer feature must also be installed. For Topaz Workbench users, the Host Explorer is included with the kit and is installed accordingly. For Eclipse/RDz users, the Host Explorer is installed separately. IMPORTANT: To use Xpediter/Eclipse, you must define an HCI connection and connect Topaz Workbench or Eclipse/RDz to a mainframe system. Connections are defined within the Preferences dialog box, which is available from the Window menu by selecting Preferences> Compuware>Host Explorer>Host Connections. A Host Communication Interface (HCI) connection between the mainframe host and Topaz Workbench should have already been established during the installation and configuration of Topaz Workbench. Contact your system administrator to obtain specific connection credentials for your site for establishing Host Connections. (For system administrators, refer to the appropriate installation guide for further information on installing and configuring the HCI.) Related Topics Opening the Xpediter Perspective Setting Xpediter/Eclipse Preferences Debugging in Xpediter/Eclipse Cheat sheets

2 Open the Xpediter Perspective To open the Compuware Xpediter/Eclipse perspective Do one of the following: From the Compuware menu, select Xpediter. From the Window menu, select Open Perspective> Xpediter. The Xpediter perspective appears.

3 Xpediter/Eclipse Preferences The Xpediter Preferences dialog box is used to do the following: Select load modules to be launched for the next debug session. Configure SlickEdit as the Xpediter/Eclipse debug editor. Enable hover functionality. Enable Xpediter/TSO exit breakpoints. Close Compuware source listings after debug session termination. Show system modules in the call stack for Batch and TSO, CICS, DB2 Stored Procedures, and IMS MPP. Change the monitor buffer size

4 Cheat Sheets Cheat sheets, which outline the steps users need to take to accomplish a specific task (such as create launch configurations), are available for particular Xpediter/Eclipse functionality. To open a cheat sheet From the Help menu, select Cheat Sheets. The Cheat Sheet Selection dialog box appears. Toggle open the Compuware node. Toggle open the appropriate Compuware product node. 4. Select a cheat sheet from the list. 5. Click OK. The selected cheat sheet appears.

5 Debugging in Xpediter/Eclipse Xpediter/Eclipse is used to debug mainframe applications within an Eclipse-based workbench (for example, Topaz Workbench, Eclipse, or RDz). Xpediter/Eclipse provides several types of debug launch configurations. Click the appropriate link below for instructions on creating a debug launch configuration: Xpediter Batch launch configuration Xpediter TSO launch configuration Xpediter CICS launch configuration Xpediter DB2 SP launch configuration Xpediter IMS MPP launch configuration Note: Xpediter/Eclipse does not support Compuware Shared Services enhanced listings. For information on enhanced listings, refer to the Compuware Shared Services documentation. Related Topics Collecting Data for Topaz for Total Test Breakpoints and the Breakpoints View Variables and the Variables View Registers and the Registers View Memory and the Memory View CICS Channels and Containers view Exit with Abend and Abend-AID Report

6 Select the Xpediter/Eclipse Debug Editor Users can choose either SlickEdit or the Xpediter/Editor as the debug editor. SlickEdit is the default debug editor. To select the Xpediter/Eclipse debug editor From the Window menu, select Preferences. Toggle open the Compuware node and select Xpediter. From the Editor drop-down list, select either Compuware Editor powered by SlickEdit or Xpediter Editor. Note: When SlickEdit is selected as the debug editor, the Outline view displays by default in a new workspace. If you are upgrading from a previous Topaz Workbench release, from the Window menu, select Show View>Other. The Show View dialog box appears. Toggle open the General node and select Outline to enable the Outline view. Refer to the SlickEdit help for information on the Outline view.

7 Collecting Data for Topaz for Total Test Topaz for Total Test is a unit testing product that uses Xpediter to collect unit test data. Topaz for Total Test is flexible: users can create a unit test for an individual COBOL sub-program or they can stub out a COBOL sub-program from the main program. Topaz for Total Test takes information from Xpediter, generates the unit test case, and formats the data collected so it can be used by the test cases. Xpediter provides a method to stub out parts of the program to allow more isolated testing. Refer to the Topaz Workbench Topaz for Total Test User Guide for information on using Topaz for Total Test. Note: Topaz for Total Test works with COBOL batch programs.

8 Xpediter Batch Launch Configurations To create an Xpediter Batch launch configuration from Xpediter/Eclipse From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. This dialog box contains a tree view of configuration types (such as Xpediter Batch Debug Session ) and their corresponding configurations. Note: Alternatively, a launch configuration can be created from Host Explorer. In the left pane, select Xpediter Batch Debug Session. Click or right-click the node and select New. A child node representing the newly created configuration is added to the Xpediter Batch Debug Session root node. Note: Alternatively, you can share launch configurations by exporting from one workspace and importing into another workspace. 4. Enter in the Name field a name for the new configuration. The default name is New_configuration. 5. Complete the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) Log (Optional) Work Files (Optional) Note: To use Batch debugging with Xpediter/Eclipse, the Xpediter Multi-Batch Facility must be installed and active. Contact your system installer for assistance if needed. Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To create an Xpediter Batch launch configuration from Host Explorer Do any of the following: Right-click a JCL member in the navigation tree and select Debug As>Xpediter Batch Debug Session. Right-click a JCL member in the Contents view and select Debug As>Xpediter Batch Debug Session. With the JCL member open in an editor, right-click and select Debug As>Xpediter Batch Debug Session. Select a JCL member and, from the Run menu, select Debug As>Xpediter Batch Debug Session. Select a JCL member and, from the list, select Debug As>Xpediter Batch Debug Session. The Select Debug Configuration dialog box appears, showing all previous launch configurations of this type. Note: If there are no previous launch configurations that use this JCL, the Debug Configurations dialog box appears, pre-populated with information for a selected JCL member. The default launch configuration name is <JCL member name>. Skip to step

9 Note: If the parse is unsuccessful, the data is not populated. Note: The toolbar and right-click functionality available for a configuration is described in the right pane when a configuration type is selected. Select Create a new configuration and click Open. The Debug Configurations dialog box appears, prepopulated with information for a selected JCL member. The default launch configuration name is <JCL member name>. Complete any additional information on the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Compuware Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) Log (Optional) Work Files (Optional) Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To open an existing launch configuration In Host Explorer, do any of the following: Right-click a JCL member in the navigation tree and select Debug As>Xpediter Batch Debug Session. Right-click a JCL member in the Contents view and select Debug As>Xpediter Batch Debug Session. With the JCL member open in an editor, right-click and select Debug As>Xpediter Batch Debug Session. Select a JCL member and, from the Run menu, select Debug As>Xpediter Batch Debug Session. Select a JCL member and, from the list, select Debug As>Xpediter Batch Debug Session. The Select Debug Configuration dialog box appears, showing all existing launch configurations of this type that use the selected JCL member. Note: If there are no previous launch configurations that use this JCL, the Debug Configurations dialog box appears, pre-populated with information for a selected JCL member, so a new launch configuration can be created. Continue the process of creating a new launch configuration by completing the tabs used to define the launch configuration as described above. The default launch configuration name is <JCL member name>. Select Use an existing configuration, select the launch configuration from the list, and click Open. The Debug Configurations dialog box appears. Alternatively, prior launched debug sessions that use a particular configuration can be re-launched using the list menu of the Debug toolbar button on the Xpediter or Host Explorer perspective and selecting the configuration. To launch a debug session

10 Do one of the following: Right-click a JCL member in the navigation tree and select Debug As and select the desired debug configuration. Note: The five most recently used debug configurations with the same dataset name and host are available from the Debug As submenu. Right-click a JCL member in the navigation tree and select Debug As>Xpediter Batch Debug Session. The Select Debug Configuration dialog box appears, showing all previous launch configurations of this type that use the JCL member. Select the debug configuration to be run and click Debug. From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. Select a batch configuration to use for the debug session. Click Debug. The debug session runs. Note: Upon launching a Batch debug session, users are prompted for the user ID and password for the system running the session. Note: The user ID and password for a given system are stored in memory for that system as long as Topaz Workbench is running. When they are closed, user IDs and passwords are released from memory. Note: When a debug session is prepared, the source of the target program displays with the execution pointer stopped at the first line of executable code. Views in a Batch session The Console view shows the current status of the debug session. For instance, messages display when attempting to connect to the mainframe, upon connection, and when the job specified in the debug launch configuration is submitted (Batch session). The Memory view displays the values in memory and allows users to edit them during a debug session. The Open DDIO view allows users to browse source listing files and set breakpoints during a debug session. The Debug view provides information about the debug session as well as controls for forwarding progress of the debug session. The Variables view allows users to view and edit variable names, types, and values during a debug session. Displaying the Xpediter Log The Log tab in a Batch or TSO launch configuration contains an option to display the log at the end of each debug session. When this option is enabled, the log appears when the debug session terminates and the Console tab displays a message signaling the end of your session.

11 Target tab for Batch The Target tab of a Batch configuration allows you to define the Batch job location, the job match criteria, the test type, the target system, and the login credentials for your debug session. Multiple steps can be debugged. All fields on this tab are required. The Target tab can be completed using Autofill to automatically populate the job name and steps/programs from the JCL or by entering this information manually. Note: Multiple-step debugging functionality requires that the HCI and Xpediter/TSO be at the same API level as Topaz Workbench. Otherwise only one step will be debugged. To use Autofill to complete the Target tab for Batch Autofill allows users to automatically populate the job name and steps/programs from the JCL, From the Target system group box's Host connection list, select the host connection on which to run the debug session. From the Login Credentials list, select one of the following: Select Use saved credentials to use the credentials used to log into the selected host. Note: If your site has chosen to disallow stored credentials, this selection has no effect. Select Prompt for login to be prompted to log in when you attempt to launch the debug session on the selected host. In the Job to Debug group box, specify the dataset and member of the JCL (batch job) that executes the program you want to debug. Click Browse to navigate to the dataset. Note: When the Dataset(member) field is populated, clicking View opens the JCL in a separate window so the user can copy data from it to the Target tab. 4. In the Debug Criteria group box, click Autofill to populate the job name and steps/programs from the JCL. Click here if an error message box appears regarding the JCL containing PROCs. Notes: Steps that cannot be debugged do not appear in the Steps/programs box. The Debug Criteria group box lists the criteria of the steps/programs to be debugged. The DB2/IMS column indicates the testing of DB2 batch jobs (using DSN connect) and IMS batch jobs (executing the IMS pre-preprocessor). The Created By column indicates whether the source of the debug criteria is parsed JCL or user-entered. 5. Click Apply or, when ready to debug, click Debug. The selected step is debugged. If multiple steps were selected for debugging, the first step intercepted is debugged until it ends. At that point, either the next step is intercepted or the batch job terminates and the session ends. Notes: The LIBRARY keyword of the DSN command (used in DB2 Batch programs that call IKJEFT01 to establish a connection to DB2) is not supported. If your program name is in the library indicated by the LIB keyword, that library must be specified in your JCL JOBLIB, STEPLIB, or in the batch launch configuration Load Libraries tab. Click Revert at any time to revert to the last saved state. Autofill settings can be exported so they can be shared with others or be imported when

12 configuring a new workspace. To manually complete the Target tab for Batch From the Target System group box's Host connection list, select the host connection on which to run the debug session. From the Login Credentials list, select one of the following: Select Use saved credentials to use the credentials used to log into the selected host. Note: If your site has chosen to disallow stored credentials, this selection has no effect. Select Prompt for login to be prompted to log in when you attempt to launch the debug session on the selected host. In the Job to Debug group box, specify the dataset and member of the JCL (batch job) that executes the program you want to debug. Click Browse to navigate to the dataset. Note: When the Dataset(member) field is populated, clicking View opens the JCL in a separate window so the user can copy data from it to the Target tab. 4. In the Debug Criteria group box, follow the steps below to specify the job name, step name(s), and program name(s) defined in the JCL for the program(s) you want to debug. Multiple steps can be debugged within the session. Note: The Debug Criteria group box lists the criteria of the steps/programs to be debugged. The DB2/IMS column indicates the testing of DB2 batch jobs (using DSN connect) and IMS batch jobs (executing the IMS pre-preprocessor). The Created By column indicates whether the source of the debug criteria is parsed JCL or user-entered. 5. In the Job name field, specify the job name of the JCL dataset member being submitted. Xpediter uses this job name to intercept this job for testing. Click Add to add a step/program to debug. The Add dialog box appears. In the Step field, specify the name of a step for Xpediter to intercept. If the JCL contains PROCS, the Step field should contain the PROCSTEP to intercept. In the Program field, specify the name of a program for Xpediter intercept. Select one or both of the DB2 or IMS check boxes. The DB2 and IMS check boxes indicate the testing of DB2 batch jobs (using DSN connect) and IMS batch jobs (executing the IMS prepreprocessor). By default these check boxes are cleared. Since a DB2 DSN batch job typically executes PGM=IKJEFT01 and an IMS batch job usually executes PGM=DFSRRC00, selecting the check boxes instructs Xpediter to intercept these programs and to subsequently debug the program specified in the Program Name field. Further, when either check box is selected, the Program Name field must contain the full name of the application program to be invoked in the DB2 or IMS environment; no generics or wildcards are allowed. Click OK. The criteria is added to the Target tab. Repeat until each step to be debugged appears in the table. Notes: Any of these fields can be wild-carded, but cannot all be completely wildcarded. If there is a multi-batch request from ISPF in the file that matches the specified user ID, job name, step name, and program name, the multi-batch request from ISPF takes precedence. An example indication of this condition would be a repetitive "Waiting for Xpediter debug session..." messages.

13 6. Select or clear the Debug all steps that match the specified criteria check box. Selecting it causes all steps that match the debug criteria to be debugged. Clearing it causes only the step with a check mark to be debugged. 7. Click Apply or, when ready to debug, click Debug. The selected step is debugged. If multiple steps were selected for debugging, the first step intercepted is debugged until it ends. At that point, either the next step is intercepted or the batch job terminates and the session ends. Note: The LIBRARY keyword of the DSN command (used in DB2 Batch programs that call IKJEFT01 to establish a connection to DB2) is not supported. If your program name is in the library indicated by the LIB keyword, that library must be specified in your JCL JOBLIB, STEPLIB, or in the batch launch configuration Load Libraries tab. Note: Click Revert at any time to revert to the last saved state. To address an error message regarding the JCL containing PROCs If the JCL contains PROCs but does not specify their location, location information must be specified on the Autofill page of the Preferences dialog box. Before Autofill functionality can be used, follow the appropriate steps below, depending on whether the PROC libraries have previously been added to the preferences. If the PROC libraries have not previously been added to the preferences If the PROC libraries have not previously been added to the preferences and a message indicates that the PROC was not found, follow the steps below. Close the Debug Configurations dialog box. From the Windows menu, select Preferences>Compuware>Xpediter>Autofill Preferences dialog box appears.. The Autofill page of the Click Add to open the Add Datasets dialog box on which to type the PROC libraries to be used to resolve the JCL PROCs during the autofill operation. Optionally, do any of the following: Click Browse to open the Dataset Selection dialog box on which to browse for datasets to select for populating the Autofill page. Select a PROC library and click Edit to edit its name. Select a PROC library and click Move Up or Move Down to change its location in the input order. Select a PROC library and click Remove to remove it from the list. 4. If desired, click Validate to verify that the datasets exist. A failure message appears if validation errors exist. Reasons for validation failure include the following: The dataset is not found. The dataset is migrated. The user does not have authority to the dataset. 5. Address any validation failures. 6. Click OK on the Autofill page.

14 7. Restart the procedure above for using Autofill to complete the Target tab for Batch. If the PROC libraries have already been added to the preferences If the PROC libraries have already been added to the preferences yet a message indicates that autofill validation failed, follow the steps below. On the Autofill Validation Failed dialog box that appears, click the Configure Proc Libraries for Autofill link. The Autofill page of the Preferences dialog box appears. Click Add to open the Add Datasets dialog box on which to type the PROC libraries to be used to resolve the JCL PROCs during the autofill operation. Optionally, do any of the following: Click Browse to open the Dataset Selection dialog box on which to browse for datasets to select for populating the Autofill page. Select a PROC library and click Edit to edit its name. Select a PROC library and click Move Up or Move Down to change its location in the input order. Select a PROC library and click Remove to remove it from the list. If desired, click Validate to verify that the datasets exist. A failure message appears if validation errors exist. Reasons for validation failure include the following: The dataset is not found. The dataset is migrated. The user does not have authority to the dataset. 4. Address any validation failures. 5. Click OK on the Autofill page. 6. On the Autofill Validation Failed dialog box, click one of the following: To retry the autofill operation, click Retry. The Debug Criteria group box populates with the job name and steps/programs from the JCL. To continue with the autofill operation but ignore validation errors, click Continue. 7. On the Target tab, click Apply or, when ready to debug, click Debug. The selected step is debugged. If multiple steps were selected for debugging, the first step intercepted is debugged until it ends. At that point, either the next step is intercepted or the batch job terminates and the session ends. To share autofill settings Autofill settings can be exported so they can be shared with others or be imported when configuring a new workspace. From the Export Compuware Configuration dialog box, export the autofill settings by selecting Xpediter>Autofill and completing the remainder of the dialog box. Refer to the Topaz Workbench User Guide online help for details on using this dialog box.

15 From the Import Compuware Configuration dialog box, import the autofill settings by selecting Xpediter>Autofill and completing the remainder of the dialog box. Refer to the Topaz Workbench User Guide online help for details on using this dialog box. To edit a step/program from the Debug Criteria group box In the Debug Criteria group box, select the row for the step/program to be edited. Click Edit. The Edit dialog box appears. Make the necessary changes and click OK. The changes are reflected on the Target tab. To remove steps/programs from the Debug Criteria group box In the Debug Criteria group box, do one of the following: Select the check boxes for any steps to be removed and click Remove. Select Remove All. The changes are reflected on the Target tab.

16 Code Coverage tab An Xpediter session can optionally be code covered using Xpediter/Code Coverage. Xpediter captures information about the test, including tracking which verbs and branches were taken. Reports can also be generated from Xpediter/Code Coverage. Mainframe reporting can be selected from the Xpediter/Code Coverage option from the Xpediter/TSO primary menu. Code Coverage results can be displayed in the Topaz Workbench Code Coverage perspective. To complete the Code Coverage tab Select the Collect Code Coverage check box to activate standard Code Coverage. When selected, the Repository, System, and Test ID fields are enabled. The default for this check box is cleared. From the Repository list, specify the dataset where Xpediter will write coverage information. This repository can then be used when creating a code coverage report request in the Topaz Workbench Code Coverage perspective.. From the System name list, type, select from the list, or browse to the system name for this test. When browsing, the Browse Repository dialog box appears. Select the system from the list. Code Coverage keeps statistics by programs separate by system name. This name can be any user-specified name. 4. From the Test ID list, type, select from the list, or browse to the test identification to be added to the Code Coverage test. When browsing, the Browse Repository dialog box appears. Select the test ID from the list. This information can be useful when reviewing test reports from Xpediter/Code Coverage. 5. Select the Clear existing statistics before starting the debug session check box to remove any data from previous code coverage collections for the selected repository, system, and test ID before executing the launch configuration. 6. Select the Display a report after the debug session check box to display a Code Coverage report when the debug session ends or is terminated. 7. Toggle open Test Data Optimization to show the fields below. This section is disabled if the Collect Code Coverage check box is not selected. 8. Select the Enable Test Data Optimization (TDO) check box to enable Test Data Optimization (TDO) for a test. TDO information can only be collected during an Xpediter/TSO or Xpediter/IMS test for a program with Code Coverage active. The TDO Dataset group box becomes active for entry when this check box is selected. The default for this check box is cleared. 9. In the TDO dataset field, specify the name of the dataset to be created or deleted, or click Browse to navigate to it. The name can be qualified with quotes or be unqualified. An unqualified name appears with your user ID as a prefix. Ensure that your site s Code Coverage users have write access to the specified dataset. If this field is left blank, Xpediter generates a DSNAME in the form userid.xptdo.mmmdd.thhmmss where, mmm is the three-character month, dd is the current date, hhmmss is the current time of day, in hours, minutes, seconds. 10. In the Data class field, specify the desired SMS management class. Only use this optional field or the Storage class field when creating an SMS-managed dataset. When you use this field, leave the Volume and Unit fields blank. The appropriate values for those fields will be assigned by the system. 1 In the Storage class field, specify the desired SMS storage class. Only use this optional field when creating an

17 SMS-managed dataset. When you use this field, leave the Volume and Unit fields blank. The appropriate values for those parameters will be assigned by the system. 1 From the Space units list, specify the primary space units for the dataset. A value must be entered when any dataset is created or deleted. Valid values are cylinders (CYL) and tracks (TRK). 1 In the Unit field specify the generic unit name on which to allocate the TDO dataset. If you specify a unit name, a sequential dataset will be dynamically allocated to a volume on that unit. 14. In the Primary field, specify the number of primary space units to be allocated for the TDO dataset. A valid space unit value must be entered when any TDO dataset is created. 15. In the Volume field, specify the volume serial number on which to allocate the TDO dataset. You can also specify a generic unit name. Only use this optional field when creating a non-sms dataset. If you use the Storage Class field when creating an SMS-managed dataset, leave this field blank so that the system assigns the appropriate value. 16. In the Secondary field, specify the number of primary space units to be allocated for the dataset. A valid space unit value must be entered when any repository dataset is created. 17. In the Before test list, select APPEND to append data to the end of the existing TDO dataset or select DELETE to delete the existing TDO dataset and reallocate it.

18 Breakpoints Tab The purpose of the breakpoints tab is to specify the load modules to be loaded into memory at the start of a debug session so that existing breakpoints can automatically be set at that time. Processing and managing breakpoints Breakpoints are retained (or persisted) between debug sessions. Because of this, there are some points to be considered regarding how and when breakpoints are set, how to manage breakpoints, and so on. Breakpoints can be managed (enabled, disabled, removed, and so on.) via the Breakpoints view. Once a breakpoint is created, that breakpoint exists until it is removed. Breakpoints can then automatically be loaded upon session start, but only if its associated load module is first loaded into memory. Otherwise, existing breakpoints are ignored during a debug session unless the associated load module is loaded manually. To load modules into memory upon session start To specify the load modules that are loaded into memory upon starting a debug session, the following options exist: Load all modules: This default option loads all modules into memory that have associated enabled breakpoints upon session start. A status message detailing whether a module was successfully loaded into memory appears in the Console view. If a module could not be loaded, the breakpoints within that module are skipped. Load the main module only: This option only loads the main module into memory at session start. Enabled breakpoints within the main module are set. All other breakpoints are skipped. Specify the modules to load: This option provides a checklist of modules that currently have associated enabled breakpoints. All enabled breakpoints within the checked modules are set at session start. All other breakpoints are ignored. Note that the main module is always be loaded into memory regardless of whether it is displayed or checked. Considerations Loading modules other than the main module should be done with caution. Please be aware of the following before choosing to load such modules into memory: Memory limitations with your program s address space Possible module conflicts between multiple load libraries Code Coverage activation of modules that get loaded into your program s address space Related Topics Breakpoints and the Breakpoints View

19 Scripting tab for Batch The Scripting tab of a batch configuration allows you to define an initial script to use with your session. To complete the Scripting tab for Batch In the Initial Script field, specify the dataset member containing your script. Using an initial script is optional. In the Include Datasets group box, specify any include datasets that may contain your script. Optionally, use the Dataset List Utility to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Note: Only the following commands are supported when using initial scripts in Xpediter/Eclipse: INTERCEPT SET SHOW

20 Load Libraries tab for Batch The Load Libraries tab of a Batch configuration allows you to define the load libraries that will be concatenated to the STEPLIB DD in your JCL. To complete the Load Libraries tab for Batch Use this tab to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Entering load libraries for a Batch session is optional. Note: Supply load libraries only if the STEPLIB DD in your JCL does not contain the programs to be run in this test. Note: When performing a DB2 test and the DB2 load libraries are not in the JCL being used for the test, specify the load libraries on the Load Libraries tab.

21 DDIO tab Multiple methods exist for defining the source listing files to be included in the debug session. The simplest way is to set up DDIO rules so DDIO members are automatically found, as described in the Xpediter/TSO and Xpediter/IMS Installation and Configuration Guide's section about using the run-time parameter CTLASSD. If this is not set up at your site, an error message will indicate that no DDIO was found when the debug session is launched. If that occurs, use one of the following methods to define the source listing to be included in the debug session. Compile the program to be debugged with Compuware Shared Services 8.6 or later, which places a reference to the DDIO dataset inside of the load module so discovery is automatic. Note, however, that if the DDIO member is promoted to a different DDIO dataset, this pointer is no longer valid. Refer to the Compuware Shared Services documentation for details. Use the DDIO tab of the Debug Configurations dialog box to define the source listing files to be included in the debug session by browsing for datasets; adding, editing, or removing datasets; and changing the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Note: Xpediter/Eclipse does not support Compuware Shared Services enhanced listings. For information on enhanced listings, refer to the Compuware Shared Services documentation.

22 Log tab for Batch The Log tab allows you to define the Xpediter log dataset options for your session. To complete the Log tab for Batch Select or clear the Display the log after each debug session check box depending on whether you want a log of session action to appear upon conclusion of the debug session. In the Log Dataset Options group box, do the following: Select the Use default DSN of userid.xplog.mondd.thhmmss check box or clear this check box and enter the dataset name to use. To print to the DSN specified above, clear the Delete and print log dataset at end of debug session check box. To print to a SYSOUT class, select the Delete and print log dataset at end of debug session check box and select the SYSOUT class from the Print to SYSOUT class drop-down list ; the log dataset will be deleted at the end of the debug session. In the Log Dataset Allocation group box, select the allocation parameters to use when creating the log: Space units - The default is TRK. Primary - The default is 5. Secondary - The default it 5. Unit - The default is SYSDA. Volume Data class Storage class 4. Click Apply.

23 Work Files tab for Batch Use the Work Files tab to define the allocation parameters to use for Xpediter TSO work files on the mainframe.

24 Dataset Selection Dialog Box The Dataset Selection dialog box allows you to browse for datasets or members to populate a field in another dialog box. It is used in many dialog boxes in Topaz Workbench, such as the Debug Configurations dialog box and the Preprocessor Compile Common Settings dialog box. To browse for datasets or members From the originating dialog box, click Browse. The Dataset Selection dialog box appears. From the Host drop-down list, select the appropriate host. If the filter was not prepopulated from the originating dialog box, enter a dataset filter in the Name field, then click List. The datasets that match the filter populate the listbox. 4. Optionally, click a dataset type icon (such as PDS or Sequential) to restrict the list to just that type of datasets. 5. To make a selection to populate the originating dialog box, do either of the following: To use a dataset name, from the Datasets box, select the dataset(s) to use. To use a member name, from the Members list, select the member to use. Note: To view the contents of a member, select the member and click View. The contents of the member appear in a separate window. 6. Click OK.

25 Xpediter TSO Launch Configurations To create an Xpediter TSO launch configuration From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. This dialog box contains a tree view of configuration types (such as Xpediter Batch Debug Session ) and their corresponding configurations. Note: The toolbar and right-click functionality available for a configuration is described in the right pane when a configuration type is selected. Select the Xpediter TSO Debug Session root node from the Debug Configurations dialog box. Click or right-click the node and select New. A child node representing the newly created configuration is added to the Xpediter TSO Debug Session root node. Note: Alternatively, you can share launch configurations by exporting from one workspace and importing into another workspace. 4. Enter in the Name field a name for the new configuration. The default name is New_configuration. 5. Complete the tabs beneath the Name field, which are used to define information for a selected launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) User Files (Optional) Log (Optional) Work Files (Optional) Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To open a debug session From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. Select the configuration listed under the particular type of debug session. Click Debug. The Debug button is disabled when a selected configuration contains invalid data. To launch a debug session From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears.

26 Select a TSO configuration to use for the debug session. Click Debug. Upon launching a debug session, users are prompted for the user ID and password for the system running the session. Note: The user ID and password for a given system are stored in memory for that system as long as Topaz Workbench is running. When they are closed, user IDs and passwords are released from memory. Note: When a debug session is prepared, the source of the target program displays with the execution pointer stopped at the first line of executable code. The debug session runs. Views in a TSO session The Console view shows the current status of the debug session. The Memory view displays the values in memory and allows users to edit them during a debug session. The Open DDIO view allows users to browse source listing files and set breakpoints during a debug session. The Debug view provides information about the debug session as well as controls for forwarding progress of the debug session. The Variables view allows users to view and edit variable names, types, and values during a debug session. Displaying the Xpediter Log The Log tab in a TSO launch configuration contains an option to display the log at the end of each debug session. When this option is enabled, the log appears when the debug session terminates and the Console tab displays a message signaling the end of your session.

27 Target tab for TSO The Target tab of a TSO configuration allows you to define the program, TSO logon parameters, and the connection for your debug session. To complete the Target tab for TSO From the Target System box's Host connection list, select the host connection on which to run the debug session. From the TSO system list, select the TSO system on which to run the debug session. From the Login Credentials list, select one of the following: Select Use saved credentials to use the credentials used to log into the selected host. Note: If your site has chosen to disallow stored credentials, this selection has no effect. Select Prompt for login to be prompted to log in when you attempt to launch the debug session on the selected host. 4. In the Program to Debug group box, specify the program name and parameters of the program you want to debug. 5. In the TSO Logon Parameters group box, specify the procedure, accounting information, and region size for logging onto TSO to debug. The Accounting info field defaults to DEFAULT and the Region size field defaults to Click Apply or, when ready to debug, click Debug.

28 Scripting tab for TSO The Scripting tab of a TSO configuration allows you to define an initial script to use with your session. To complete the Scripting tab for TSO In the Initial Script field, specify the dataset member containing your script. Using an initial script is optional. In the Include Datasets group box, specify any include datasets that may contain your script. Optionally, use the Dataset List Utility to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Note: Only the following commands are supported when using initial scripts in Xpediter/Eclipse: INTERCEPT SET SHOW

29 Load Libraries tab for TSO The Load Libraries tab of a TSO configuration allows you to define the load libraries to be concatenated to the STEPLIB DD in your JCL. To complete the Target tab for TSO Use this tab to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. A TSO configuration requires at least one load library to be defined. If the program is linked with LE, the LE runtime library is needed in this LOADLIB list. If the program is linked with a COBOL runtime library, then either the LE runtime library or the COBOL runtime Library must be included. Due to duplicate module names within the LE and COBOL libraries, both these libraries should not be included at the same time. Note: Supply load libraries only if the STEPLIB DD in your JCL does not contain the programs to be run in this test.

30 Log tab for TSO The Log tab allows you to define the Xpediter log dataset options for your session. To complete the Log tab for TSO Select or clear the Display the log after each debug session check box depending on whether you want a log of session action to appear upon conclusion of the debug session. In the Log Dataset Options group box, do the following: Select the Use default DSN of userid.xplog.mondd.thhmmss check box or clear this check box and enter the dataset name to use. To print to the DSN specified above, clear the Delete and print log dataset at end of debug session check box. To print to a SYSOUT class, select the Delete and print log dataset at end of debug session check box and select the SYSOUT class from the Print to SYSOUT class dropdown list ; the log dataset will be deleted at the end of the debug session. In the Log Dataset Allocation group box, select the allocation parameters to use when creating the log: Space units - The default is TRK. Primary - The default is 5. Secondary - The default it 5. Unit - The default is SYSDA. Volume Data class Storage class 4. Click Apply.

31 User Files tab The Users Files tab of a TSO configuration allows you to define input and output files for your program. The User Files tab provides push button functionality to add, edit, duplicate, remove, move up, and move down specified user files within the table. When you click Add or select a dataset and click Edit or Duplicate, the File Specifications dialog box appears. On the File Specifications dialog box, you must specify the DD name of the file as well as whether it is a SYSOUT or a Dataset/Member. If the SYSOUT check box is selected, the Class list box must be set to SYSOUT. If the Dataset/Member check box is selected, the disposition Status list box must be specified. If you select a Status of NEW, then the SMS, Allocation Units, and DCB Information groups become active. The Duplicate button opens the File Specifications dialog box with the same information as the file selected. You can then edit the information and click OK to create a new entry in the table. Note: User files in the table cannot have the same DD name and dataset name. When you select a file and click Remove on the User Files tab, the selected file will be deleted. When you select a file and click Move Up, the selected file will switch positions in the table with the file above it. When you select a file and click Move Down, the selected file will switch positions in the table with the file below it. The buttons become enabled and disabled depending on the current selection in the table.

32 Work Files tab for TSO Use the Work Files tab to define the allocation parameters to use for Xpediter TSO work files on the mainframe.

33 Xpediter CICS Launch Configurations To create a new Xpediter CICS launch configuration From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. This dialog box contains a tree view of configuration types (such as Xpediter Batch Debug Session ) and their corresponding configurations. Note: The toolbar and right-click functionality available for a configuration is described in the right pane when a configuration type is selected. In the left pane, select Xpediter CICS Debug Session. Click or right-click the node and select New. A child node representing the newly created configuration is added to the Xpediter CICS Debug Session root node. Note: Alternatively, you can share launch configurations by copying the files from one workspace to another. 4. Enter in the Name field a name for the new configuration. The default name is New_configuration. 5. Complete the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Traps Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To open a debug session From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. Select the configuration listed under the particular type of debug session. Click Debug. The Debug button is disabled when a selected configuration contains invalid data. To launch a debug session From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. Select a CICS configuration to use for the debug session Click Debug. Upon launching a CICS debug session, users are prompted for the user ID and password for the region running the session. When a debug session begins, a source view of the target program defined in the load module of the launch configuration is shown.

34 Note: The user ID and password for a given region are stored in memory for that system as long as Eclipse is running. When Eclipse is closed, user IDs and passwords are released from memory. Note: When a debug session is prepared, the source of the target program displays with the execution pointer stopped at the first line of executable code. Note: Unlike a Batch or TSO debug session, execution begins upon the launch of a CICS session. The transaction that executes the program to be debugged must be executed by an appropriate means outside of Xpediter/Eclipse. Once executed, Xpediter/Eclipse traps the transaction and debugging begins. Views in a CICS session The Console view shows the current status of the debug session (such as messages when attempting to connect to the mainframe and when the debug session ends). The CICS Channels and Containers view allows users to view a list of channels and containers, as well as to preview and browse data, when debugging a CICS transaction that involves container data The Debug view provides information about the debug session as well as controls for forwarding progress of the debug session. The CICS Traps view provides information about the current trap criteria set for the active CICS debug session. The Memory view displays the values in memory and allows users to edit them during a debug session. The Open DDIO view allows users to browse source listing files and set breakpoints during a debug session. The Variables view allows users to view and edit variable names, types, and values during a debug session.

35 Configuration of an Xpediter Launch Configuration from a Fix Request Import Users can import a performance problem fix request file that was exported from istrobe or an abend fix request file that was exported from Abend-AID. From this imported fix request file, an Xpediter launch configuration can be created. Once the Xpediter launch configuration artifact is created, additional configuration is required to make the configuration usable in Xpediter. Note: Refer to the Topaz Workbench User Guide help for information on importing a fix request. Refer to the istrobe online help for information on exporting a fix request from istrobe. Refer to the Abend-AID Web Browser Interface help for information on exporting a fix request from Abend-AID. To complete configuration of an Xpediter launch configuration created by importing a fix request After importing a fix request to create an Xpediter launch configuration, launch Xpediter/Eclipse. Click and select Debug Configurations. The Debug Configurations dialog box appears. Select the launch configuration created by importing the fix request. The Comments tab appears. This tab shows information that is used by the launch configuration but need not be edited. 4. Click the Target tab and fill out any required fields. Required fields are indicated by messages at the top of the tab and vary by launch configuration type. Refer to the Topaz Workbench User Guide help for information on configuring host connections, if necessary. 5. For batch, DB2 stored procedures, IMS MPP, and TSO launch configurations, click the DDIO tab and add the DDIO files if they were not prepopulated by the fix request file. Refer to the appropriate help topic for the DDIO tab. 6. Click Debug. The debug session begins.

36 Target tab for CICS The Target tab of a CICS configuration allows you to define the program you want to debug and the connection for your debug session. The load module and connection fields on this tab are required. To complete the Target tab for CICS From the Target System group box's Host connection list, select the host connection on which to run the debug session. From the Login credentials list, select one of the following: Select Use saved credentials to use the credentials used to log into the selected host. Note: If your site has chosen to disallow stored credentials, this selection has no effect. Select Prompt for login to be prompted to log in when you attempt to launch the debug session on the selected host. From the CICS region list the CICS region on which to run your debug session. 4. In the Program to Debug group box, specify the load module name and the CSECT name of the program you want to debug. If you do not specify a CSECT name, the default (the entry CSECT of the specified load module) is used. 5. Click Apply or, when ready to debug, click Debug.

37 Traps tab The Traps tab of a CICS launch configuration allows you to define the traps to be set upon startup of your Xpediter debug session. Traps define the CICS activity subject to being trapped into a debug session. Among other purposes, this tab can be used to intercept and debug a program based on values found within the CICS COMMAREA associated with a program. The Traps tab has two traps set by default: one to trap based on your 3270 terminal/emulator and one to trap based on your user ID. The CICS Traps view allows users to view the traps that have been set and to add, edit, and remove traps while a debugging session is active. Note: Traps are also used to define the CICS activity that is displayed within a Runtime Visualizer session. Refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide. Note: When debugging in CICS, you must log on to the specified region via a 3270 terminal/emulator and enter the transaction that will run your program or invoke the program by another means, such as a web application or incoming MQ message. Note: The default traps set by Xpediter/Eclipse are sufficient for most users. Add or edit traps only if the default traps are known to be insufficient. Any transactions executed in the specified region by the specified user ID are trapped by Xpediter/Eclipse. The Traps tab contains the following fields: User ID Terminal ID Netname Client IP Server IP:Port Transaction Program Abends Data These fields function as described in the following section. The Traps tab allows users to add, edit, or remove traps as well as move traps up or down within the table. Adding or Editing a Trap When you click Add, the Add CICS Trap dialog box appears. When you click Edit, the Edit CICS Trap dialog box appears. The fields on the two dialog boxes are identical. These dialogs present a number of options for you to create a specific trap you want to add to your debug session. By default, traps are set for breakpoints. Traps are set for abends only if the Trap abends that may occur check box is selected. Once you click OK, the trap is added to/edited in the table. The fields on these dialog boxes are as follows: Communications Trap this workstation s emulators: Select to trap all transactions that originate from this workstation's terminal emulators. This option assumes that the terminal emulator and Topaz Workbench execute on the same workstation (that is, that they have the same IP address). If the workstation emulator and Topaz Workbench do not run on the same workstation (which may be the case if Topaz Workbench is executing on a server) or if you are unsure whether they run on the same workstation, select Trap all communication activity instead. Selecting Trap this workstation s emulators results in the <HERE> placeholder displaying on the Traps tab's Terminal ID column. Trap all communication activity: Select to set a trap for all terminals and for non-terminal tasks.

38 Trap by terminal ID: Select to set a trap for a specific terminal, then enter any of the following: The terminal ID for which you want to set a trap An asterisk as a wildcard character NONE to set the trap for only non-terminal (asynchronous) related tasks for the TRAN/PROGRAM combination Trap by netname: Select to set a trap for a specific netname, then enter the terminal netname for which you want to set a trap. An asterisk can be used as a wildcard character. Trap non-terminal IP communications: To set a trap for non-terminal tasks only, do one of the following: Client activity>use this workstation s IP address: Select to use the current terminal s IP address for the trap. Client activity>all non-terminal client activity: Select to set the trap for all client IP addresses. Client activity>other client IP: Select and then enter the client IP address to be used for the trap. Enter the desired address in nodal format with four segments separated by periods (n.n.n.n). The value of each segment must be from 0 to 255. An asterisk can be used as a wildcard character for any of the segments but not for part of a segment. Server activity>all non-terminal server activity: Select to set a trap for all server IP addresses. Server activity>use the CICS region s IP address: Select to cause the IP address associated with this terminal to be used for the trap. Server activity>other server IP/port: IP: Select and then enter the desired server IP address in nodal format with four segments separated by periods (n.n.n.n). The value of each segment must be from 0 to 255. An asterisk can be used as a wildcard character for any of the segments but not for part of a segment. Port: Select and then enter the server port number for the trap. Enter a numeric value from 1 to Enter a zero to trap all server ports. User ID Trap user ID specified at login: Select to trap abends for the current user ID. The <LOGIN> placeholder on the Traps tab is converted to a real value when a CICS debug session is started. Trap all users: Select to trap abends for all user IDs. Trap other user ID: Select and then specify the user ID for which to trap abends. An asterisk can be used as a wildcard character. Application Trap all transactions and programs: Select to trap by transaction or program, then specify the transaction or program name. Trap by transaction/program: Select to trap by transaction or program, then specify the transaction or program name. Transaction: Specify the transaction in which breakpoints will be trapped. An asterisk can be used as a wildcard character. Program: Specify the program in which breakpoints will be trapped. An asterisk can be used as a wildcard character. Data Trap using data intercept: Select this check box to trap transaction based on the data in a transaction's COMMAREA. Data area: Select from the drop-down list either Initial COMMAREA or Current COMMAREA. The initial COMMAREA is the COMMAREA passed to the initial program in a transaction (task), while the current COMMAREA is the current COMMAREA of a transaction (tasks) when there is a transfer of control within the task Data value: Enter the data value within the COMMAREA to trap the transaction based on. For example, if the initial COMMAREA contains the characters "Commarea" in bytes 1 to 8, supplying a value of "comm' in the Data value field, a start position of 1, and an operator of "Equal" will cause the transaction to be trapped. Refer to the descriptions of the Start position and Operator fields below. Data type: Select from the drop-down list the type of data to be trapped. The available options are EBCDIC

39 (not case-sensitive), EBCDIC (case-sensitive), Hex, ASCII (not case-sensitive), and ASCII (case-sensitive). Select one of the following: Search entire data field: Select this radio button to search the entire data field. When this option is selected, the Start position field is set to * and the Operator field is set to Equal ; these are not modifiable. Specify data location: Select this radio button to search only a specific data location. Then specify the start position and operator for the search. Trap abends that may occur: Select this check box to trap abends, or clear it to bypass abend trapping. When abend trapping is bypassed, breakpoints continue to be trapped. Disabling of abend trapping allows debugging of CICS handle abend routines and Language Environment user condition handlers (UCHs). When you select a trap and click Remove on the Traps tab, the selected trap will be deleted. When you select a trap and click Move Up, the selected trap will switch positions in the table with the trap above it. When you select a trap and click Move Down, the selected trap will switch positions in the table with the trap below it. Your configuration setup is now complete and you are ready to launch your debug session. Refer to Debugging in Xpediter/Eclipse.

40 Xpediter DB2 Stored Procedure (SP) Launch Configurations To create an Xpediter DB2 Stored Procedure (SP) launch configuration from Xpediter/Eclipse From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. This dialog box contains a tree view of configuration types (such as Xpediter Batch Debug Session ) and their corresponding configurations. Note: Alternatively, a launch configuration can be created from Host Explorer. In the left pane, select Xpediter DB2 SP Debug Session. Click or right-click the node and select New. A child node representing the newly created configuration is added to the Xpediter DB2 SP Debug Session root node. Note: Alternatively, you can share launch configurations by exporting from one workspace and importing into another workspace. 4. Enter in the Name field a name for the new configuration. The default name is New_configuration. 5. Complete the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) Log (Optional) Work Files (Optional) Note: To use DB2 Stored Procedure debugging with Xpediter/Eclipse, the Xpediter Multi-Batch Facility must be installed and active. Contact your system installer for assistance if needed. Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To create an Xpediter DB2 Stored Procedure (SP) launch configuration from Host Explorer Do any of the following: Right-click a JCL member in the navigation tree and select Debug As>Xpediter DB2 SP Debug Session. Right-click a JCL member in the Contents view and select Debug As>Xpediter DB2 SP Debug Session. With the JCL member open in an editor, right-click and select Debug As>Xpediter DB2 SP Debug Session. Select a JCL member and, from the Run menu, select Debug As>Xpediter DB2 SP Debug Session. Select a JCL member and, from the list, select Debug As>Xpediter DB2 SP Debug Session. The Select Debug Configuration dialog box appears, showing all previous launch configurations of this type. Note: If there are no previous launch configurations that use this JCL, the Debug Configurations dialog box appears, pre-populated with information for a selected JCL member. The default launch configuration name is

41 <JCL member name>. Skip to step Note: If the parse is unsuccessful, the data is not populated. Note: The toolbar and right-click functionality available for a configuration is described in the right pane when a configuration type is selected. Select Create a new configuration and click Open. The Debug Configurations dialog box appears, prepopulated with information for a selected JCL member. The default launch configuration name is <JCL member name>. Complete any additional information on the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) Log (Optional) Work Files (Optional) Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To open an existing launch configuration In Host Explorer, do any of the following: Right-click a JCL member in the navigation tree and select Debug As>Xpediter DB2 SP Debug Session. Right-click a JCL member in the Contents view and select Debug As>Xpediter DB2 SP Debug Session. With the JCL member open in an editor, right-click and select Debug As>Xpediter DB2 SP Debug Session. Select a JCL member and, from the Run menu, select Debug As>Xpediter DB2 SP Debug Session. Select a JCL member and, from the list, select Debug As>Xpediter DB2 SP Debug Session. The Select Debug Configuration dialog box appears, showing all existing launch configurations of this type that use the selected JCL member. Note: If there are no previous launch configurations that use this JCL, the Debug Configurations dialog box appears, pre-populated with information for a selected JCL member, so a new launch configuration can be created. Continue the process of creating a new launch configuration by completing the tabs used to define the launch configuration as described above. The default launch configuration name is <JCL member name>. Select Use an existing configuration, select the launch configuration from the list, and click Open. The Debug Configurations dialog box appears. Alternatively, prior launched debug sessions that use a particular configuration can be re-launched using the list menu of the Debug toolbar button on the Xpediter or Host Explorer perspective and selecting the configuration.

42 To launch a debug session From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. Select a Xpediter DB2 SP debug session configuration to use for the debug session. Click Debug. Upon launching a DB2 SP debug session, users are prompted for the user ID and password for the region running the session. After the WorkLoad Manager (WLM) JCL is submitted, the message Waiting for Xpediter debug session displays in the Console view indicating that Xpediter is waiting for the DB2 stored procedure to execute. When the DB2 stored procedure specified in the launch configuration is executed and intercepted by Xpediter, the source for the program displays with the execution pointer stopped at the first executable line of code. The source code of the program specified in the DB2 SP Launch Configuration displays. Note: The user ID and password for a given system are stored in memory for that system as long as Eclipse is running. When Eclipse is closed, user IDs and passwords are released from memory. Note: When a debug session is prepared, the source of the target program displays with the execution pointer stopped at the first line of executable code. Views in a DB2 Stored Procedure session The Console view shows the current status of the debug session. For instance, messages display when attempting to connect to the mainframe, upon connection, and when the job specified in the debug launch configuration is submitted. The Debug view provides information about the debug session as well as controls for forwarding progress of the debug session. The Memory view displays the values in memory and allows users to edit them during a debug session. The Open DDIO view allows users to browse source listing files and set breakpoints during a debug session. The Variables view allows users to view and edit variable names, types, and values during a debug session. To run the DB2 Stored Procedure multiple times Xpediter/Eclipse DB2 stored procedure support allows the DB2 stored procedure specified on the launch configuration to be intercepted as many times as specified in the Maximum Number of Tests field on the Target tab of the launch configuration. Xpediter/Eclipse stops automatically at the return point of the program. Click. Xpediter/Eclipse DB2 stored procedure support waits for the DB2 stored procedure to re-execute. When the DB2 stored procedure re-executes, it is intercepted until the maximum number of tests is reached. To terminate the debugging session do either of the following: Click Click when the maximum number of tests is reached. prior to attaining the specified maximum number of tests.

43 At this point, the debugging session terminates, the Xpediter/TSO log optionally displays (if enabled on the launch configuration Log tab), and the DB2 WLM batch address space terminates. Displaying the Xpediter Log The Log tab in a DB2 SP Launch Configuration contains an option to display the log at the end of each debug session. When this option is enabled, the log appears when the debug session terminates and the Console tab displays a message signaling the end of your session.

44 Target tab for DB2 SP The Target tab of a DB2 Stored Procedure configuration defines the location of the Application Environment WorkLoad Manager (WLM) JCL, DB2 stored procedure filter criteria, and the target system for the debug session. To complete the Target tab for DB2 SP In the Target System section, specify the host connection on which to run your debug session. In the Login Credentials section, do one of the following: Select Use saved credentials to use the credentials used to log into the selected host. Note: If your site has chosen to disallow stored credentials, this selection has no effect. Select Prompt for login to be prompted to log in when you attempt to launch the debug session on the selected host. In the Application Environment (WLM JCL) section, specify the dataset, job name, member, and step name of the JCL (Batch job) that creates the WorkLoad Manager (WLM) address space. If the JCL contains PROCS, then the Step name field should contain the PROCSTEP of the program that initiates the WorkLoad Manager address space. Optionally, click Browse to navigate to the dataset. Note: When the Dataset(member) field is populated, clicking View opens the JCL in a separate window so the user can copy data from it to the Target tab. 4. In the DB2 Stored Procedure Filter Criteria section, specify the filter criteria for the DB2 stored procedure to be debugged: In the Program name field, specify the name of the program you want to debug. This name matches the name of the listing found in the Compuware listing file specified in the DDIO tab. In the Schema name field, specify the schema name associated with the stored procedure. Xpediter uses this name along with the stored procedure name to resolve the WorkLoad Manager (WLM) application environment and the load module name. The site's DB2 administrator or system support responsible for WLM should provide the schema and stored procedure names that have been defined to WLM and DB Beginning with DB2 8.1, the schema name can be up to 128 bytes long. In the Stored procedure name field, specify the stored procedure name associated with the schema name. Xpediter uses the name to resolve the WorkLoad Manager (WLM) application environment and the load module name. The site's DB2 administrator or system support responsible for WLM should provide the stored procedure's name that has been defined to WLM and DB Beginning with DB2 8.1, the stored procedure name can be up to 128 bytes long. Note: To intercept a trigger that calls a DB2 stored procedure, specify the stored procedure here. To debug a user-defined function (UDF), specify the FUNCTION name (not the SPECIFIC name). In the Client End User ID/PC Account Code/IP Address field, specify one of the following: The user ID of the client (caller of the stored procedure)

45 The account code used by the middleware (or batch job) The client's IP address (which is applicable if the requester is not a DB2 subsystem) An asterisk * (which indicates a generic wildcard match; only the subsystem and stored procedure name will be used for interception) This field cannot be blank. If this field as entered does not match the client's user ID, the account code, or IP address, and an asterisk was not entered, Xpediter will not intercept the stored procedure. If the client is CICS, enter the AUTH from the CICS DFHRCT. In the DB2 subsystem name field, specify the name of the DB2 subsystem where the stored procedure is defined. In the Maximum number of tests field, specify how many times the stored procedure will be intercepted. Note: During a test, a user can terminate the WLM address space, which will override this value and cause immediate termination of the test. To accomplish this, in the Debug view, click the configuration name and click the terminate icon. Note: If there is a multi-batch request from ISPF in the file that matches the specified user ID, job name, step name, and program name, the multi-batch request from ISPF takes precedence. An example indication of this condition is a repetitive "Waiting for Xpediter debug session..." message.

46 Scripting tab for DB2 SP The Scripting tab of a DB2 Stored Procedure configuration allows you to define an initial script to use with your session. To complete the Scripting tab for DB2 SP In the Initial Script field, specify the dataset member containing your script. Using an initial script is optional. In the Include Datasets group box, specify any include datasets that may contain your script. Optionally, use the Dataset List Utility to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Note: Only the following commands are supported when using initial scripts in Xpediter/Eclipse: INTERCEPT SET SHOW

47 Load Libraries tab DB2 SP The Load Libraries tab of a DB2 Stored Procedure configuration allows you to define the load libraries that will be concatenated to the STEPLIB DD in your JCL. To complete the Load Libraries tab for DB2 SP Use this tab to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Entering load libraries for a DB2 Stored Procedure session is optional. Note: Supply load libraries only if the STEPLIB DD in your JCL does not contain the programs to be run in this test.

48 Log tab for DB2 SP The Log tab allows you to define the Xpediter log dataset options for your session. To complete the Log tab for DB2 SP Select or clear the Display the log after each debug session check box depending on whether you want a log of session action to appear upon conclusion of the debug session. In the Log Dataset Options group box, do the following: Select the Use default DSN of userid.xplog.mondd.thhmmss check box or clear this check box and enter the dataset name to use. To print to the DSN specified above, clear the Delete and print log dataset at end of debug session check box. To print to a SYSOUT class, select the Delete and print log dataset at end of debug session check box and select the SYSOUT class from the Print to SYSOUT class dropdown list ; the log dataset will be deleted at the end of the debug session. In the Log Dataset Allocation group box, select the allocation parameters to use when creating the log: Space units - The default is TRK. Primary - The default is 5. Secondary - The default it 5. Unit - The default is SYSDA. Volume Data class Storage class 4. Click Apply.

49 Work Files tab DB2 SP Use the Work Files tab to define the allocation parameters to use for Xpediter TSO work files on the mainframe.

50 Xpediter IMS MPP Launch Configurations To create an Xpediter IMS MPP launch configuration from Xpediter/Eclipse From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. This dialog box contains a tree view of configuration types (such as Xpediter Batch Debug Session ) and their corresponding configurations. Note: Alternatively, a launch configuration can be created from Host Explorer. In the left pane, select Xpediter IMS MPP Debug Session. Click or right-click the node and select New. A child node representing the newly created configuration is added to the Xpediter IMS MPP Debug Session root node. Note: Alternatively, you can share launch configurations by exporting from one workspace and importing into another workspace. 4. Enter in the Name field a name for the new configuration. The default name is New_configuration. 5. Complete the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) Log (Optional) Work Files (Optional) Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To create an Xpediter IMS MPP launch configuration from Host Explorer Do any of the following: Right-click a JCL member in the navigation tree and select Debug As>Xpediter IMS MPP Debug Session. Right-click a JCL member in the Contents view and select Debug As>Xpediter IMS MPP Debug Session. With the JCL member open in an editor, right-click and select Debug As>Xpediter IMS MPP Debug Session. Select a JCL member and, from the Run menu, select Debug As>Xpediter IMS MPP Debug Session. Select a JCL member and, from the list, select Debug As>Xpediter IMS MPP Debug Session. The Select Debug Configuration dialog box appears, showing all previous launch configurations of this type. Note: If there are no previous launch configurations that use this JCL, the Debug Configurations dialog box appears, pre-populated with information for a selected JCL member. The default launch configuration name is <JCL member name>. Skip to step

51 Note: If the parse is unsuccessful, the data is not populated. Note: The toolbar and right-click functionality available for a configuration is described in the right pane when a configuration type is selected. Select Create a new configuration and click Open. The Debug Configurations dialog box appears, prepopulated with information for a selected JCL member. The default launch configuration name is <JCL member name>. Complete any additional information on the tabs beneath the Name field, which are used to define the launch configuration: Target Visualization (Optional) (Used to request visualization of program and I/O calls in the Runtime Visualizer perspective. For more information refer to the Topaz Workbench Program Analysis and Runtime Visualizer User Guide.) Code Coverage (Optional) Scripting (Optional) Load Libraries (Optional) DDIO (Optional) Log (Optional) Work Files (Optional) Note: An error displays at the top of the Debug Configurations dialog box any time a required field of a launch configuration is not specified or is invalid. A debug session using a configuration with errors cannot be launched. To open an existing launch configuration In Host Explorer, do any of the following: Right-click a JCL member in the navigation tree and select Debug As>Xpediter IMS MPP Debug Session. Right-click a JCL member in the Contents view and select Debug As>Xpediter IMS MPP Debug Session. With the JCL member open in an editor, right-click and select Debug As>Xpediter IMS MPP Debug Session. Select a JCL member and, from the Run menu, select Debug As>Xpediter IMS MPP Debug Session. Select a JCL member and, from the list, select Debug As>Xpediter IMS MPP Debug Session. The Select Debug Configuration dialog box appears, showing all existing launch configurations of this type that use the selected JCL member. Note: If there are no previous launch configurations that use this JCL, the Debug Configurations dialog box appears, pre-populated with information for a selected JCL member, so a new launch configuration can be created. Continue the process of creating a new launch configuration by completing the tabs used to define the launch configuration as described above. The default launch configuration name is <JCL member name>. Select Use an existing configuration, select the launch configuration from the list, and click Open. The Debug Configurations dialog box appears. Alternatively, prior launched debug sessions that use a particular configuration can be re-launched using the list menu of the Debug toolbar button on the Xpediter or Host Explorer perspective and selecting the configuration. To launch a debug session

52 From the Run menu, select Debug Configurations. The Debug Configurations dialog box appears. Select an Xpediter IMS MPP configuration to use for the debug session Click Debug. Upon launching an IMS MPP debug session, users are prompted for the user ID and password for the system running the session. After your IMS MPP job is submitted, the message Waiting for Xpediter debug session appears in the Console view, indicating that Xpediter is waiting for the IMS MPP transaction to be executed. When the IMS MPP transaction has been entered and intercepted by Xpediter, the source for the program displays and the execution pointer stops at the first executable line of code. The tab or the source view displays the load module name and the CSECT name in load module [CSECT ] format. Note: The user ID and password for a given system are stored in memory for that system as long as Topaz Workbench is running. When they are closed, user IDs and passwords are released from memory. Note: When a debug session is prepared, the source of the target program displays with the execution pointer stopped at the first line of executable code. Views in an IMS MPP session The Console view shows the current status of the debug session. For instance, messages display when attempting to connect to the mainframe, upon connection, and when the job specified in the debug launch configuration is submitted. The Debug view provides information about the debug session as well as controls for forwarding progress of the debug session. The Memory view displays the values in memory and allows users to edit them during a debug session. The Open DDIO view allows users to browse source listing files and set breakpoints during a debug session. The Variables view allows users to view and edit variable names, types, and values during a debug session. To run multiple IMS MPP transactions Xpediter/Eclipse allows multiple IMS MPP transactions to be run for any transaction criteria that is specified on the Target tab. When the IMS MPP Transaction Complete dialog box appears at the end of testing the current transaction, do either of the following: Click Yes if you want to run another transaction. The debug session remains active so you can execute another IMS transaction. Click No if you do not want to run another transaction. The Xpediter/IMS log displays (if enabled on the Launch Configuration Log tab), the debugging session terminates (as shown in the Console view), and the IMS MPP batch region terminates. Note: It is possible (but not advised) to terminate the IMS MPP debugging session by selecting the launch configuration or transaction thread and clicking. If this is done, Xpediter/IMS is unable to terminate the batch IMS MPP region and Xpediter/Eclipse issues a warning. The Console view displays the messages Xpediter/IMS is unable

53 to stop the IMS MPP batch region. Please use IMS to stop the IMS MPP batch region. To test another IMS MPP transaction using Xpediter/Eclipse, the batch IMS MPP region must manually be stopped, via IMS. Displaying the Xpediter Log The Log tab in an IMS MPP launch configuration contains an option to display the log at the end of each debug session. When this option is enabled, the log appears when the debug session terminates, and the Console tab displays a message signaling the end of your session.

54 Target tab for IMS MPP The Target tab of an IMS MPP debug configuration allows you to define the location of your IMS MPP JCL, the IMS program and transaction code, and the target system for your debug session. To complete the Target tab for IMS MPP In the Target system section's Host connection field, specify the host connection on which to run your debug session. In the Login credentials field, do one of the following: Select Use saved credentials to use the credentials used to log into the selected host. Note: If your site has chosen to disallow stored credentials, this selection has no effect. Select Prompt for login to be prompted to log in when you attempt to launch the debug session on the selected host. In the IMS MPP JCL Location section's Dataset(member) field, specify the dataset and member of the IMS MPP JCL (batch job) that creates the IMS MPP address space. Optionally click Browse to navigate to the dataset. Note: When the Dataset(member) field is populated, clicking View opens the JCL in a separate window so the user can copy data from it to the Target tab. 4. In the Debug criteria section's Job name field, specify the job name of the JCL dataset member being submitted here. This job name will be used by Xpediter/IMS to intercept this job for testing. This field cannot be wildcarded. 5. In the Step name field, specify the name of the step for Xpediter to intercept. If the JCL contains PROCS, then the Step name field should contain the PROCSTEP to intercept. This is a required field and it may be wild carded. 6. In the IMS User ID field, specify the IMS Userid that will be used to test this program/transaction. This field is used to specify the ID of the IMS user issuing the IMS transaction you want to debug and is applicable only if IMS user ID or the IMS DATA Value Driven Intercept support is enabled. A single character asterisk (*) in this field indicates a generic match (any User ID will be considered a match). This field defaults to a single asterisk (*). 7. In the Programs/transactions table, click Add. The Add dialog box appears. 8. In the Program field, specify the IMS MPP program to be tested using Xpediter/IMS. This field cannot be wildcarded. 9. In the Transaction field, specify the IMS MPP transaction to be tested using Xpediter/IMS. This field cannot be wildcarded In the Data field, optionally specify the IMS MPP data to be used by the program/transaction specified above. This field can be used in conjunction with the User ID field (if the IMS DATA Value Driven Intercept has been installed) to further restrict selection of transactions to those that contain the specified data in the transaction buffer.

55 1 Click OK. The program/transaction information is added to the Target tab. 1 Click Add to add additional programs/transactions, and repeat as necessary. Note: Multiple entries in the table with the same transaction code are disallowed (program and data fields can be duplicated). Note: To edit the program, transaction, or data information, click Edit to open the Edit dialog box. To remove a program/transaction, select it from the table and click Remove. To remove all program/transactions in the table, click Remove All. 1 In the Options section, select the Hogan test check box if you want to set a flag for Xpediter/IMS to perform a Hogan test. The Pseudo Wait For Input (PWFI) parameter in the IMS MPP region JCL determines what IMS does when there is no designated task for the IMS region. Under normal circumstances, this parameter should be specified as NO. Only specify YES for this parameter if you understand and require the IMS behavior inherent in this option. Note: If there is a multi-batch request from ISPF in the file that matches the specified user ID, job name, step name, and program name, the multi-batch request from ISPF takes precedence. An example indication of this condition is a repetitive "Waiting for Xpediter debug session..." message.

56 Scripting tab for IMS MPP The Scripting tab of an IMS MPP configuration allows you to define an initial script to use with your session. To complete the Scripting tab for IMS MPP In the Initial Script field, specify the dataset member containing your script. Using an initial script is optional. In the Include Datasets group box, specify any include datasets that may contain your script. Optionally, use the Dataset List Utility to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Note: Only the following commands are supported when using initial scripts in Xpediter/Eclipse: INTERCEPT SET SHOW

57 Load Libraries tab IMS MPP The Load Libraries tab of an IMS MPP debug configuration allows you to define the load libraries that will be concatenated to the STEPLIB DD in your JCL. To complete the Target tab for IMS MPP Use this tab to browse for datasets; add, edit, or remove datasets; and change the order in which datasets are listed. Datasets are processed in the order in which they appear in the table. Entering load libraries for an IMS MPP debug session is optional. Note: Supply load libraries only if the STEPLIB DD in your JCL does not contain the programs to be run in this test.

58 Log tab for IMS MPP The Log tab allows you to define the Xpediter log dataset options for your session. To complete the Log tab for IMS MPP Select or clear the Display the log after each debug session check box depending on whether you want a log of session action to appear upon conclusion of the debug session. In the Log Dataset Options group box, do the following: Select the Use default DSN of userid.xplog.mondd.thhmmss check box or clear this check box and enter the dataset name to use. To print to the DSN specified above, clear the Delete and print log dataset at end of debug session check box. To print to a SYSOUT class, select the Delete and print log dataset at end of debug session check box and select the SYSOUT class from the Print to SYSOUT class dropdown list ; the log dataset will be deleted at the end of the debug session. In the Log Dataset Allocation group box, select the allocation parameters to use when creating the log: Space units - The default is TRK. Primary - The default is 5. Secondary - The default it 5. Unit - The default is SYSDA. Volume Data class Storage class 4. Click Apply.

59 Work Files tab IMS MPP Use the Work Files tab to define the allocation parameters to use for Xpediter/IMS work files on the mainframe.

60 Sharing Launch Configurations Launch configurations can be imported and exported to and from the local file system. To export launch configurations From the File menu, select Export. The Export dialog box appears. Select Run/Debug>Launch Configurations and click Next. The Export Launch Configurations dialog box appears. Toggle open the launch configuration types to show the available launch configurations. 4. Select any number of individual launch configurations from the Launch Configurations list box or click Select All to select all available launch configurations. 5. In the Location field, enter a file location in which to save these selected launch configurations files, or click Browse to navigate to the location. 6. Click Finish to write these launch configurations to the selected location. To import launch configurations From the File menu, select Import to import launch configurations (to another workspace for example ). The Import dialog box appears. Select Run/Debug>Launch Configurations and click Next. The Import Launch Configurations dialog box appears. In the From Directory field, enter the file location where the launch configurations are stored on the local file system, or click Browse to navigate to the location. The selected directory and all subdirectories are listed in the left column. 4. Do any of the following: Click a directory or subdirectory name to display all of the launch configuration files (*.launch) within that directory in the right column. Individual files can be selected when displayed in the right column. Select the directory's check box to select all of the configuration files contain in that directory. 5. Click Finish.

61 Setting Preference for Load Modules to be Loaded for Debug Sessions A preference setting allows users to determine which load modules will be loaded upon launch of a debug session. This setting is used each time a new Xpediter debug configuration is created. Breakpoints associated with the selected load modules will be intercepted. Breakpoints outside of those load modules will not be loaded unless other actions are taken, such as loading the module via the context menu in the Breakpoints view. To set the default preference for loading modules related to breakpoints From the Window menu, select Preferences. The Preferences dialog box appears. Toggle open the Compuware node and select Xpediter. The Xpediter preferences page appears. Under Breakpoints, select the Retain breakpoints set during a debug session check box. 4. Select one of the following radio buttons to dictate which modules will be loaded upon launch of a debug session: Load all modules: This default option loads all modules into memory that have associated enabled breakpoints upon session start. A status message detailing whether a module was successfully loaded into memory appears in the Console view. If a module could not be loaded, the breakpoints within that module are skipped. Load the main module only: This option only loads the main module into memory at session start. Enabled breakpoints within the main module are set. All other breakpoints are skipped. Specify the modules to load: This option provides a checklist of modules that currently have associated enabled breakpoints. All enabled breakpoints within the checked modules are set at session start. All other breakpoints are ignored. Note that the main module is always be loaded into memory regardless of whether it is displayed or checked. Note: The "main" load module is always loaded. 5. Click OK.

62 Dynamic Dataset Verification Dynamic Dataset Verification ensures that the specified datasets exist and that the user has read access to them. Dataset verification takes place before the batch job is submitted either by the Compile Facility or when a debug configuration is launched. When a compile or debug session is launched, dataset verification is performed prior to submission of the JCL. If one or more of the datasets do not exist or are not accessible, an error message appears stating that condition and listing the datasets failing verification. If a dataset verification error occurs, the following options are provided in the error message: Abort -Immediately terminates the submission. Retry -Performs the verification again using the same dataset list. This option is provided to enable corrective actions to be taken while maintaining the current state of the session. Ignore -Submits the job with the datasets unchanged. The Ignore option should only be chosen when it is known that the failed condition will not be encountered or will be corrected prior to the point where it would negatively impact the function being performed.

63 Breakpoints and the Breakpoints View When a debug session is launched, an initial breakpoint is automatically set on the first line of program that was executed as specified in your launch configuration. All breakpoints set in Xpediter/Eclipse are before breakpoints. Using Breakpoints Breakpoints can be set and removed either within an active debug session or within your source before you launch a debug session. However, only new Before breakpoints can be set outside of an active session. Each breakpoint is displayed in the Breakpoints view. Breakpoints are retained after an active session ends. Methods for loading modules into memory There are two methods for loading modules into memory: Automatically load modules and set associated existing breakpoints upon session start. Load modules specified on the Breakpoints tab are loaded into memory upon session start and associated breakpoints are automatically set that time. The default is to load all load modules associated with existing breakpoints. Note: The main module is loaded at session start regardless of any settings in the Breakpoints tab. Manually load modules and set breakpoints during a debug session. Breakpoints can be set at any time during a debug session. Existing breakpoints whose load modules were excluded by the Breakpoints tab settings have disabled (dark grey) text for their associated breakpoints text in the Breakpoints view. To manually load modules and set breakpoints during a debug session These breakpoints can be enabled by loading their associated load modules in one of the following ways: Open the DDIO source listing via the Open DDIO view. Double click on the CSECT or right-click it and select Open. Right-click the breakpoint(s) in the Breakpoints view and select Load Associated Module(s). Considerations Loading modules other than the main module should be done with caution. Please be aware of the following before choosing to load such modules into memory: Memory limitations with your program s address space Possible load module conflicts between multiple load libraries Code Coverage activation of load modules that get loaded into your program s address space To group breakpoints in the Breakpoints view To group breakpoints by type (such as Before and When), click in the Breakpoints view and select Group by>breakpoint Types. To list all breakpoints in one list, click in the Breakpoints view and select Group by>breakpoints. To add or remove breakpoints Do either of the following to add or remove breakpoints:

64 Right-click the vertical ruler of a source display and select Toggle Breakpoint. Double-click the vertical ruler next to a line. The Breakpoints view shows all breakpoints that currently exist in the debug session. Note: If a breakpoint is set on a non-executable line in a CICS debug session, it is automatically placed on the next available executable line. For instance, a breakpoint set on line 1 of a program will automatically be placed at the first executable line of the program. To enable or disable breakpoints Breakpoints can be enabled and disabled. A disabled breakpoint is still considered set, but will not interrupt program execution. Do either of the following in the Breakpoints view to enable or disable breakpoints: Select (to enable) or clear (to disable) the breakpoint's check box. Right-click a breakpoint and select Enable or Disable. To enable Xpediter/TSO exit breakpoints Users can choose to display and honor Xpediter/TSO exit breakpoints or, more precisely, to emulate the functionality of Xpediter/TSO for exit breakpoints within Xpediter/Eclipse. By default, these breakpoints are not displayed or honored. To enable Xpediter/TSO exit breakpoints, from the Window menu, select Preferences>Compuware>Xpediter the Enable Xpediter/TSO exit breakpoints check box.. Select Note: Changes to this setting do not take effect until a new debug session is started. To close Compuware source listings after debug session terminates By default, Compuware source listings are closed after the debug session terminates. To instead keep source listings open, from the Window menu select Preferences>Compuware>Xpediter and clear the Close Compuware Source Listings after debug session termination check box. The Breakpoints View Toolbar The following toolbar buttons are available on the Breakpoints view toolbar. Button Description Remove Selected Breakpoint - Removes the selected breakpoints from your debug session. Remove All Breakpoints - Removes all existing breakpoints from your debug session. Go to File for Breakpoint - Points the source display of the breakpoint s associated CSECT at the line where the breakpoint is. You can achieve the same results by double-clicking on a given breakpoint in the Breakpoints view. Skip all Breakpoints - Directs Xpediter/Eclipse to bypass or ignore all breakpoints. Related Topics Breakpoints Tab When Conditions

65 Conditional Breakpoints Run To Line Set Line as Next Statement Skippoints

66 When Conditions and Conditional Breakpoints When Conditions Unlike conditional breakpoints, When conditions are not associated with a particular source line. Source statements are executed one at a time. Every defined When condition expression is evaluated after each executed source statement. While multiple When conditions can be active simultaneously, they are evaluated in the order in which they were defined. After a defined When condition is satisfied (evaluates to true), program execution halts, positioned at the last executed source statement. To create When conditions Do one of the following: From the ruler area of the source, right-click and select Set When Condition. The When Condition dialog box appears. Right-click in the Editor and select Set When Condition. The When Condition dialog box appears. Enter a When condition expression. Click OK. The When condition appears in the Breakpoints view and is evaluated when execution resumes. Note: All When conditions are examined individually after each executable statement. This can impose a substantial load on available processor resources. When Condition Syntax In its most basic form, a When condition consists of a variable and the keyword CHANGES. Another simple form consists of a variable, an operator, and a comparison value. The following table describes the basic set of operators common to both Xpediter/TSO and IMS and Xpediter/CICS. Operator Meaning < Less than = Equal to > Greater than NOT CHANGES Logical negation Variable value changes For a comprehensive list of operators supported by each product's debuggers see each product's respective user documentation. Conditional Breakpoints Conditional breakpoints are breakpoints that only stop execution once a specified condition is met. Upon encountering a source line designated with a conditional breakpoint, Xpediter/Eclipse evaluates whether the associated condition is true. If true, the breakpoint is honored and execution stops at that source line. If false, the breakpoint is ignored and

67 execution continues. To create Conditional breakpoints Do one of the following: From the ruler area of the source, right-click and select Set Conditional Breakpoint. The Conditional Breakpoint dialog box appears. Right-click in the Editor and select Set Conditional Breakpoint. The Conditional Breakpoint dialog box appears. Right-click an existing before breakpoint in the Breakpoints view and select Breakpoint Properties. The Conditional Breakpoint dialog box appears. Enter the condition to be evaluated. Click OK. The condition appears in the Breakpoints view. If you modified an existing before breakpoint, the breakpoint is modified as specified to have the condition associated with it. To disable or remove Conditional breakpoints In the Breakpoints view, select the breakpoint and click. Conditional Breakpoint Syntax The rules for syntax are exactly the same as described in either the Xpediter/CICS or Xpediter/TSO & Xpediter/IMS User Guide. In its simplest form, syntax follows the format of [variable ] [condition ] [value ]. Related Topics Skippoint Set Line as Next Statement

68 Run to Line A Run to Line breakpoint is a convenient way to resume a debugging session until program execution encounters a particular line of code. To set a Run to Line breakpoint Select the line where the program execution is to suspend. Do one of the following: Right-click and select Run to Line. From the Run menu, select Run to Line. Program execution resumes and then suspends immediately before the specified run to line is executed. Note: If the specified run to line is not in the active code path, the program will not suspend due to the Run to Line breakpoint. It could potentially run to termination, provided that execution does not encounter other breakpoints and exceptions. To skip breakpoints during a Run to Line operation Breakpoints and exceptions can result in the program suspending prior to reaching the specified run to line. To avoid this situation, before setting a Run to Line breakpoint, do the following so that breakpoints are ignored. From the Window menu, select Preferences>Run/Debug. The Run/Debug Preferences dialog box appears. Select the Skip breakpoints during a 'Run to Line' operation check box. The debugger will ignore any breakpoints it encounters during a Run to Line operation.

69 Skippoint Skippoint functionality allows users to bypass the execution of a statement in a debug session. Setting a skippoint on a line causes the line to not be executed. To set a skippoint In a debug session, right-click the line to be skipped and select Toggle Skippoint. An entry with Breakpoints view. is added to the Note: Setting a skippoint on a line that already contains a breakpoint will cause the breakpoint to be removed and the skippoint to be added. To remove a skippoint Right-click the line to be skipped and select either Toggle Skippoint or Toggle Breakpoint.

70 Set Line as Next Statement Xpediter/Eclipse allows users to force the execution pointer to a selected line, which invokes the Xpediter/TSO or Xpediter/CICS Goto functionality. To use Set Line as Next Statement functionality Place the cursor on line that you want to set as the next statement. Do one of the following: From the ruler area of the source, right-click and select Set Line as Next Statement. Right-click in the Editor and select Set Line as Next Statement. From the Run menu, select Set Line as Next Statement. Program execution resumes starting at the specified line.

71 CICS Traps view The CICS Traps view provides information about the traps set for the active CICS debug session. The CICS Traps view also allows users to add, edit, and remove traps while a debugging session is active. To access the CICS Traps view From the Window menu, select Show View>Other>Xpediter>CICS Traps. To define CICS traps Traps can be defined in two ways: Add traps using the Traps tab of the CICS launch configuration. These traps are the default traps set for each debugging session. Add traps in the CICS Traps view. These traps are active for the current debugging session only. To view CICS traps Refer to the Traps tab topic for detailed field descriptions for the CICS Traps view. Further, the CICS Traps view displays in the first column to indicate which trap caused the current breakpoint to be taken.

72 Variables and the Variables View Variable names, types, and values can be viewed and edited from the Variables view during a debug session. Since variables are tied to a stack frame, a stack frame item must be selected in the Debug view in order for Xpediter/Eclipse display variables in the Variables view. The variables in this view are updated when execution is suspended. Within the Variables view, Xpediter/Eclipse displays the variables of the current line of execution along with any variables from the previously executed line. To change the value of a variable Do either of the following: In the Variable view's Value column, select the value to be changed and type over it with the new value. In the Variable view's Value column, right-click the value and select Change Value. The Set Value dialog box appears. Enter the new value and click OK. To display hexadecimal values In the Variables view, click and select Xpediter>Display Hex Values. To show fully qualified variable names In the Variables view, click and select Xpediter>Show Qualified Variable Names. Repeat to show only the variable name, if desired. To view and update variables in vertical hexadecimal format In the Variables view, right-click a variable and select Vertical Hex Display. The Vertical Hex Display dialog box appears containing the hexadecimal value for the selected variable. To update the variable in vertical hex display Overtype the existing EBCDIC value or hexadecimal value with the new value. The corresponding hexadecimal or EBCDIC value changes automatically to match. For example, if the EBCDIC value of 2 is manually changed to a 3, the corresponding hexadecimal value changes to X F3. When the hexadecimal value is manually changed, Xpediter/Eclipse validates the newly entered characters as to whether they are legal hexadecimal characters. Note: The actual value of the variable in the program is updated when you click OK. The Prev button performs an undo action for each displayed character change made within the Vertical Hex Display dialog box. When a character is changed, the Prev button becomes active. The Prev button stays active until all changes are undone back to the last saved instance of the variable display. Vertical Hex Display also supports Unicode (National) values. Vertical Hex Display data may be changed on any of the three lines, character, zone and digits. In the following, the hex A in the digits portion of the j character was over-typed with a hex B, resulting in an automatic display change to the character "k". However, no actual value changes take place until the OK button is selected, only the display of the character changes. The Delete and Backspace keys may also be used. For example, when the cursor is positioned to the right of the character j and the Backspace key pressed, this results in a shift to the left of all following characters with the last character being replaced by a space (0x20). A further example is when the cursor is positioned either immediately to the right of the character i or the left of the character j and the Delete key is pressed. In this case, the j is deleted and the position replaced by a space (0x20). Pressing Delete or Backspace on the zone (digits) portion of the hex display, the character is replaced by 0x00. The Insert key may used to set insert mode on. With Insert mode set, all characters entered cause a 0x20 or 0x 00 at the end of the data to be shifted out and the character typed inserted at the cursor position.

73 Display Variable Values with Text Hover Text Hover is an additional method to display the value of variables while debugging a program. When the mouse pointer hovers over a program variable within the source listing, a small hover window appears containing the variable name and its associated value. If the mouse pointer happens to hover over something other than a program variable (e.g. text or white space), no window displays. If the content of the hover window extends beyond the size of the hover window, the pointer can be placed within the window to reveal a scroll bar. To enable or disable the Text Hover feature From the Window menu, select Preferences>Compuware>Xpediter. Select or clear the Display a variable's value when hovering over a variable check box. Enabling or disabling hover takes effect immediately. By default, Text Hover is enabled. Unlike within the Variable view, the value of a variable cannot be modified using the Text Hover feature. The Variables view must be used to change the value of a variable. In the example below, the value of the variable WORK-REC, which is 234, displays in a hover window just below the variable in the listing. When hovering over an array, the hover window indicates the variable is an array and shows its dimensions. To view the contents of arrays, use the Variables view.