Compuware Source Support

Why You Need to Implement Compuware Source Support Best Practices

As a customer, when you implement Compuware Source Support best practices, you get access to program source code when and where you need it. This could come in handy:

  • During a Compuware Xpediter debugging session while working on program
  • Getting into a report listing for contextual information about code while resolving abends in Compuware Abend-AID
  • Understanding where you are in the code while using Compuware Strobe to determine how you can reduce a program’s overhead

Recently, we covered this and more in, “Source Support Best Practices for Enabling Effortless Debugging in Topaz,” the second monthly webcast in our “Did You Know?” series. Watch the replay, or continue reading, to learn about the three Compuware Source Support practices mainframe customers use:

  1. Classic DDIO (DDIO is simply a Compuware source listing file)
  2. Source Shared Directory (SSD)
  3. Embedded Source Support (ESS)

Which Compuware Source Support Should You Use?

Right now, most Compuware customers leverage Source Support through Classic DDIO. We’ll cover the details in just a second and explain how the most recent evolution of Compuware Source Support, ESS, will help your team become more productive and agile through reducing or eliminating DDIO maintenance. The best part is your Compuware products will maintain their most recent source listings and you won’t have to resize DDIO files anymore due to them running out of space.

For context, let’s quickly explore an issue you may encounter during an Xpediter debugging session in Compuware Topaz. The circled message below lets the user know there’s no source available for their program.

Xpediter debugging session

This could be the result of:

  • Deleting a DDIO source listing member to make room for another
  • Failing to compile with the Compuware compile process
  • Forgetting the DDIO name of where a compile listing went
  • Mismatching date and timestamp

Implementing the most recent Compuware Source Support best practices can help prevent these issues. Let’s go through the three available options.

Classic DDIO

With Classic DDIO, you have a DDIO file for source listing. When you compile, you write to a LOADLIB and a Compuware DDIO file to get your source.

This Compuware Source Support practice requires a lot of effort. There’s administration to maintain, there are extra setup steps for users and names of DDIO files are easily forgotten, to name a few.

If you look at the screenshot below, you have a DEVL.LOADLIB (green), a TEST.LOADLIB (orange) and a shared COMMON DDIO (purple).Compuware Classic DDIO

With this, users could run into issues—here’s how: On January 12, a user compiles PDA001. It goes into DEVL.LOADLIB and the source listing goes into the COMMON DDIO where it’s locked.

If PDA001 is compiled again on January 20 to TEST.LOADLIB, in the COMON DDIO there is now the original program from the 12th and the test from the 20th. The former is unlocked, the latter is locked.

If we add more programs (PDA002, PDA003, PDA004) to DEVL.LOADLIB, the members show up fine. However, the original PDA001 from the 12th has been moved to the trash. Because DEVL.LOADLIB and TEST.LOADLIB share COMMON DDIO, and because PDA001 was unlocked and we needed room after PDA004 was written, PDA001 was deleted.

What happens now? If a programmer tries to debug PDA001 from DEVL.LOADLIB, they get the message circled above in the debugging session telling them the source listing can’t be found. New compiler listings would also fail due to lack of space.

Source Shared Directory

You can avoid the above issues with SSD. By coupling an SSD file (basically a pointer file) and a database file with each LOADLIB you’re working with, the source is pushed into a database that automatically spawns new databases as it fills up.

SSD is easier to maintain than Classic DDIO because it doesn’t require extra setup steps or knowing the names of DDIO files, and it automatically allocates additional, self-maintaining database files as needed, keeping only the current DDIO version of each program.

Looking at the same example from above, DEVL.LOADLIB.SSD (purple) contains pointers to other files called databases. Here, we’re talking about DEVL.LOADLIB.DB1 (also purple).

When you compile a program on January 12 into DEVL.LOADLIB (green) it also writes a pointer into DEVL.LOADLIB.SSD and writes the actual source listing into DEVL.LOADLIB.DB1. If we do the same compile on January 20 into TEST.LOADLIB (orange), the same pattern ensues.Compuware Source Shared Directory (SSD)

With SSD, you create a pair of databases for every LOADLIB. JCL is provided that will help you automatically create them as needed. Unlike Classic DDIO, as you compile more programs you retain PDA001 from the 12th, regardless of space. When DEVL.LOADLIB.DB1 is full, it automatically allocates a new database and attaches it to the SSD DEVL.LOADLIB.DB2, as shown below.Compuware Source Shared Directory (SSD)

Embedded Source Support

Despite the improvements to Classic DDIO that SSD provides, ESS is the latest and greatest automated and transparent Compuware Source Support solution, offering zero administration and only requiring compile setups to be turned on. Source listings formerly in the DDIO or SSD become a nonexecutable part of the load member because they’re paired with actual load modules.Compuware Embedded Source Support (ESS)

ESS is self-maintaining because the source stays with the load module you’ve compiled, eliminating chances of mismatches. Source can be viewed from within a load module with a simple right click. ESS supports COBOL Version 5 and above.

ESS is the simplest Compuware Source Support option available to customers, as it eliminates the need for extra files because all source is contained within the LOADLIB. As a member moves up the promote process, the source goes with it.

We’re continuously improving the elegant simplicity of our solutions for customers, helping your team be more productive and agile. To learn more about how we’ve minimized the work required from programmers using Compuware Source Support best practices, watch the webcast replay of “Source Support Best Practices for Enabling Effortless Debugging in Topaz.”

Register for our next “Did You Know?” webcast, “Protecting Sensitive Data with Ease.”

The following two tabs change content below.

Ed Gannaway and Scott Smith

Latest posts by Ed Gannaway and Scott Smith (see all)

Share: