Using the Inventory Analyzer

Information on using the Inventory Analyzer to organize and classify software components
Endevor 18.1
The following article contains information on how to use the
CA Endevor
Inventory Analyzer to organize and classify your software components.
2
How to Use the Inventory Analyzer
Follow this process to organize and classify your software components:
Customize the Sample JCL
The first step when using the Inventory Analyzer is to customize the sample JCL (member BC1JANLZ in the
CA Endevor
JCL library) to meet your requirements.
Follow these steps:
  1. Create ANALYZE statements to let you select members for processing.
    • Determine which source and load libraries you want to analyze. You most likely will want to analyze production load, source, JCL, and any other libraries containing elements that lend themselves to use with
      CA Endevor
      . We recommend that you use load libraries whenever possible, as load modules are more reliable when determining element type and processor group.
    • Decide which members you want to analyze. You can use a name mask when specifying member names.
    You can assign specific values to symbolics which reflect the system and subsystem designations, as well as environment, CCID, and comment, at your site. Using this statement in conjunction with member name masking, you can create most of the SCL (load syntax) required for the load function.
    For more information about creating (coding) the ANALYZE statements, see How to Use Analysis Request Statements.
  2. Customize the Output Model Definition. The output model definition is used to generate SCL that you can use to load analyzed members into
    CA Endevor
    . The Inventory Analyzer contains a predefined output model definition. You can customize the output model definition, as necessary.
    You can create syntax to add to the SCL initially generated by the Inventory Analyzer. You can also replace the SCL.
  3. Decide which reporting level (summary, detail, or all) you want to use for the Inventory Analyzer reports. In most cases, the reports produced by the summary level should be sufficient for your needs.
  4. Customize the JCL to point to the
    CA Endevor
    libraries containing the analysis rules, the output model definition, and the input ANALYZE statements. The rules are divided into several members, one or more of which can be omitted (unless that member is required, as indicated in the following list). For example, if your site does not use DB2, you may want to omit that member.
    The following indicates how rules are grouped in the source library:
    • DEFINES
      Language Definitions (required)
    • NODBMS
      Batch (required)
    • DB2DBMS
      DB2 (optional)
    • IDMSDBMS
      IDMS (optional)
    • IMSDBMS
      IMS (optional)
    • TOTALDBM
      TOTAL (optional)
    • OTHERS
      OTHERS (required)
      A basic rule set is provided on your installation tape to analyze the majority of your current data (source, object, and load). Do not modify this rule set, except as specified in customizing the Inventory Analyzer. If you encounter source, object, or load data that cannot be classified by the Inventory Analyzer (as indicated by the Inventory Analysis reports), you can manually classify those modules.
  5. Submit the job with a valid jobcard.
How to Review the Output
During, and as a result of, processing, the Inventory Analyzer generates several reports. Review this output as it provides information that can impact load processing.
The most important information presented in the reports tells you the following:
  • How many members were analyzed.
  • How many members of each type and processor group were found. This information lets you define the appropriate inventory structures to
    CA Endevor
    for eventual loading.
  • Which members could not be classified. "Failure" SCL is written for those members that could not be uniquely classified. As much information as is available is provided in this SCL. You should classify these members manually, by editing the load SCL with the appropriate remaining values.
If load modules were examined, review the Load Module Summary Report to ensure that all modules contain the same link attributes. If there are load modules of the same type and processor group but with different attributes, the specified processor group may have to be classified into one or more separate processor groups, to accommodate the differences.
How to Use the Load Utility
You can use the Load Utility to place analyzed elements into
CA Endevor
. This utility automatically loads the members from their existing libraries into the inventory structure and, optionally, footprints the corresponding output members. The SCL input to the Load Utility is created by the Inventory Analyzer and written to the DDname specified on the output model definition. For more information, see
Customizing the Inventory Analyzer
.
You need to decide whether you want to use this capability at this time.
If you want to use the Load Utility, you must first do the following:
  • Define the appropriate inventory structures.
  • Create the appropriate processors for the different types from within
    CA Endevor
    .
How to Use Analysis Request Statements
The Inventory Analyzer request processing uses the following four types of syntax statements:
  • ANALYZE statements. These are the only request statements executed by the Inventory Analyzer. Use ANALYZE statements to select members for analysis and to specify the libraries to be referenced during analysis.
  • SET statements. These are global default statements that establish values for subsequent ANALYZE statements. If a certain parameter is required (or used) but not coded in an ANALYZE statement, the Inventory Analyzer looks for that information in a previous SET statement.
  • CLEAR statements. These statements clear the information designated by a related SET statement.
  • EOF (EOJ) statement. This statement instructs the Inventory Analyzer to stop parsing the request syntax at a point; that is, request processing is terminated. No other requests are read from the request input file once the EOF (EOJ) statement is encountered.
How the Analyze Statement Works
The ANALYZE statement selects members from the specified source (FROM) and executable (USING) data sets (one or both can be coded). Type and processor group are then resolved, using a rule-based scanning technique.
This figure illustrates the syntax for the ANALYZE statement:
►►─ANAlyze-MEMber──
member-name
──┬──────────────────────────┬─────────────► └─┬─THRough──┬─
member-name
─┘ └THRu──────┘ ►──┬───────────────────────────────┬─────────────────────────────────────► └─FROm DSName──('
dataset-name
')─┘ ►──┬────────────────────────────────┬────────────────────────────────────► └─USIng DSName──('
dataset-name
')─┘ ►──┬────────────────────────────────────────────────┬───.───────────────►◄ │ ┌──,────────────────────────────┐ │ └─ASSign──(─▼──
symbol-name1
=
symbol-value1
─┴─) ─┘
The following describes the clauses in the ANALYZE statement:
  • ANALYZE MEMBER
    member-name
    Required. Indicates the members to be analyzed. Member names can be up to ten characters in length. You can code an explicit member name to process just one member, or you can use a name mask (
    *
    at the end of the member name), a place holder (? within the member name), or both, to process multiple members.
  • THROUGH (THRU)
    member-name
    Optional. Indicates that a range of members are to be analyzed, beginning with the member coded in the ANALYZE MEMBERS clause up to and including the member(s) specified in this clause. You can use a name mask and place holder with the THROUGH member name.
  • FROM DSNAME (
    dataset-name
    . . .)
    Required. Indicates the location of the members being analyzed. If the FROM clause is not coded in the request, the Inventory Analyzer looks for a previously coded SET FROM clause.
    The data sets can be any combination of PDS, PDSE, CA Librarian, or CA Panvalet libraries. Sequential data sets are not supported.
    If you specify the parameter SOURCE OPTIONAL in the execution JCL, you do not need to code FROM or SET FROM information. For more information, see How the SET ASSIGN Statement Assigns the Default CCID and Comment and How to Use Additional SET ASSIGN Statements within Requests.
    For more information about coding data set names in this clause, see How to Enter Information in the Data Set Clauses.
  • USING DSNAME (
    dataset-name
    . . .)
    Optional. Indicates the location of the outputs directly associated with the member being analyzed. If a USING DSNAME clause is not coded in the request, the Inventory Analyzer looks for a SET USING DSNAME clause. A USING data set is optional, so you do not have to enter USING DSNAME data.
    The data sets can be any combination of object or load libraries. The following are the recommended guidelines:
    • You specify load libraries before object libraries when both types of libraries are present. A better analysis can be performed using load libraries.
    • The source and executable member names are different, but follow standard naming conventions. You can customize an exit specific to the Inventory Analyzer to accommodate the situation. For more information, see
      Customizing the Inventory Analyzer
      .
    For more information about coding data set names in this clause, see How to Enter Information in the Data Set Clauses.
  • ASSIGN symbol-name=
    symbol-value
    Optional. Indicates a user-defined symbolic to be used in building SCL, along with the value associated with that symbolic. Specify as many user-defined symbolics that you need. You can assign values to one or more of the following symbolics:
    • ENV - to define an environment.
    • SYS - to define a system.
    • SBS - to define a subsystem.
    • CCID - to specify a CCID.
    • Comment - to specify a comment.
    When building SCL to load the data classified by the Inventory Analyzer, an output model definition template is used. When a user-defined symbolic is found in the template, the Inventory Analyzer looks for a corresponding symbol-name in the ASSIGN clause of the request. Before writing the SCL, the symbolic is replaced with the appropriate value, as defined by the ASSIGN clause.
