Managing builds with impact analysis

z/OS® Extensions provides impact analysis tools that you can use to manage COBOL, PL/I, and High Level Assembler (HLASM) builds.

z/OS Extensions uses information available from SYSADATA produced by z/OS COBOL and PL/I compilers and the High Level Assembler to determine dependencies for COBOL, PL/I, and assembler programs. This information is gathered during program compilations and assemblies and can be queried using TSO Client. Using this dependency information and TSO Client, you can do the following build management tasks:

Obtain a list of source files that need to be rebuilt. This list is generated from a list of modified COPY and INCLUDE files that have been identified by PDS member names qualified by PDS names.
Obtain a list of external entry point dependencies for source files.
Obtain a list of all files that have references to a given externally visible name.
Request that source files identified from these queries be recompiled.
Request the compile dependency list needed to compile selected source files.

Impact analysis provides the following set of queries:

Copybook to find Source Query - You can use this query to determine which source files are required to be recompiled when a set of copybooks has been modified.
Source to find Copybook Query - You can use this query to determine which copybooks are required in order to compile the specified set of source files.
Symbol to find Source Query - You can use this query to determine which source files contain the set of symbol names that are specified on this panel.
Source to find Symbol Query - You can use this query to determine which symbol names are referred to be source files that are specified on this panel.

Your impact analysis administrator is responsible for setting up the impact analysis data that is used in the queries. The data is collected from compilers that compiled the source file. The impact analysis data contains information about the pairings between the source file compiled and the files included for the compile. It also contains the same symbol information that the linker can use to perform caller/external-callee bindings to create a load module from the provided set of object modules.

The external entry symbol information is placed in the object modules by the compilers to assist the linker in performing its link-edit operations. The linker uses the external entry symbol information to locate the "definition" (or place) where the code of an external entry (that is, routine) is located and the place where the code is called. Both places reference the same symbol. In the resulting load module, the linker binds the caller code to the callee code by link-editing the original object module code. Thus, when the load module is executed, the call at the caller location will call the callee code.

Use cases for external call queries

Determining the impact of removing a function

A programmer becomes aware that a certain module produces a side effect. The module exists in a source file named IAADMIN.PROJECT.Dyymmdd.COMMON(PAYROLL).. In member PAYROLL is the module that can be invoked externally through the use of the external symbol PAYROLL. This can be determined by looking at the code. The module seems to open a side file and writes some information to it that does not seem to be directly related to the function of the module.

The programmer wants to look at all code that calls this module to see if any of the callers require that the module create the side file. If none of the callers need this side effect, then the programmer can safely remove it. If not, then some other measure needs to be taken.

One way to do this, for example, is to separate out the side effect so that its functionality is contained in its own externally callable module. Then whatever caller requires the side file can call this new module as well as the modified PAYROLL module. The modified PAYROLL module would no longer contain the side effect. All other programs that do not require the side effect remain the same as before.

To discover what source code contains invocations of the PAYROLL module, the programmer can enter the external symbol PAYROLL into the Symbol to find Source Query panel; the sources of interest are displayed on the Result of Source to find Symbol Query panel.

Determining the extent of a particular function

The programmer is interested in a general understanding of how the code in IAADMIN.PROJECT.Dyymmdd.COMMON(PAYROLL) works. The programmer would like to understand its overall structure to gain a better understanding of where a certain miscalculation could most likely have occurred. The programmer would like, of course, to look at the PAYROLL member source, but also needs to find the external source of any module that is executed by the PAYROLL code.

To discover this information, the programmer can specify the IAADMIN.PROJECT.Dyymmdd.COMMON(PAYROLL) information in the Source to find Symbol Query panel; the sources of interest are displayed on the Result of Source to find Symbol Query panel.

VSAM RLS for impact analysis

Before version 8.0, z/OS Extension has only supported VSAM non-RLS for impact analysis. Since version 8.0, it has started supporting both RLS and non-RLS VASM.

What is VSAM RLS?

VSAM RLS is another mode of managing buffer pools, which allows any number of users to share your existing VSAM spheres. It provides full data integrity (read and write). The serialization is at record level.

VSAM RLS does not introduce new types of VSAM clusters; rather, it introduces a new way of accessing existing data sets. Apart from the need to open data sets in RLS mode, the same VSAM record management interfaces (get, put, point, erase) are used.

Why RLS?: RLS allows concurrent access to your VSAM data sets at record level, while maintaining data integrity.

When should RLS be used?

For single-user use, VSAM non-RLS is recommended as it does not need system configuration changes. Only IA administrators have the authority to update and delete VSAM for single-user use; other general users only have read permissions.

For multiple-user use, VSAM RLS is recommended because, compared to VSAM non-RLS, VSAM RLS has better performance for concurrent access. General users as well as IA administrators have authority to update and delete VSAM for multiple-user use.

RLS restrictions

There are restrictions that need to be considered before implementing RLS.

To share a VSAM sphere under RLS, the sphere must be SMS managed.
IDCAMS currently does not have access to the control blocks in the SYSVSAM address space. You will not be able to use IDCAMS to obtain information pertaining to RLS.
Linear, keyrange, and temporary data sets are not supported under RLS.
Because the control block structure is shared, RLS does not use share options.
RLS does not support data striping.

Impact analysis tasks

The remaining topics in this section explain how to prepare for and accomplish impact analysis tasks. It shows impact analysis tasks by role: administrator and user.

Impact analysis administrator tasks
Configuring VSAM RLS for impact analysis (Optional, for VSAM RLS only): Describes how to set up VSAM RLS for impact analysis.
Sharing source files for impact analysis: Describes how to prepare source files for impact analysis.
Gathering initial impact analysis data: Describes how to perform an initial impact analysis to gather baseline information.
Updating an impact analysis: Describes how to update impact analysis data.
Deleting impact analysis data: Describes how to delete impact analysis data for source files no longer in use.
Submitting a build request for source programs: Describes how to submit a build request against impact analysis query results.

User tasks
Using TSO Client for query and build requests: Describes how to use TSO Client to submit impact analysis queries and rebuild requests.
Using remote build for impact analysis queries: Describes how to use Remote Build to submit impact analysis queries.