Source Support best practices

This section intends to guide and help you implement the most optimal and rewarding experience using BMC Source Support solutions.

Benefits of Source Support

BMC AMI products provide maximum benefit when associating collected information with affected programs. This section describes best practices to ensure that you get the most from your BMC AMI tools at all stages of the application life cycle.

This process ensures that the human-readable symbolic file is available at every stage of development and production. This file is often referred to as the BMC compiler listing, DDIO listing, and source listing. All these names refer to the same object.

The following BMC AMI products use the BMC compiler listing:

Code Debug- to interactively analyze and debug program code.
Code Coverage - to verify that a test executed the code.
Strobe and iStrobe - to show the line of code where the application consumed resources.
Abend-AID - to show the last statement executed and format program storage.
Total Test - requires the listing to enable virtualized testing.

Implementing source support ensures that a source listing is available when needed with the least amount of effort by the end user.

Migrating-your-current-source-code-to-the-new-process

Embedded-Source-Support-listing

DDIO-files

When you follow the naming conventions, you automatically gain all the benefits of source support with no additional user configuration. BMC AMI products locate the cataloged source support repository based on the name of the LOADLIB from which the system loaded the program.

Implementing a strategy where a BMC AMI listing is always available is a fairly straightforward process which can mirror your management of source code and executable LOADLIB members. When you move either the object code or the linked module along in the application life cycle, and if you move the corresponding BMC AMI listings in parallel, you will always have a source listing available for your BMC AMI tools.

The following figure shows a typical Source Code Management (SCM) promotion process:

When compiling a program, you save the listing in the repository (unless you use ESS). When you copy, move, or recreate (via a recompile) the LOADLIB member, for example, from test to QA, you would also copy, move, or recreate the BMC AMI listing member. The following figure shows these changes, where you contain the compile listing in BMC AMI Source Databases (DDIO) attached to Shared Directories (SHRDIR).

Important

You can configure Code Pipeline to treat the DDIO listing as one of the parts that the program generation process creates.

In this configuration, you would create a source listing repository corresponding to each of your LOADLIB.

For composite load modules that contain multiple compile units, you must correlate all the compile listings that make up the LOADLIB member. You must create and maintain a single-source listing repository corresponding to each of your LOADLIB. For COBOL (starting with release 5) and PL/I (starting with release 4.5), you can embed the listing into the LOADLIB member without using a Source Listing Repository. This is called Embedded Source Support (ESS).

The following figure illustrates Source Support with Embedded Source Support (ESS):

The following shows screenshots of Abend-AID, iStrobe, Strobe, and Code Coverage using the compiler listing.

Tip

To expand the image, click the required screenshot.

Source support during Abend-AID analysis

Abend-AID with/without source support

Indexing during iStrobe attribution

This section displays examples of indexing during iStrobe attribution.

iStrobe with and without indexing

Indexing during Strobe attribution

This section displays examples of indexing during Strobe attribution.

Strobe with and without indexing

Code Coverage statistics

This section displays examples of Code Coverage statistics.