How to Enter Information in the Data Set Clauses
Use the following rules when you enter the data set information in the FROM DSNAME and USING DSNAME clauses:
  • Specify one or more data sets, up to 1000 names. If you enter multiple data sets, separate the names with blanks and enclose all names in a single set of parentheses. If you code only one data set, you do not have to use parentheses.
  • Enclose each data set name in single or double quotes, and use the same convention for each data set name in the list. Be sure each data set is cataloged in the system catalog.
    The Inventory Analyzer checks each data set for members matching the selection criteria. The order in which the data sets are specified becomes the search order. If a member is found in more than one data set, the Inventory Analyzer selects the first occurrence of that member.
This information also applies to the SET FROM DSNAME and SET USING DSNAME statements.
How the Inventory Analyzer Analyzes All Members
In the following example, all members in the FROM and USING libraries (PROD.SOURCELIB and PROD.LOADLIB, respectively) are be analyzed. The same member names must exist in both libraries. If the member names are not the same in both libraries, use exit C1BM7XIT, which lets you specify an output library member for analysis when that member name differs from the input to source member name.
ANALYZE MEMBER * FROM DSN 'PROD.SOURCELIB' USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='GENERAL' SBS='GENERAL' CCID='LOAD' COMMENT='INITIAL
CA Endevor
LOAD'
The Inventory Analyzer first classifies members in the load library. Members classified successfully as a result of the analysis of PROD.LOADLIB are bypassed in PROD.SOURCELIB. That is, those members are not classified again in the source library. The load SCL created, however, loads the appropriate members into
CA Endevor
from PROD.SOURCELIB.
The ASSIGN statements assign the specified values to the appropriate variables in the output model definition. The SCL generated from this example can be used to load the analyzed members into the following
CA Endevor
location: environment PROD, system GENERAL, and subsystem GENERAL. The CCID LOAD and the comment 'INITIAL ENDEVOR LOAD' are assigned to each member.
How the Inventory Analyzer Analyzes All Members Using Different Selection Criteria
The following example is similar to the previous example in that the same libraries are to be analyzed and the same symbolic values are assigned. However, the member selection criteria are different (note the ANALYZE MEMBER . . .THROUGH . . .clause):
ANALYZE MEMBER FI?A?C THROUGH FI?D?C FROM DSN ('PROD.SOURCELIB' 'PROD.PANLIB') USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='FINANCE' SBS='ACCTREC' CCID='LOAD" COMMENT='INITIAL
CA Endevor
LOAD'
Members are selected for analysis using the following criteria:
  • The first two characters of the member name must be FI.
  • The third and fifth positions of the member name, as indicated by the placeholder (?), may contain any valid character (A-Z, 0-9, @, #, $).
  • The fourth position of the member name can only be A, B, C, or D. Any other character in this position is not accepted.
  • The final character of the member name must be C.
The following member names would be selected for analysis:
  • FINARC
  • FI5C6C
  • FIND#C
Names such as FINAR or FIGARC are not selected.
How the Inventory Analyzer Analyzes Specific Members
In this example, only those members whose names begin with FINAR are analyzed.
ANALYZE MEMBER FINAR* FROM DSN ('PROD.SOURCELIB' 'PROD.PANLIB') USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='FINANCE' SBS='ACCTREC' CCID='LOAD" COMMENT='INITIAL
CA Endevor
LOAD'
The ASSIGN statements indicate the values to be assigned to the variables in the output model definition. All members whose names begin with FINAR can be loaded into environment PROD, system FINANCE, and subsystem ACCTREC in
CA Endevor
, and are assigned a CCID of LOAD and the comment 'INITIAL ENDEVOR LOAD'.
How Set Statements Work
SET statements are global default statements that establish values for subsequent requests. SET statements are never executed.
A SET statement establishes default parameters for specific items that are omitted from subsequent ANALYZE requests. If a parameter is required (or used) but not coded in a request, the information can be obtained from a previous, corresponding SET statement.
For example, if you want to use one FROM data set for several requests, you can specify that data set by:
  • Coding the same FROM DSNAME clause in every request.
  • Entering a SET FROM DSNAME statement. The data set specified is applied to every ANALYZE request that follows that SET statement.
  • "Reissuing" a SET statement to change the default values as often as you need. SET statements remain in effect until another (similar SET statement or a related CLEAR statement) is encountered or processing ends.
If you code the SOURCE OPTIONAL parameter on the execution JCL, you do not need to include FROM information in the ANALYZE request.
How to Apply SET Statements
SET information applies only if similar information is not entered in the request. If you enter similar information in the ANALYZE request, the SET value is ignored.
For example, you code a SET FROM DSNAME statement. In the first four ANALYZE requests following the SET statement, you do not enter a FROM data set. In the fifth request, you enter a data set name. The Inventory Analyzer applies the data set name from the SET statement for the first four requests. For the fifth request, however, the Inventory Analyzer uses the value coded in the ANALYZE request. The value in the SET statement is ignored.
How the SET ASSIGN Statement Works
This figure shows the SET ASSIGN statement:
┌──,────────────────────────────┐ ►►──SET ASSign──(─▼──
symbol-name1
=
symbol-value1
─┴─)───.───────────────►◄
SET ASSIGN applies to each request that uses, but does not contain, an ASSIGN clause. The SET ASSIGN statement remains in effect until the system encounters another SET ASSIGN statement with the same symbol or a CLEAR ASSIGN statement, or processing ends.
How the SET FROM/USING Statement Works
This figure shows the SET FROM/USING statement:
┌─,──────────────┐ ►►──SET ┬─FROm──┬──DSName──▼─'
dataset-name
'─┴──.────────────────────────►◄ └─USIng─┘
SET FROM and SET USING apply to each request that uses, but does not contain, a FROM DSNAME or USING DSNAME clause respectively. The SET FROM statement remains in effect until the system encounters another SET FROM statement or a CLEAR FROM statement, or processing ends. Similarly, the SET USING statement remains in effect until the system encounters another SET USING statement or a CLEAR USING statement, or processing ends.
The rules and processing for data sets apply to the data sets coded in these statements. For more information, see How the Inventory Analyzer Analyzes All Members.
How the SET REPORT LEVEL Statement Works
The following is the SET REPORT LEVEL statement:
┌─DETail───┐ ►►──SET──REPort──LEVel──├─SUMmary──┤──.──────────────────────────────────►◄ └─ALL──────┘
SET REPORT LEVEL is a control card that lets you select the amount of information that you want to receive as part of your reports (that is, which reports you want to see). If you want to use this statement, code it with the ANALYZE request.
There are three levels (options) of information available. Each level provides a different set of reports, as follows:
  • Summary
    Parameter Syntax, Request Syntax, Output Model Definition, Final Request Interpretation, Analysis Summary Report, Load Module Summary Report, Execution Summary Report.
  • Detail
    Default. The reports listed in Summary, as well as the Request Processing report.
  • All
    The reports listed in Summary, as well as the Rule Syntax, Rule Analysis, and Final Rule Interpretation reports.
For more information about reports, see
Using the Inventory Analyzer Reports
.
How the SET ASSIGN Statement Assigns the Default CCID and Comment
Use the following SET ASSIGN statement to assign the default CCID and comment to each member analyzed, across all requests. This statement is based on the requests in How the Inventory Analyzer Analyzes All Members, How the Inventory Analyzer Analyzes Specific Members, and How the Inventory Analyzer Analyzes All Members Using Different Selection Criteria.
┌──,────────────────────────────┐ ►►──SET ASSign──(─▼──
symbol-name1
=
symbol-value1
─┴─)───.───────────────►◄
Using this statement, you could enter the three ANALYZE requests as follows:
SET ASSIGN CCID='LOAD' COMMENT='INITIAL
CA Endevor
LOAD'. ANALYZE MEMBER * FROM DSN 'PROD.SOURCELIB' USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='GENERAL' SBS='GENERAL' . ANALYZE MEMBER FINAR* FROM DSN ('PROD.SOURCELIB' 'PROD.PANLIB') USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='FINANCE' SBS='ACCTREC' . ANALYZE MEMBER FI?A?C THROUGH FI?D?C FROM DSN ('PROD.SOURCELIB' 'PROD.PANLIB') USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='FINANCE' SBS='ACCTREC'
How to Use Additional SET ASSIGN Statements within Requests
In the previous example, the SET ASSIGN statement applied to all three ANALYZE requests. In that example, the FROM and USING data sets in the second and third requests are the same. The ASSIGN information is also the same. You can use additional SET ASSIGN statements within the requests to set the values, as follows:
SET ASSIGN CCID='LOAD' COMMENT='INITIAL
CA Endevor
LOAD' ANALYZE MEMBER * FROM DSN 'PROD.SOURCELIB' USING DSN 'PROD.LOADLIB' ASSIGN ENV='PROD' SYS='GENERAL' SBS='GENERAL' . SET FROM (DSN 'PROD.SOURCELIB' 'PROD.PANLIB') SET USING DSN 'PROD.LOADLIB' SET ASSIGN ENV='PROD' SYS='FINANCE' SBS='ACCTREC' ANALYZE MEMBER FINAR* . ANALYZE MEMBER FI?A?C THROUGH FI?D?C .
The CCID and comment assigned at the beginning of the series of requests are still applied to the second and third requests. Remember that all SET statements remain in effect until another statement (a similar SET statement or a CLEAR statement) is encountered, or processing ends.
How Clear Statements Work
CLEAR statements clear the information designated by a related SET statement. When you need to remove information established in a SET statement, code a parallel CLEAR statement. The CLEAR statement remains in effect until a new, related SET statement is encountered or processing ends.
CLEAR statements apply only to SET statements. Similar information entered in the ANALYZE request is not affected by a CLEAR statement.
How the CLEAR ALL Statement Works
This figure shows the CLEAR ALL statement:
►►──CLEar ALL──.────────────────────────────────────────────────────────►◄
CLEAR ALL clears all information established by all previous SET statements. Make sure that you specify all required information in subsequent ANALYZE requests, or code new SET statements for the required information.
How the CLEAR ASSIGN Statement Works
This figure shows the CLEAR ASSIGN statement:
►►──CLEar ASSign──.─────────────────────────────────────────────────────►◄
CLEAR ASSIGN clears all symbolics entered in previous SET ASSIGN statements.
How the CLEAR FROM/USING Statement Works
This figure shows the CLEAR FROM/USING statement:
►►──CLEar──┬─FROm───┬──.─────────────────────────────────────────────────►◄ └─USIng──┘
CLEAR FROM and CLEAR USING clear information entered in previous SET FROM and SET USING statements.
How the EOF (EOJ) Processing Statement Works
The EOF or EOJ (End of File or End of Job) statement instructs the parser to stop parsing the syntax at a point. This statement eliminates the need to manually delete any requests you do not want performed.
This figure shows the EOF (EOJ) statement:
►►──┬─EOF─┬──.───────────────────────────────────────────────────────────►◄ └─EOJ─┘
Code EOF or EOJ, followed by a period. Use the term with which you are most comfortable.
How Analyze Requests are Processed
This table explains how ANALYZE requests are processed.
Sequence
Condition
Action
First
None
Searches for specified members in the FROM library list, if that library is specified. Each occurrence of the member is noted in the Request Processing report. The first occurrence of the member can be used later for source scanning.
If the member is not located in any FROM library, the request is terminated.
Note:
If you specify the parameter SOURCE OPTIONAL in the execution JCL, you do not have to code FROM or SET FROM information. For more information, see
Understanding the Execution JCL
.
Second
None
Searches for the member in a USING library, if that library is specified. Each occurrence of the member is noted in the Request Processing report. The first occurrence of the member is used for executable scanning.
If the member is not located in any USING library, the request is terminated.
If no USING library is specified, executable scanning is not performed.
Note:
We strongly recommended that libraries be specified for all software components that have executable forms. The Inventory Analyzer can classify components based on executables more accurately than components based on source.
Third
If the request is unsuccessful
Formats and prints information about the members' source and output. This information appears in the Request Processing report.
Third
If the request is successful
Writes a line to the Analysis Summary Report indicating the member analyzed, what libraries were used for the analysis, and the type and processor group selected (if unique).