Gathering initial impact analysis data

After source files have been uploaded and shared, the impact analysis administrator gathers and shares baseline dependency information.

Before you begin

Sharing source files for impact analysis

About this task

The impact analysis administrator submits the uploaded source code for compilation or assembly to generate initial impact analysis information. Because impact analysis data is derived from information provided by the compilers and assemblers, the source code must be processed with an appropriate language translator. The following compilers and assemblers support impact analysis data:
  • COBOL compilers:
    • IBM® Enterprise COBOL for z/OS®, Version 3 Release 4
    • IBM® Enterprise COBOL for z/OS®, Version 4 Release 1
    • IBM® Enterprise COBOL for z/OS®, Version 4 Release 2
  • PL/I compilers:
    • IBM® Enterprise PL/I for z/OS®, Version 3 Release 5
    • IBM® Enterprise PL/I for z/OS®, Version 3 Release 6
    • IBM® Enterprise PL/I for z/OS®, Version 3 Release 7
    • IBM® Enterprise PL/I for z/OS®, Version 3 Release 8
  • High Level Assemblers
    • IBM® High Level Assembler, Version 1 Release 5
    • IBM® High Level Assembler, Version 1 Release 6

The impact analysis information is stored in two VSAM key-sequenced data sets (KSDS) and is identified by the administrator in BCL or JCL. One of the data sets is used to store copy book or source file dependence information and the other one is used to store internal/external call information. These two data sets are referred to as the impact analysis data. Besides that, we also need to allocate another VSAM key-sequenced data set to store the index sequence number. The initial gathering of impact analysis data does not have to involve a full set of compilations, and a full set of compilations is probably not realistic or necessary with a very large number of files, some of which might be unlikely to change. If the initial impact analysis is for less than the full set, the query and rebuild requests are limited by the dependency information that has been collected.

Restriction: Queries for external call sources and symbols can help show possible relationships only. All current impact analysis information is derived from the compiler—not the linker. The linker is the final arbiter in determining relationships between invoking and invoked modules. If different versions of the same code are compiled and the results of these compilations captured in your impact analysis data, then the information from queries may show more than one source that contains the definition of an external symbol, or the place where the module is coded.

Procedure

  1. Optional: Allocate a sequential data set or PDS member with a fixed-block record format (RECFM=FB) and record length of 80 (LRECL=80).
    In this data set, create a list of the partitioned data set names to which the source files have been uploaded as described in Sharing source files for impact analysis. This data set is referred to as the library filter file. The following list is an example of entries in this file:
    ADMIN.PROJ1.COBOL.SRC
ADMIN.PROJ2.COBOL.SRC
ADMIN.ALLPROJ.PLI.SRC
ADMIN.PROJ1.COBOL.CPY
ADMIN.PROJ2.COBOL.CPY
ADMIN.PROJ8.PLI.INCLUDE
ADMIN.PROJ3.HLASM.SRC
ADMIN.PROJ3.HLASM.MACLIB
    Only resources contained in the data sets listed are added to the impact analysis data. If, for example, a COBOL source file contains copybooks from a library not listed in the library filter file, these copybooks will not be included in the impact analysis data.
    Note: As an alternative, you can list the partitioned data set names as an in-stream data set. See Sample JCL to compile COBOL source for impact analysis for an example.
  2. Allocate three VSAM KSDS. For the first one, allocate it with the primary key of 8 bytes at offset 0, a non-unique alternate key of 52 bytes at offset 8, and a second non-unique alternate index of 52 bytes at offset 60. For the second one, allocate it with the primary key of 8 bytes at offset 0, a non-unique alternate key of 52 bytes at offset 8, and a second non-unique alternate index of 32 bytes at offset 60. These two data sets contain the impact analysis data, where the dependency information is stored and managed. Allocate the third VSAM KSDS with the primary key of 9 bytes at offset 0.
    This data set contains the index sequence number. See Sample JCL to allocate the impact analysis data set for sample JCL for allocating these data sets.
  3. Compile your COBOL programs to capture dependency information in the impact analysis data defined in step 2
    For example, to compile a COBOL program and populate the impact analysis data with the dependency information, do the following (in addition to your site's normal COBOL compilation requirements):
    1. Specify compiler option ADATA.
    2. Specify a SYSADATA DD statement used by the compiler to write ADATA output.
    3. Add a step to invoke BCC2XML.
      Use the SYSADATA file defined above and specify a SYSIADSD DD statement for the output of BCC2XML.
    4. Add a step following the compile step to invoke BCCIAUPD.
      To bypass this step if the compilation returns a return code of 8 (severity E) or higher, specify COND=(8,LE) on the EXEC statement.
    See Sample JCL to compile COBOL source for impact analysis for an example of JCL for compiling COBOL source with these options.
  4. Compile your PL/I programs to capture dependency information in the impact analysis data defined in step 2
    For example, to compile a PL/I program and populate the impact analysis data with the dependency information, do the following (in addition to your site's normal PL/I compilation requirements):
    1. Specify compiler option XINFO(SYM).
    2. Specify a SYSADATA DD statement used by the compiler to write ADATA output.
    3. Add a step to invoke BCC2XML.
      Use the SYSADATA file defined above and specify a SYSIADSD DD statement for the output of BCC2XML.
    4. Add a step following the compile step to invoke BCCIAUPD.
      Use the SYSIADSD file defined above. To bypass this step if the compilation returns a return code of 8 (severity E) or higher, specify COND=(8,LE) on the EXEC statement.
    See Sample JCL to compile PL/I source for impact analysis for an example of JCL for compiling PL/I source with these options.
  5. Assemble your High Level Assembler programs to capture dependency information in the impact analysis data defined in step 2.
    For example, to assemble a High Level Assembler program and populate the impact analysis data with the dependency information, do the following (in addition to your site's normal High Level Assembler requirements):
    1. Specify assembler option ADATA.
    2. Specify a SYSADATA DD statement used by the assembler to write ADATA output.
    3. Add a step to invoke BCC2XML.
      Use the SYSADATA file defined above and specify a SYSIADSD DD statement for the output of BCC2XML.
    4. Add a step following the assembly to invoke BCCIAUPD.
      Use the SYSIADSD file defined above. To bypass this step if the assembly returns a return code of 8 (severity E) or higher, specify COND=(8,LE) on the EXEC statement.
    See Sample JCL to assemble High Level Assembler source for impact analysis for an example of JCL for assembling High Level Assembler source with these options.

What to do next

Using TSO Client for query and build requests or Using remote build for impact analysis queries