Debugging mainframe applications requires flexibility in how you initiate your debugging environment. z/XDC provides five distinct methods to start debugging sessions, each tailored to different scenarios and workflows. Let’s walk through all five options and help you figure out which approach fits your specific situation best.
Method 1: The ISPF Startup Panel
The z/XDC startup panel serves as the simplest entry point for debugging sessions. Available as both an ISPF panel and executable CLIST, this method requires minimal setup. Simply specify your program name, parameters, and TASKLIB datasets containing your load libraries. For authorized programs running in supervisor state key zero, toggle the authorization field to YES. The panel also handles situations where problem state programs reside in key-0 storage by allowing reentrant and refreshable programs to load into key-8 storage instead.
This approach works best for standalone applications and test programs running under TSO or ISPF. While designed for straightforward scenarios, the panel can accommodate more complex environments through its various configuration options—though you might find yourself doing extra gymnastics for really complicated setups.
Method 2: Batch and Started Task Integration
Production environments often require debugging batch jobs or started tasks. Modify your JCL by changing the PGM parameter to XDCCALL for problem state execution or XDCCALLA for supervisor state. Your original program name becomes the first parameter, followed by any required program parameters.
Critical DD statements include:
- //XDCJSTEP: Controls debugging scope across the entire address space, essential for multitasking applications
- //XDCPROF: Points to libraries containing your XDC profiles for automatic loading
- //XDCRENT8 and //XDCREFR8: Manage storage allocation for reentrant and refreshable programs
This creates a CDF (Cross Domain Facility ) session that displays operator console messages. Connect to these sessions through the startup panel’s option 3 or via VTAM using LOGIN APPLID=XDC.
Method 3: Cross-Memory Hooks
Debugging programs already running in other address spaces requires cross-memory hooks. Start with a dummy XDC session using TSO XDCCALLA IEFBR14. Then use SET ASID to target your desired address space. After mapping the target module and setting hook points, XDC automatically creates a debugging session when execution reaches those points.
This technique proves invaluable for debugging PC routines, SVC routines, system exits, and code running in PLPA or LINKLIST without requiring application restarts or modifications. Basically, if you need to debug something that’s already humming along in production, this is your ticket.
Method 4: Recovery Environment Integration
Embedding z/XDC into your application’s recovery routines provides automated debugging capabilities. Within ESTAE or ESTAEX exits, add logic to determine when to invoke XDC. Expected abends can continue normal recovery processing, while unexpected errors trigger debugging sessions automatically.
This integration allows debugging through simple operator commands or automatic session creation when problems occur. Though requiring more initial setup, this method provides seamless debugging for complex, long-running applications. Think of it as building debugging infrastructure right into your application’s DNA.
Method 5: IPCS with dump/XDC
The fifth method uses dump/XDC to apply XDC’s capabilities to system dumps within IPCS. After setting your dump in IPCS, navigate to option 6 (Commands) and issue the DXDC command. This launches XDC in dump analysis mode, providing all debugging features except tracing and zapping, since you’re examining static dump data rather than live storage.
Selecting Your Approach
Your debugging needs will determine the best entry method. Use the startup panel for quick testing, batch integration for production environments, cross-memory hooks for live debugging, recovery integration for permanent infrastructure, and dump/XDC for post-mortem analysis. Each method provides full access to z/XDC’s debugging capabilities while fitting naturally into different development and troubleshooting workflows. The real trick is knowing which tool to pull out of your toolbox for the job at hand.