® IBM Software Group RDz Workbench – Debugging z/OS Assembler Applications Jon Sayles, Rational System z Products - jsayles@us. ibm. com © 2012 IBM Corporation September, 2012
IBM Trademarks and Copyrights 4 © Copyright IBM Corporation 2007, 2008, 2009, 2010, 2011, 2012. All rights reserved. 4 The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. 4 This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. 4 IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM Rational products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 2
Course Contributing Authors § Thanks to the following individuals, for assisting with this course: 4 Larry England/IBM 4 Russ Courtney/IBM 4 Doug Stout/IBM 3
Course Overview § Audience 4 This course is designed for application developers who have learned or programmed in Assembler, and who need to do z/OS Traditional Development and Maintenance as well as build leading-edge applications using Assembler and Rational Developer for System z. § Prerequisites 4 This course assumes that the student has a basic understanding and knowledge of software computing technologies, and general data processing terms, concepts and vocabulary, as well as a working knowledge of Assembler and z/OS. 4 Knowledge of SQL (Structured Query Language) is assumed for database access is assumed as well. 4 Basic PC and mouse-driven development skills, terms and concepts are also assumed. 4
Course Topics § Course Name: Rational Developer for System z Foundation Training § Course Description: Learn how to use Rational Developer for System z to do z/OS traditional development, maintenance, support and for Enterprise Modernization of z/OS applications § Pre-requisites: Some experience developing Assembler applications using z/OS is expected. A working knowledge of SQL is also recommended. § Course Length: ~5 days – or if done in self-paced mode, at your own pace § Topics (Agenda) § § § § § Getting Started - installing and configuring RDz - and the course materials, and using Eclipse The RDz Workbench – Code analysis tools – Editing – Compiling programs – Debugging local Assembler programs The Data Perspective: – Working with relational data sources – Modifying test data – Editing and testing SQL statements Working with remote system resources: – Connecting to a mainframe – Data management – Accessing and editing files z/OS Application Development – Creating MVS Subprojects – Creating and customizing project properties Debugging z/OS Applications – Debugging Batch Applications – Setting Debug Tool for Online Applications Working with File Manager – Creating test data – Editing complex file-types Working with mainframe ABENDs using Fault Analyzer – Creating Fault History views – Analyzing and solving mainframe ABENDs Creating and modifying BMS Maps using the BMS Map Editor 5
UNIT The RDz Workbench Topics: § Debugging z/OS Assembler Batch Applications § Debugging z/OS Assembler Online Applications § Appendix 6
Topic Considerations Note: In this topic you will learn how to debug a Assembler program running on a z/OS mainframe. The screen captures all describe connecting to a public z/OS machine that IBM makes available – during classes. If you are taking this course through standard IBM services delivery you should be able to use the properties (I/P address, port#s, etc. ), logon IDs and passwords that your instructor provides you with. But you may also be taking this course standalone – and in that case, you will need to speak to your company's Systems Programming staff to learn how to connect and logon. It goes without saying that the actual file names in the screen captures of mainframe libraries and datasets will vary. So you should focus on the process and steps and "how to" – and don't be perplexed at differences in screen captures. You also may be using your company's own Source Control Management system – to do things like builds, compiles, etc. In that case much of the remote functionality in RDz will be customized and tailored to your company's unique and idiosyncratic procedures and protocols. 7
Workshop Considerations Note: Unfortunately, due to the fact that you will need an I/P address that resolves to your workstation in order to use IBM Debug Tool, there is no way that you can use the Sandbox or z. Server. OS for workshops that reflect the content in this unit. Your options for additional learning include: Return to the RDz Workbench Introduction unit – and carefully go over all the Debug option materials in the slides. Note that the workbench interface/perspective and > 95% of the functionality of Remote Debug is also contained in Local Debug. 1. 2. Along with this course you can watch the following Camtasias on RDz Debugging: http: //websphere. dfw. ibm. com/atdemo_rdz_zosad_recorded. html RDz and Debugging RDz and Remote Development (including Debugging) 8
Topic Objectives After completing this unit, you should be able to: § Describe the concept of source code debugging § List the run-times that Debug Tool supports § List the steps in preparing a program for debugging § Debug a mainframe batch job – Describe the run/step/animate options – List PF-Keys associated with them – Set/unset/inspect conditional and unconditional break-points – Set "watch" break-points that halt execution when a value in a variable changes – Show to access the LPEX editor functionality during debugging (such as Perform Hierarchy) – Be able to Jump to any given line, and run to a line – Show to change variable values dynamically during debug – Show to set different levels of variable display – Monitor specific variables you are interested in § Debug a CICS online transaction – Discuss the Debug Option setup and configuration requirements for Online Debugging – DTCN Profile/View – DTCN Transaction – Launch a CICS transaction that invokes Debug Tool 9
Debugging Overview Face facts: No one gets it right the first time. 4 Not at the level of production business logic That's why IBM invented source-level application debuggers, so that you can: 4 View program execution, line-by-line 4 Verify the value of a variable – during program execution 4 Stop and start program execution, and analyze results at the speed that our procedural understanding of the application's execution flow can handle 10
Enter Source-Level Debuggers § Specifically: IBM Debug Tool/PD Tools Family 4 Green-screen (TSO-based) or RDz/Workstation-based interface to z/OSbased debugging engines 4 Debug: § Online (CICS, or IMS TM) § Batch § Multiple languages (Assembler, PL/I, COBOL, Java, etc. ) 4 Seamless debugging of mixed-language/cross-platform applications 4 Interactive, source-level debugging in RDz with program running on z/OS 4 Display, monitor and alter program variables 4 Set standard types of breakpoints 4 View data in Hex (EBCDIC) or string values 4 Multiple configurable views 4 Ability to make adjustments to the program while debugging § Debug Tool product web-site: http: //www-01. ibm. com/software/awdtools/debugtool/ 11
Debug Tool - Application Environments One debugging engine, with support for many environments: Batch 3270 or GUI CICS IMS/TM 3270 or GUI DB 2 stored procedure 3270 or GUI UNIX systems services 3270 or GUI Debug Tool Debug Tool Batch Applicatio n CICS Applicatio n IMS Applicatio n DB 2 Stored Procedure Posix Applicatio n Transaction Batch region Transaction CICS region IMS/TM region 12 WLM region z/OS
RDz Interfacing with Debug Tool TCP/IP Debug Tool Engine Your Application Load Module z/OS Data Source The RDz remote debugger 4 Client software that is installed with RDz on your workstation 4 Communicates with the Debug Tool engine on the mainframe § Note that Debug Tool must be installed on z/OS in order for you to do the labs in this unit 13
Steps for Batch Application Debug Session 1. Ensure that your compile proc has the necessary TEST parameter, and Compile/Link options and DD cards to create a debug-ready load module 2. Discover workstation TCP/IP parameters: 4 IP Address 4 Listener port# 3. Enter TCP/IP address of workstation in run JCL for Debug Tool DD statement, and Submit the JCL 4. Load the Assembler source code 5. Debug the application 14
Compile JCL Requirements for Using Debug Tool for Assembler § To debug Assembler programs, you will need additional datasets and steps: § SYSADATA § EQALANGX 4 Step creates Debug symbolics § See the Debug Tool v 11 Users Guide – Chapter 6 Preparing an Assembler program – for more information on these datasets. § Sample Assembler JCL is in the slide notes 15
2. Discover TCP/IP address and RDz Port § Open the Debug Perspective 4 Click the small downward pointing triangle next to the debug-daemon icon 4 Note the Port# 4 Select: Get Workstation IP… 4 Copy the IP address Note: Your RDz Port# will most likely be set once, and will change infrequently. However, depending on your installation's setup, your workstation's TCP/IP address could change - often 16 See Notes
3. Submit the JCL for Assembler Debugging § Configure your application to start Debug Tool by including a specific DD card in the run JCL – that includes your workstation's current Port# and TCP/IP address 4 This is an example of JCL to run a batch job 4 The EQANMDBG DD statement is the easiest way to start the Debug Tool for batch applications //EQANMDBG DD * PGM TEST(, , , TCPIP&5. 76. 97. 236%8003: ) 17 Sample JCL In Slide Notes
3 a. Debug Tool - Prompts § Debug Tool will interface with RDz and throw the Confirm Perspective Switch prompt 4 Click Yes Additionally, if your mainframe source code is out sync with the Load Module you'll get an informational prompt. This typically means you need to check your compile listings for syntax errors that caused the link edit step not to execute because of condition codes 18
3 b. Debug Tool Connects to RDz § Debug Perspective is launched in RDz § Program source is copied down from z/OS to your RDz workstation § Execution is on z/OS Note: Initially the Assembled instruction set is loaded into Debug Tool. You will want to load and utilize "debug data" source – the LANGX file output from Assemble in your testing. This is achieved via the LDD XXXX command (next slide) 19
4. Load Debug Data (LDD Command) § Before you can debug an assembler program, you must: 4 4 Define the compilation unit (CU) as an assembler CU Load the debug data for the compilation unit. § This can only be done for a compilation unit that is currently known to Debug Tool as a "disassembly CU". § Use the LOADDEBUGDATA command 4 abbreviated as LDD … to define a disassembly CU as an assembler CU and to cause the debug data for this CU to be loaded. § See the Debug Tool Users Guide for additional details on this command Steps: § § From the Debug Console view Enter the Debug Command: 4 LDD <modulename> Note: Debug Commands are not case-sensitive 20
Breakpoints 5. The Debug Perspective and Views Monitors and Registers views The Debug Icons Assembler Macro Expansions Your code Current Instruction Pointer Hovering over a variable returns the variable value Load Module Disassembled Offset Object Code 21
Prefix Area Debug and RDz's LPEX Editor Functionality Command Line All of the LPEX editing features work under Debug Tool 22
Action Icons – Review Debug Listener (Should be green) Resume: Run the program to the next breakpoint or to the end Step Return: run until return from subprogram Terminate: End the program Disconnect: from the debug engine Step: run one statement Animated Step Continuous source-level debugging without user interaction 23 Step Over: run one statement, but step over a CALL
Run Menu § § Shows same + additional debugging functionality as icons on toolbar 4 However, not all Run menu functionality enabled for Assembler/PL 1 Also shows hot-keys 4 § Your PC's function keys Context-sensitive: 4 Options are grayed in current debug session if not applicable 24
Displaying/Manipulating the Registers Enable from: Window > Show View > Registers Opens the Registers view to a scrollable, editable register list with access to the following: 25
Statement Breakpoints – Review § A statement breakpoint will stop the program when it reaches a statement: 4 It stops before the statement runs § A breakpoint can optionally be made conditional 4 A simple condition may be specified such as: § VAR 1 > 999 …or… § VAR 2 = 'ABC' § A breakpoint can be based on a frequency: 4 Stop the Nth time a statement runs 26
Set a Statement Breakpoint – Review dbl click Set a statement breakpoint by double-clicking in the gray area next to a statement 27
Set/Edit Conditional Statement Breakpoints Select the Breakpoint. Right-click and select: Edit Breakpoint… A breakpoint can trigger the Nth time the statement runs… RECORDS = 9 Can set to different statement/line Or click Next > to specify conditional breakpoint logic 28 … and breakpoints can be conditional.
Watch Monitor Breakpoints § Can have breakpoints occur conditionally, when: 4 The value in a field changes 4 Some portion (# of bytes) of a field changes 4 A simple condition tests true for the value in the field § Steps: 4 Select a variable 4 Right-click, and select: Add Watch Breakpoint… 4 Select Number of bytes to watch – or add a simple condition § Specify Auto to test for all bytes 29
Run (F 8) to a Statement Breakpoint Resume click A breakpoint icon is shown… and the breakpoint is also shown in the Breakpoints view. 30 see slide Notes
Breakpoint Options – 1 of 2 Disable (but do not Remove) Breakpoints by unchecking a box The program ran to the breakpoint … or by deleting it from the Breakpoints view from the Context Menu You can remove the breakpoint by double clicking again here… 31
Breakpoint Options – 2 of 2 Disable (but do not Remove) Breakpoints by unchecking a box By Editing a Breakpoint… you can make the Breakpoint conditional (prior topic) 32
Entry Breakpoint Options You can set an “Entry Breakpoint” – which would allow you to Resume (run) your module until the Called program is launched by z/OS Resume to the Called module From Modules Right-click the module and Set an Entry breakpoint Note that you will need to load the Debug Descriptor (LDD) for the subroutine(s) 33
Monitoring Variable Values Besides hovering over a variable, you can: 1. Double-click and select any variable 2. Right-click and monitor the variable value throughout your debug session The Monitors view shows the variable's value 34
Monitors View – Options Monitored variable value – in EBCDIC internal display very useful for debugging data exceptions Change Value… allows you to modify the variable's value on the fly – during debug 35
Detach the Monitors View A useful Best Practice… 36 Can view any # of variable values during debug, animated debug or Resume to breakpoints
Making Optimal use of Screen Real Estate § Some of the Debug Perspective views are not enabled for Assembler programs: Variables, Outline, etc. § Along with detaching views, consider moving the useful Assembler views "front-and-center" to maximize your screen real estate – adding to your ability to see as much useful information at a glance Registers view Breakpoints view Monitors view 37
Monitor Memory § The memory content can be shown (or “rendered”) in several different formats: § Raw HEX, EDBCDIC or ASCII § Tree structure using customized XML mappings. 38
The Debug Console View Debug Tool messages The Debug Console view shows RDz messages and lets you enter some Debug Tool commands Place your cursor in the Command area and press Ctrl+Spacebar – to see a list of available commands 39 You can enter a subset of commands from the Debug Tool 3270 interface, a list of Debug Tool commands that are valid for use in RDz can be found in the Appendix of the Debug Tool Reference and Messages Guide.
Debug Console Commands – Tracing Through Statement Execution This is another very popular command: SET AUTOMONITOR ON LOG It forces Debug Tool to track each statement as it's executed and write it to the Debug Console Using this technique you can copy and paste your program's dynamic execution and trace forward and backward through any portion of your code You can also copy all of the statements to hard-copy : 1. 2. 3. Right-click Select Export History Specify a file – preferably an RTF or MS-Word doc, as formatting will be retained 40
Debug Option – Jump to / Run To § Jump to Location - skip over sections of code to avoid executing certain statements or move to a position where certain statements can be executed again. Useful: § § § To avoid called programs or I/OS to a not available dataset Or to iteratively execute some statements of interest Run to Location - executes all statements between the current location and the run-to location. Context Menu 41
How to return from anywhere in your program to the Current Instruction § To get back to the Current Instruction Pointer (the "next sequential instruction") – if you've navigated away within the source: 4 Click the small blue rectangle in the right-hand margin of your source code 42
Obtaining the Outline View § To enable the Outline View during your Debugging session: 4 From Remote Systems – open the program 4 Manipulate the View size/window proportion, and ensure that the Outline view synchronizes with the source file editor Note that the Outline view will not synchronize with the Debugger's code view 43
Handling program abends § Debug Tool can receive control back from the system after an abend occurs 4 The program will be stopped at the abending statement § You can: 4 Allow the application to abend and terminate § Capture abend info with a product such as Fault Analyzer § Terminate the application and prevent further processing 4 Or continue running the program § Usage note: 4 The LE TRAP(ON) option must be active 44
Terminating the application § There are several options for terminating your application: 4 Remain in the debugger, and RESUME until the program runs to completion § The program will terminate normally or with an abend § The return code is controlled by the program 4 Disconnect the debugger, and allow the program to run to completion § The program will terminate normally or with an abend § The return code is controlled by the program 45
Termination action buttons You can immediately terminate the application using action buttons Terminate: Immediate termination of the application. No more program statements run. RC=0 is returned to the environment. 46 Disconnect: Disconnect Debug Tool from the application. The program continues to run from the current location without the debugger. And subsequent batch job steps can finish as well.
Force an immediate termination with abend 1 Right click in the Debug view right click 2 Options 3 47 Terminate and abend
Restart Your Debugging Session For batch debugging 4 If your submitted JCL is still in the code (Content) area § No need to return to the z/OS Projects perspective 4 Right-click 4 Select: Submit Note that F 11 (or Debug from the Run menu) does NOT work – as it did with Local Assembler debugging 48
Summary Having completed this unit, you should now be able to: 4 Describe where the debug engines are located 4 Show to set the workbench preferences for running and debugging 4 Show to invoke the debugger for local programs 4 Describe the views of the Debug perspective 4 Demonstrate how to set breakpoints in Assembler code 4 Explain how to set up the Assembler compile options for remote debugging 4 Show to debug a remote batch Assembler program 49
® IBM Software Group Batch Assembler Debugging Workshop © 2012 IBM Corporation September, 2012
Pre-Workshop Overview § You will use Debug Tool to test the ASAM 1 and ASAM 2 batch Assembler programs § Steps: 4 Allocate data sets 4 Modify the JCL for the compile and run stream JCL 4 Find your workstations: § I/P Address § Port# 4 Substitute those variables into the run steam JCL 4 Debug 4 Test out various Debug Tool options § At any point, you can terminate your debug session by clicking the Red icon or pressing Ctrl+2 § You can submit the JCL again – Debug (again) 51
Workshop – Preparing for the Workshop § Prerequisites: 4 Ensure the IBM Debug Tool is installed and configured on your z/OS § You may need to speak to one of your systems programmers about this 4 Ensure that you have a "real" I/P address (as opposed to a router-generated I/P address) for your workstation 4 Ensure that you know to invoke the IBM Assembler AMA 90 – typically found in Linkpack § Locate the files: 4 Assembler programs: § ASAM 1 DBG § ASAM 2 DBG 4 JCL: § BASAM 1 § XASAM 1 § Rename the files: 4 ASAM 1 DBG ASAM 1 4 ASAM 2 DBG ASAM 2 If another version of ASAM 1 and ASAM 2 exist, please delete them before renaming the files 52
Workshop – Allocate Data Sets You will need the following development and debugging libraries: 4<HLQ>. xxx. ASM – example: DDS 0001. TEST. ASM 4<HLQ>. xxx. COPYLIB – example: DDS 0001. TEST. COPYLIB 4<HLQ>. xxx. LISTING – example: DDS 0001. TEST. LISTING 4<HLQ>. xxx. LOAD – example: DDS 0001. TEST. LOAD 4<HLQ>. xxx. EQALANGX – example: DDS 0001. TEST. EQALANGX If you don't already have these libraries, allocate them, using Specify characteristics by usage type: type 53
Workshop – ASAM 1 and ASAM 2 Code Review § Load ASAM 1 and ASAM 2 into the editor – and review the logic in this typical z/OS data collections/editing pattern § Time permitting, learn a little bit about the programs you're going to debug: 4 Multiple windows, Outline and Filter views, navigation techniques, etc. 54
Assemble ASAM 1 and ASAM 2 § Steps (in BASAM 1. jcl): 4 In all four job steps, modify the library names for: § Assembler compiler library § Your personal datasets 4 Submit the JCL 4 Go to the JES queue and check the return codes for each step 4 Optionally, expand your load library and ensure that there are members for ASAM 1 and ASAM 2 § Note – this step requires you to have allocated the datasets referenced in the JCL (see prior slide) Don't forget the 2 nd LKED step 55
Workshop – Obtain your I/P Address and Port# § Switch to the Debug perspective § Click on the downward pointing triangle to the right of the little green listener tool, and: 4 Note the Port# 4 Select and copy the I/P address This is the I/P address you want! § Ensure that green listener tool is – in fact – green, and not red. If it's red (not listening) click it once to change it to green 56
Workshop – Modify and Submit the Run JCL § Open XASAM 1. JCL and modify: 4 JOB card § You will have to enter your shop's specific JOB card parameters 4 Your test dataset names: § Load library § SAMFILE - //CUSTFILE § Paste your copied IP address – between the & and % § Also verify (or change) the Port # to your RDz client listener port (recall from previous slide) § Submit the job: Click Yes to enter the Debug Perspective 57
Basic Debug Techniques § Begin using the Debug Tool functions that you learned about in this section: 4 Start by loading the Assembler source code for both modules – From the Debug Console, type: § LDD ASAM 1 § LDD ASAM 2 4 Press F 5 – or click Step Into a few times – 4 Hover a few variables § INREC § DATALEN 4 Try some find commands – in the ISPF command line area of ASAM 1. asm 4 From the Context menu, Filter ASAM 1 4 Press F 2 – then close the split screen 58 Top ; f closfils last LDD ASAM 1
Workshop – Debug Techniques – Working with Registers § Select the Registers view § Step through the program – as the various Assembler statements update the register contents note the changes § Right-click and Monitor one or more of the Registers 59
Workshop – Debug Techniques – Monitors § Check the Monitors view § Experiment with: 4 Change representation 4 Change Value… 4 Show Type Names 4 Remove § Try Detaching the Monitors view – or moving it to a different area within the Debug perspective § Also experiment with: 4 Monitor Memory 60
Workshop – Debug Techniques – Breakpoints § Set and use breakpoints 4 From the Modules view – drill down to ASAM 2 and Set an entry breakpoint 4 Click Resume (F 8) to the breakpoint 4 Press F 5 (or click Step Into) a few times 4 Press F 7 – to return to ASAM 1 4 Resume (F 8) to the entry breakpoint again (you'll stop inside of ASAM 2) 4 From inside of ASAM 2 – Resume or press F 8 … what happened? 4 Press F 7 – to return to line-by-line debugging of ASAM 1 4 From the Breakpoints view – un-check (disable) the Entry breakpoint 4 Add a few other breakpoints by either double-clicking in the prefix area – or Right -clicking over the statement and select Add Breakpoint 4 Resume (F 8) to the breakpoints while they are enabled 4 Remove or Disable the breakpoints 4 Right-click over INREC and select: Add Watch Breakpoint 4 Resume (F 8) § Did the program stop? Where? What's in the Debug Console view? 61
Workshop – Automonitor on Log § Tracing execution flow 4 From the Debug Console, type: set automonitor on log 4 Continue to step – or use: What happens in the Console? 4 At any point, Right-click inside of the Debug Console content and select Export History Open the exported messages with Wordpad Notepad) (not 62
Workshop – Jump To Location Branching and Debug § From any executable Assembler Statement 4 Right-click 4 Run To Location …or… 4 Jump To Location Combine Techniques § In the program, find the line CLC EOFFLAG, =X'FF' § Jump to that line § Select and Monitor the EOFFLAG variable 4 Monitor Expression 4 What is the current value? § Press F 5 (or Step Into) several times § From the Monitors view, change the value of EOFFLAG to X'FF' § Jump back to the CLC statement § Press F 5 (or Step Into) again § Note the flexibility of being able to iteratively test expressions 63
Workshop – Experiment ! Terminate your debug session § Time permitting – submit the JCL again, and try: 4 Set conditional breakpoints 4 Unset/Remove breakpoints § Single § Remove All § Submit the JCL again, try: 4 Run to Location § How does this differ from Jump to Location? 64
UNIT The RDz Workbench Topics: § Debugging z/OS Assembler Batch Applications § Debugging z/OS Assembler Online Applications § Appendix 65
Topic Objectives After completing this unit, you should be able to: 4 Using the Problem Determination Tools, Debug Option and RDz: § Debug a mainframe online transaction 4 Describe the online transaction features for configuring your 3270 sessions with Debug Option 4 Debug a CICS 3270 Application 66
Online Debugging Overview § Guess what? No one gets it right the first time coding online programs either § Lucky for you: 4 Debug tool handles: § CICS 3270 online transactions § IMS TM online transactions 4 Without any different debugging techniques § The only difference from batch is the debug setup procedure for the online environment 67
Steps for Online (CICS) Application Debug Session 1. Ensure that your compile proc has the necessary TEST parameter, and Compile/Link to create load module – and that your CICS application is setup for Debug Option testing 2. Discover workstation TCP/IP parameters: § IP Address § Listener port# 3. Access and login to your CICS region – Green Screen 4. Use the DTCN view, or execute the DTCN transaction and specify: § Terminal ID § Transaction code and programs – to put under Debug control § User-ID § TCP/IP parameters: § § § 5. IP Address Port# Save the DTCN transaction specification Debug your CICS application 68
1. Compile JCL Requirements for Using Debug Tool § Use the TEST compiler option to prepare your executable Assembler program for use with the debugger. 4 The TEST option is required for remote debugging. It produces symbol and statement information that enables the debugger to perform symbolic sourcelevel debugging § Enterprise Assembler 3. 4: TEST(NONE, SYM, SEP) § Enterprise Assembler V 4. 1 +: TEST(NOHOOK, SEP, EJPD) 4 Include the DD card for your SYSDEBUG dataset in the Assembler Compile step § In traditional compile JCL – this would be in the IGYCTRL step § If you are not using the IBM/RDz compile PROCs for building your applications, be sure to override the compiler option and add TEST - as shown 69
2. Discover TCP/IP address and RDz Port - Review § Open the Debug Perspective 4 Click the small downward pointing triangle next to the debug-daemon icon 4 Note the Port# 4 Select: Get Workstation IP… 4 Copy the IP address 4 Either paste the IP address into Notepad, or write it down Note: Your RDz Port# will most likely be set once, and will change infrequently. However, depending on your installation's setup, your workstation's TCP/IP address could change - often 70
3. Setup the DTCN Parameters Using the DTCN View If you are using RDz v 7. 6. 1 or higher, you can utilize an RDz view to setup your DTCN CICS Debug properties. § Steps: 4 From Window > Show View > Other type: DTCN and select DTCN Profiles 4 Right-click inside the new, empty view and select: Create 4 From the DTCN profiles window: § Enter your User ID § Click DTCN Preferences 4 From DTCN preferences specify: § Host Name/IP Address § CICS DTCN transaction port § CICS login credentials: – User ID – Password § Other fields as shown § Click Test Connection § Click OK to check your work 71
Setup the DTCN Parameters Using the DTCN View – continued From DTCN profiles click Next > From DTCN pattern matching specify : 4 Terminal ID: * 4 Transaction ID (Trancode) 4 Click Add, and specify the Compile Units (Load Module names) Click Next > From DTCN TEST run-time specify: 4 Fields as shown 4 Session Address (your workstation I/P address) 4 Port (your listener Debug Tool listener port) 4 Other fields – as shown 4 Click Finish DTCN Profiles will be populated with entries for all users connecting into that CICS region 72
Using the DTCN View Once you have setup the DTCN View, you can: § Activate the profile 4 This modifies the CICS System Tables dynamically, through the Debug Tool facilities – and allows you to debug CICS transactions § Other options include: 4 Edit the profile – and change your I/P address § After you reboot your machine 4 Delete the profile 4 Create a new profile 4 Refresh the display of DTCN entries in the region Note: In order to debug CICS programs you will have to launch a 3270 emulation session (next slides) to kick off the transaction 73
3. Login to your CICS Region From Remote Systems Explorer: 4 Right-click 4 Select: Host Connection Emulator 4 Select your CICS application 4 Enter your Userid and Password and sign in 74
3. Setup the Debug Option Parameters using DTCN Transaction – 1 of 2 If you did NOT use the DTCN view to enter your DTCN properties you can do so using a CICS Transaction (green screen) From CICS (after signing in): 4 Clear the screen, Enter: DTCN – and press Enter From the DTCN screen 4 Press F 10 – this will fill in the Terminal Id for your workstation Note that you can also * type an asterisk: …as the Terminal Id Note: You would only use the DTCN transaction to specify your Debug Option properties if you could not use the DTCN view (prior slides) 75
3. Setup the Debug Option Parameters using DTCN Transaction – 2 of 2 DTCN transaction data entry screen Enter the Tran-code 4 § Transaction ID 4 Enter up to eight specific Program Id(s) you wish to debug through …or… 4 Enter wildcard text for the Program Id(s) § Ex. CD* 4 Enter your User-ID 4 Session Type: TCP 4 Port Number: from your Debugger look-up 4 Display ID: Your TCP/IP address, from your Debugger look-up (note that you can not paste into this 3270, screen) § Press F 4 to save your debug profile § Press F 3 to clear the screen 76
4. Start Debugging From the CICS region 4 Enter the Tran-code 4 Press Enter 4 Click: Yes at the Confirm Perspective Switch 77
4. Start Debugging Debug as previously learned in the batch/remote and Local debug units. 78
What Happens for Calls and Screen-IO? – 1 of 2 You will be prompted, and presented with debugrun-time options 79
What Happens for Calls and Screen-IO? – 2 of 2 If your current transaction ends, and a BMS or 3270 screen is sent: § You will be notified (prompted) by the debug engine § If a screen is sent, the 3270 will display in the content area 80
What About PF-Keys and Other Data Entry? § You can resize the screen portion of the debugger § And use the Key emulation options in the Host Connection 81 PF-
Topic Objectives After having completed this unit, you now should be able to: 4 Using the Problem Determination Tools, Debug Option and RDz: § Debug a mainframe online transaction 4 Describe the online transaction features for configuring your 3270 sessions with Debug Option 4 Debug a CICS 3270 Application 82
Larry's Notes § ALC Debugging § 1. GPR front and center (how? ? ) § Tabbed view - Registers § If running Assembler ==> 12 points to CAA (main control block for all HLLanguages) § DSA (reg. 13 points to) Dynamic Storage Area § De-reference (? ) Address values inside the registers § "show me what this is pointing at" § De-reference pointer values inside of memory § Linked List § Storage View - De-reference "show me storage this address is pointing at" § 000123458 - go to that address, show me what's there § W 1 Fwd § W 2 Back § LNAME § FNAME § § § DSECT "structure" (like a Assembler group field - like a map over storage). C struct, PL/I Structure Technique (laborious) create XML file that mimic'd DSECT Associate DSECT with storage Can have symbolic representation as you move through the Linked List § Register Tab (%GPR 1 --> F). . . can put conditionals around (break points)? 83
Скачать презентацию IBM Software Group RDz Workbench Debugging
dbf71dd84d659146c2150290b183d0a0.ppt