Understanding CDF Sessions

CDF sessions create a unique debugging environment for batch jobs and started tasks. When you initiate a CDF session, z/XDC starts your program under its control and then waits for a developer to connect. This waiting state allows you to debug batch processes without requiring immediate interactive access, perfect for scenarios where programs run at scheduled times or when multiple developers might need to connect to the same debugging session.

CDF works through its flexibility. Your batch job starts normally through standard JES processing, but with z/XDC intercepting control at the appropriate moment. Operator console messages announce when sessions become available, and you can connect from any TSO session with proper authorization. This separation between session creation and connection makes CDF ideal for debugging in controlled production environments where direct interactive access might not always be immediately available.

Setting Up Your JCL for CDF Debugging

Converting existing JCL for CDF debugging requires minimal changes. Start by modifying your EXEC statement’s PGM parameter. For problem state programs running in key 8, change PGM to XDCCALL. For supervisor state programs requiring key 0 authorization, use XDCCALLA instead. Your original program name becomes the first parameter, followed by any parameters your program normally receives.

Here’s the basic JCL structure:

//DEBUGJOB JOB …

//STEP1    EXEC PGM=XDCCALL,

//         PARM=’MYPROG,PARM1,PARM2′

The DD statements that control z/XDC’s behavior each serve a specific purpose in configuring your debugging environment.

Essential DD Statements for CDF Sessions

//XDCJSTEP stands as the most critical DD statement for complex applications. This dummy DD controls the debugging session’s scope across your entire address space. Without it, z/XDC treats each task as a separate debugging session. Include XDCJSTEP when debugging multitasking applications, and z/XDC anchors itself at the job step task level, bringing all subtasks under a single debugging umbrella. This becomes essential when tracing execution across multiple TCBs or debugging applications that spawn child tasks.

//XDCPROF points to libraries containing your z/XDC profiles. These profiles store your debugging preferences, breakpoint definitions, and customized settings. By specifying XDCPROF, your debugging environment loads with all your predefined configurations immediately, eliminating manual setup each time you connect. Structure it like any concatenated DD:

//XDCPROF  DD DISP=SHR,DSN=YOUR.XDC.PROFILES

//         DD DISP=SHR,DSN=TEAM.XDC.PROFILES

//XDCTASK provides your TASKLIB datasets, functioning similarly to STEPLIB but specifically for z/XDC’s use. Include all load libraries containing modules you plan to debug:

//XDCTASK  DD DISP=SHR,DSN=YOUR.LOAD.LIBRARY

//         DD DISP=SHR,DSN=SYSTEM.LOAD.LIBRARY

Two specialized DD statements handle storage management for specific program types. //XDCRENT8 and //XDCREFR8 address the challenge of debugging problem state programs that reside in key 0 storage. Since z/XDC running unauthorized cannot modify key 0 storage for breakpoints or traces, these DD statements force reentrant and refreshable modules to load into key 8 storage instead, maintaining full debugging capabilities.

Connecting to Waiting CDF Sessions

Once your batch job starts, operator console messages announce the CDF session’s availability. You’ll see messages indicating the job name, ASID, and that the session awaits connection. Three methods provide access to these waiting sessions.

Through the ISPF startup panel, select option 3 to display all available CDF sessions. The resulting menu shows sessions you’re authorized to access based on SAF rules. This authorization check ensures developers only see appropriate debugging sessions, maintaining security in shared environments.

Alternatively, connect via VTAM using the command LOGON APPLID=XDC. After authentication, you’ll reach the same job selection menu. This method works particularly well when accessing z/XDC from terminals outside the standard TSO environment.

Managing Complex Debugging Scenarios

CDF sessions excel at handling sophisticated debugging requirements. For applications using multiple address spaces, configure parent-child relationships through appropriate DD statements. This maintains debugging context as your application spawns new address spaces or attaches subtasks.

Long-running batch processes benefit from CDF’s persistent nature. Set breakpoints at critical processing points, then disconnect and reconnect as needed. Your debugging state persists, allowing you to check progress periodically without maintaining a constant connection.

For production support scenarios, CDF sessions can remain dormant until needed. Include debugging DD statements in production JCL but configure z/XDC to run without intervention. When problems occur, support staff can connect to investigate without restarting the job.

Best Practices for CDF Debugging

Always specify //XDCJSTEP for any application that might involve multiple tasks. Even single-threaded applications benefit, as it prepares your debugging environment for unexpected multitasking scenarios. The overhead is negligible, but the debugging capability it provides becomes essential when tracking down timing-related bugs.

Maintain separate XDCPROF libraries for different environments. Development profiles might include extensive tracing and numerous breakpoints, while production profiles focus on specific problem areas with minimal overhead. This library structure allows teams to share debugging configurations while maintaining environment-appropriate settings.

Consider the impact of debugging on batch window timing. CDF sessions pause execution while waiting for connections and at breakpoints. In time-sensitive production environments, implement timeout mechanisms or automated continuation logic to prevent debugging from disrupting critical processing windows.

Document your CDF setup within JCL comments. Include notes about which DD statements serve which purpose, especially for less common options. Future developers (including yourself) will appreciate understanding why specific debugging configurations exist.

Moving from Development to Production

CDF’s design facilitates smooth transitions between environments. Development JCL with full debugging capabilities can move to production with minimal changes. Simply comment out debugging DD statements or use symbolic parameters to control their inclusion. This approach maintains debugging readiness without impacting normal production operations.

When problems arise in production, uncomment the appropriate DD statements and resubmit the job. CDF debugging activates immediately, providing the same comprehensive debugging environment you use in development. This consistency across environments reduces the learning curve and accelerates problem resolution when every minute counts.

CDF sessions change batch debugging from a cumbersome process into a streamlined workflow. By understanding the essential DD statements and connection methods, you gain the ability to debug your most complex batch applications with the same precision you apply to online programs. The next time a critical batch job fails at 2 AM, you’ll have the tools and knowledge to connect, diagnose, and resolve the issue efficiently.