Load Utility

2
18-0
2
The
CA Endevor
Load Utility enables you to load one or more members (elements), from data sets external to
CA Endevor
, directly to any stage that is defined within a 
CA Endevor
 environment. Using this utility, you can quickly populate
CA Endevor
environments without the need to reassemble or recompile your programs. And, you can date/time stamp--or footprint--all corresponding library members in your source, object, and load libraries as the members are loaded.
Security is invoked when the Load Utility is executed. If using ESI, a PRIMARY_OPTIONS call is issued. For this ESI call, the MENUITEM is LOAD.
Before using the
CA Endevor
Load Utility, the inventory structures that you want to populate within
CA Endevor
must be defined.
For more information about defining inventory structures, see Administrating.
This section describes the
CA Endevor
Load Utility request syntax, detailing the structure of and rules concerning the LOAD MEMBER command. The final section provides a working example of the Load process, on a step-by-step basis.
LOAD requests can be created manually, using the LOAD request syntax, or can be generated by the
CA Endevor
Inventory Analyzer as part of the analysis process. The method used is at your discretion; the results of the load processing are the same.
The
CA Endevor
Load Utility is simple to operate and involves two basic steps:
  • Creating your requests
    The Load Utility automatically validates each request before it is executed.
  • Reviewing the reports produced
    Reports are produced during and after execution to inform you about what has occurred.
How to Create LOAD Requests
LOAD requests indicate those members, from designated data sets, that are to be loaded to specific
CA Endevor
locations. A sample request is shown as follows:
LOAD MEMBER FINARP00 THRU FINARP99  FROM DSNAME  'PROD.SRCLIB'  TO ENVIRONMENT 'DEMO' SYSTEM 'FINANCE' SUBSYSTEM 'ACCTREC'    TYPE    'COBOL' STAGE 'P'  OPTIONS    CCID 'LOAD'    COMMENT 'AUTOMATED CA SCMMF IMPLEMENTATION    PROCESSOR GROUP 'COBNBL01'  FOOTPRINT 'PROD.LOADLIB'    .
This request tells the Load Utility to perform the following actions:
  • Load a range of members, beginning with FINARP00 up to and including FINARP99.
  • Load only the members from data set PROD.SRCLIB.
  • Load the members to the
    CA Endevor
    location specified by the TO information.
  • Create version 1.0 of an element in
    CA Endevor
    , for each member that matches the criteria specified.
  • Associate with each element the indicated CCID, comment, and processor group.
  • Footprint each applicable member (that is, member for which a match is found in the footprint library) in the library specified by the FOOTPRINT clause.
After all LOAD requests are coded, and before they are executed,
CA Endevor
validates both the syntax and the content of each request. Syntax validation ensures that the request syntax is correct. Content validation ensures that the data sets specified do exist and that the
CA Endevor
location specified is valid.
LOAD Request Reports
As request execution progresses, the following reports are produced:
  • The
    CA Endevor
    Load Execution Log
  • The
    CA Endevor
    Data Validation Report
  • The
    CA Endevor
    Load Execution Report
  • The
    CA Endevor
    Load Summary Report
The first two reports indicate syntax and data errors, respectively. The last two reports provide detail and summary information for each request in the input data set.
If a member specified in the LOAD request is found in the
CA Endevor
TO location indicated, creating duplicate members, the LOAD request for that member is bypassed. The occurrence of duplicate members can be caused by overlapping Load requests; that is, when two requests involve one or more of the same members. Occasionally, duplicate members may be the result of repeated execution of the same Load syntax. Duplicate member warning messages are issued when either situation occurs.
CA Endevor
Load Utility Requests
This section describes the syntax you use to load elements into environments predefined in
CA Endevor
. The Load process is described in the next section. That discussion includes syntax examples and explanations and illustrations of the reports you can use to review what you have coded.
Load Utility Statements
The Load Utility uses three types of statements:
  • The ACTION statement is always
    LOAD MEMBER
    . This is the only statement that the Load Utility executes.
  • SET statement establishes default values for subsequent action statements. These statements are never executed by the Load Utility.
  • CLEAR statements clears the information designated by a related SET statement. These statements are never executed by the Load Utility.
The remainder of this section illustrates the LOAD statement syntax and explains all required and optional clauses within the statement. A brief overview of the reports produced by the Load Utility is provided also. Read this section carefully to gain a full understanding of the syntax. Learning and using this syntax can be an invaluable and powerful tool.
Load Request Syntax
????LOAD MEMber??
member
???????????????????????????????????????????????????????????????????                         ????THRough???
member
??                           ??THRu????? ???FROm??DSName??
dsname
??TO??ENVironment??
env-name
???????????????????????????????????????? ???SYStem??
sys-name
??SUBsystem??
subsys-name
??TYPe??
type-name
?????????????????????????????? ???STAge??
stage-id
??
?
????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????????????    ??OPTion??¤????????????????????????????????????¤??                ??CCID??
ccid
?????????????????????                ??COMment??
comment
???????????????                ??PROcessor GROup??
group-name
???? ???????????????????????????????????????.??????????????????????????????????????????????????    ?               ???,????????    ?    ??FOOtprint??(?????
dsname
?????)??
Load Request Rules
The rules pertaining to each clause in the syntax are listed as follows. Required and optional clauses are noted, as well as any other requirements specific to this action.
Load Request Required Clauses
Required clauses are listed as follows:
  • LOAD MEMBER
    member
    Indicates the member(s) you want to load. The member name can be up to
    10
    characters in length.
    You must code this clause first
    , immediately followed by the THROUGH clause if you decide to use it. Otherwise, you receive an error message.
    You can code an explicit member name to load just one member, or you can use a name mask (an
    *
    alone or at the end of the partial member name) and/or a place holder (a 
    ?
    within the member name) to load several members.
  • FROM DSNAME
    dsname
    Indicates the location of the member(s) being loaded. If you do not specify FROM information here, a SET FROM clause with the required information must have been previously code.
    The FROM data set can be a partitioned data set (PDS or PDS/E), or a CA Librarian or CA Panvalet library. It cannot be a load library, however; load library members are never loaded to a 
    CA Endevor
     environment. You receive a validation error message if you attempt to do this.
    You must code an explicit data set name. If the data set name contains a period, be sure to enclose the name in single or double quotes, as follows:
'TEST.LIB' or "TEST.LIB"
If you want the member(s) in this FROM data set to be footprinted, you must code this data set name in the FOOTPRINT clause.
“TO “ENVIRONMENT env-name
“SYSTEM sys-name
“SUBSYSTEM subsys-name
“TYPE type-name
“STAGE stage-id
Indicates the
CA Endevor
location to which the member(s) will be loaded. If you do not provide (all) TO information here, a SET TO clause with the required data must have been previously coded.
You must specify full environment, system, subsystem, type, and/or processor group names, up to eight characters each; you cannot use a name mask or a place holder when defining any portion of the
CA Endevor
location.
STAGE is optional in the TO field. If you do not specify a stage ID in this clause or in the SET TO statement, the ID for Stage 2 is used.
Load Request Optional Clauses
Optional clauses are listed as follows:
  • THROUGH (THRU)
    member
    Indicates that a range of members should be loaded, beginning with the member(s) specified in the LOAD MEMBER clause, up to and including the member(s) specified in this clause.
    You can specify an explicit THROUGH member name, or you can use a name mask (an
    *
    alone or at the end of the partial member name) or a place holder (a 
    ?
    within the member name) in the name. You can also combine the 
    ?
    and the
    *
    in the THROUGH member name.
    If you use the THROUGH clause, it must immediately follow the LOAD MEMBER clause. Otherwise, you receive an error message.
  • OPTIONS
    • CCID ccid
      You can specify a CCID to group related modules that are being loaded, for reporting purposes. CCIDs can be up to 12 characters in length.
    • COMMENT comment
      You can specify a comment to further define the member(s) being loaded. Comments can be up to
      40
      characters in length, and must always be enclosed in quotes.
    • PROCESSOR GROUP group-name
      You can designate a specific processor group, up to
      8
      characters, to be used to generate the element once it is loaded. The value specified here overrides the default processor group currently found on the element's type record.
    Be sure the processor group you code is a valid processor group within the element type record being loaded. Otherwise, you receive an error message.
    If you leave this field blank, the system defaults to the processor group defined on the element's type record.
    • FOOTPRINT ('dsname', 'dsname')
      Indicates the source, object, or load libraries in which the Load Utility looks for the member(s) specified. When a match is found, that member is footprinted in that data set.
      The footprint DSN clause should not be either a base or delta library.
Set Statements
SET statements are global default statements that establish values for subsequent request statements. SET statements are never executed.
A SET statement establishes default values for keyword parameters, such as FROM or TO. If information is required and not specifically coded within a LOAD request, a corresponding SET statement must precede that request. If you code the LOAD statement first, without required information, you receive an error message.
References are made throughout this section to the “actual LOAD statement.” An actual LOAD statement begins with the word
LOAD
and ends with a
period
, and includes all data between these two items. If you code a SET statement within the actual LOAD statement, you receive an error message.
Each SET statement remains in effect until:
  • You code specific values in the actual LOAD statement, which override the corresponding values in the SET statement.
  • CA Endevor
    encounters another, like SET statement, which overrides the existing SET statement.
  • CA Endevor
    encounters a CLEAR statement for that particular SET statement.
  • Processing for the job ends.
The following SET statements can be used with the LOAD action:
SET FROM DSNAME SET TO SET OPTIONS SET FOOTPRINT
SET FROM Statement
The syntax of SET FROM statement is shown as follows:
  • SET FROM DSNAME
    dsname
    The data set name specified in the SET FROM DSNAME statement indicates the location of all members to be loaded, for all subsequent LOAD requests. This data set applies until another SET FROM DSNAME statement, a CLEAR ALL statement, or a CLEAR FROM statement is encountered, or until processing ends. Or, you can override the SET value for a particular member(s) by coding a FROM data set in the actual LOAD statement.
    The name specified must be a full data set name. If the data set name contains an embedded period, the name must be enclosed in single or double quotes.
SET TO Statement
The syntax of the SET TO statement is shown next:
SET TO ENVIRONMENT 
env-name
    SYSTEM 
sys-name
    SUB
SYSTEM
 
subsys-name
    TYP
E
 
type-name
    [STA
GE
 
stage-id]
.
The information specified in the SET TO statement indicates the
CA Endevor
location to which all members in the subsequent LOAD requests will be loaded. This location applies until another SET TO statement, a CLEAR ALL statement, or a CLEAR TO statement is encountered, or until processing ends. Or, you can override any portion (or all) of the
CA Endevor
location within the actual LOAD statement.
You must specify full environment, system, subsystem, type, and/or processor group names; you cannot use a name mask or a place holder when defining any portion of the
CA Endevor
location. If you do not specify a stage ID in the SET TO clause or in the actual LOAD statement, the system uses the ID for Stage 2.
With the exception of the stage ID, any location information you do not specify in a SET TO clause must be coded in the LOAD request.
SET OPTIONS Statement
The syntax of the SET OPTIONS statement is shown next:
SET  OPTIONS CCID 
ccid
      COMMENT 
comment
      PROCESSOR GROUP 
group-name
.
The SET OPTIONS statement allows you to specify that a particular CCID, comment (enclosed in quotes), and/or processor group be applied to all members to be loaded, for all subsequent LOAD requests. These options are in effect until another SET OPTIONS statement, a CLEAR ALL statement, or a CLEAR OPTIONS statement is encountered, or until processing ends. Or, you can override any of the SET options by coding a different, corresponding value(s) in the actual LOAD statement.
OPTIONS are not required in LOAD actions. Therefore, you are not required to have previously coded a SET OPTIONS statement if you did not specify OPTIONS information in the LOAD request.
SET FOOTPRINT Statement
The syntax of the SET FOOTPRINT statement is shown next:
  • SET FOOTPRINT (
    'dsname', 'dsname', 'dsname'
    )...
    The SET FOOTPRINT statement provides the name(s) of the library(ies) in which corresponding member(s) in the subsequent LOAD statements will be footprinted. A corresponding member is one for which a match is found in the libraries designated in the SET FOOTPRINT statement.
    If you use this statement, you must specify at least one data set (library) name. This data set(s) is used until another SET FOOTPRINT statement, a CLEAR ALL statement, or a CLEAR FOOTPRINT statement is encountered, or until processing ends. Or, you can override the information in the SET FOOTPRINT clause by coding a data set name(s) in the actual LOAD statement. If you code multiple data set names, they must be enclosed in a single set of parentheses, and separated by either blanks or commas.
    If you do override the SET FOOTPRINT clause, corresponding members are footprinted only in the library(ies) indicated in the actual LOAD statement. For example, if your SET FOOTPRINT statement lists three libraries and you specify a FOOTPRINT clause in the actual LOAD statement with only one library indicated, corresponding members are footprinted only in that one library. If you want to change just one library name out of the three listed, you must specify the new library name along with the other two library names in either a different SET FOOTPRINT statement or in the FOOTPRINT clause of the actual LOAD statement.
    To override the SET FOOTPRINT statement and code the following clause, footprinting will not occur:
FOOTPRINT '  ' .
CA Endevor
interprets the clause as having no library indicated. If no library is designated, footprinting cannot take place. And, the SET FOOTPRINT statement cannot be in effect because the FOOTPRINT clause is specified in the LOAD command, thereby overriding that statement.
Footprint information is not required in Load actions. Therefore, you are not required to have a SET FOOTPRINT statement if you did not specify footprint information in the LOAD request.
Clear Statements
A CLEAR statement clears the information that is designated by a SET statement. When you are working with a series of requests and need to remove the data established in a SET statement, simply code a parallel CLEAR statement. The CLEAR statement remains in effect until a new, related SET statement is encountered or until processing ends.
CLEAR statements apply only to SET statements. Similar information entered in a LOAD request is not affected by a CLEAR statement.
The following CLEAR statements can be used with the LOAD action:
CLEAR ALL CLEAR FROM CLEAR TO CLEAR OPTIONS CLEAR FOOTPRINT
Each of these is discussed briefly as follows.
  • CLEAR ALL
    CLEAR ALL clears all information established by all previous SET statements. Be sure that you either specify all required information in all subsequent LOAD statements or code new SET statements for all required information.
  • CLEAR FROM
    CLEAR FROM clears all SET FROM information previously coded.
  • CLEAR TO
    CLEAR TO clears all SET TO information previously coded.
  • CLEAR OPTIONS
    CLEAR OPTIONS clears all SET OPTIONS information previously coded.
  • CLEAR FOOTPRINT
    CLEAR FOOTPRINT clears all SET FOOTPRINT information previously coded.
Load Utility Reports
The following reports are produced by the
CA Endevor
Load Utility after execution of the JCL:
  • CA Endevor
    Load Execution Log
  • CA Endevor
    Data Validation Report
  • CA Endevor
    Load Execution Report
  • CA Endevor
    Load Execution Summary
Each of these reports is explained in the following sections.
For examples on their use, see Example of the Load Utility Process.
Several
CA Endevor
panels and reports, mostly related to footprints, reflect the use of the
CA Endevor
Load Utility to populate environments. A load indicator ?? the field
LD
which appears as part of the footprint ?? indicates whether a particular element/member was loaded into
CA Endevor
(
Y
, yes) or generated within
CA Endevor
(
blank
, no).
The panels affected include the
CA Endevor
-Footprint Display, as well as any other panels that show footprint information.
The reports affected include the following (in assembler):
  • CONRPT80--the Library Member Footprint Report
  • CONRPT81--the Library CSECT Listing
  • CONRPT82--the Library ZAPped CSECT Profile
  • CONRPT83--the Footprint Exception Report
Load Execution Log
The
CA Endevor
Load Execution Log displays each LOAD request in the input data set exactly as you coded it. An input data set can contain one request with several members or several requests of one member each, or any combination of the two.
The log lists all requests coded, including requests containing invalid data. In addition, any syntax errors found by the parser are flagged. A brief explanation of the error appears on the line immediately following the error, denoted by the prefix
BSTPPARS
.
Data Validation Report
The system automatically checks the content of each LOAD request to ensure that both the input data sets and
CA Endevor
locations specified are valid. The
CA Endevor
Data Validation Report is produced only when invalid information is found in one or more requests. If there are no data errors at all, throughout all the LOAD requests, you do not receive this report.
For each invalid request, the report lists the LOAD request number (automatically assigned by the system), the invalid data, and the total number of data errors found in that request. A final line at the end of the report indicates the total number of requests that contained errors.
Load Execution Report
The
CA Endevor
Load Execution Report is produced when LOAD execution begins. LOAD execution takes place after syntax validation and content validation have determined that there are no syntax and data errors in any of the requests.
This report expands the LOAD request, reformatting the clauses into a standard structure--which is the structure shown in the “Load Request Syntax” section.. All relevant SET information is applied to the LOAD statement, and appears in the printed syntax.
The remainder of the report, for each request, lists informational messages that relate what happens as each step of the load process occurs. Be sure to read these messages, as error and problem conditions are noted here also.
Especially when processing large quantities of LOAD requests and/or members, you should use this report in conjunction with the
CA Endevor
Load Execution Summary. Using this combination of reports facilitates looking for, and finding, those requests that may contain processing errors.
Load Execution Summary
The
CA Endevor
Load Execution Summary, like the
CA Endevor
Load Execution Report, is produced when LOAD execution begins. This report summarizes the results of processing the input data set and lists the following information for each LOAD request:
  • The return code for the request.
  • The total number of members requested.
  • The total number of members in the request that were successfully loaded.
  • The total number of members in the request that failed the loading process.
  • The number of members in the request that were footprinted. (Note that only members that are successfully loaded can be footprinted.)
  • The number of successfully loaded members that failed the footprinting process.
It is beneficial to use this report in combination with the
CA Endevor
Load Execution Report. You can use the Execution Summary to quickly find any requests with errors, then refer back to the more detailed Execution Report to determine where and when the error occurred.
Example of the Load Utility Process
This section provides a working example of the
CA Endevor
Load Utility process. This example begins with a LOAD request being entered into
CA Endevor
, and proceeds through a review of the JCL generated and the reports produced by the utility.
How to Load the Request
Code the LOAD requests into
CA Endevor
. Remember that you can code one request to load several members, several requests to load one member each, or any combination in between.
In the following example, you enter a LOAD request using the THROUGH clause, to load a range of members (
FINARP00 through FINARP99
) into
CA Endevor
:
LOAD MEMBER FINARP00 THROUGH FINARP99  FROM DSNAME 'PROD.SRCLIB'  TO ENVIRONMENT 'DEMO' SYSTEM 'FINANCE' SUBSYSTEM 'ACCTREC'    TYPE 'COBOL' STAGE 'P'  OPTIONS CCID 'LOAD '     COMMENT 'AUTOMATED CASCMMF IMPLEMENTATION    '     PROCESSOR GROUP 'COBNBL01 '  FOOTPRINT 'PROD.LOADLIB'  .
These members are being loaded into the DEMO environment, Stage P, Finance system, ACCTREC subsystem, and are assigned a type of COBOL. Each member has both a CCID and a comment, and is associated with the processor group COBNBL01. The members are being loaded from data set PROD.SRCLIB and will be footprinted in the load library PROD.LOADLIB.
  • Quotes are optional for data sets unless you have embedded blanks or periods within the literal. The data set names in this example contain embedded periods; therefore, these values are enclosed in quotes.
  • If no processor group is specified, the member(s) is associated with the default processor group for the type specified.
  • Members can be footprinted in source and object libraries as well as load libraries. Simply enter the appropriate library names in the FOOTPRINT clause.
How to Execute the JCL
When your requests are ready to be loaded into
CA Endevor
, submit them for execution, using JCL similar to the following:
//* (JOBCARD) // //******************************************************************* //*       SAMPLE JCL THAT WILL RUN LOAD UTILITY       * //******************************************************************* //LOAD   EXEC PGM=NDVRC1,PARM='C1BML000' //STEPLIB  DD DSN=iprfx.iqual.CSIQAUTU,DISP=SHR //     DD DSN=iprfx.iqual.CSIQAUTH,DISP=SHR //CONLIB  DD DSN=iprfx.iqual.CSIQLOAD,DISP=SHR //C1BMLIN DD *         
(PLACE INPUT DATA HERE)
//C1BMLLOG DD SYSOUT=* //C1BMLSYN DD SYSOUT=* //C1BMLDET DD SYSOUT=* //C1BMLSUM DD SYSOUT=* //SYSOUT  DD SYSOUT=* //SYSPRINT DD SYSOUT=* // //* BC1JLOAD
How to Review the Reports
CA Endevor
Load Utility execution produces a series of reports for your review. The reports you see depend on whether your input requests contained syntax and/or data errors. If errors exist in the input LOAD requests, the
CA Endevor
Load Execution Log and the
CA Endevor
Data Validation Report are produced. If no syntax or data errors exist in the input requests, you see the
CA Endevor
Load Execution Log, the
CA Endevor
Load Execution Report, and the
CA Endevor
Load Execution Summary. Each of these reports is illustrated in the following sections, and contains information pertaining to the example, as appropriate.
The Load Utility Reports help you review the processing of your LOAD requests. With these reports, you can pinpoint problems and errors before you begin working with
CA Endevor
. Interpreted and used properly, the load reports enable you to load accurate and valid data.
The following table summarizes which reports are produced under which circumstances, where B indicates that the report is produced:
Report/Condition
Syntax Errors Only
Invalid Data Only
Syntax Errors and Invalid Data
Syntax and Data Correct
CA Endevor
Load Execution Log
B
B
B
B
CA Endevor
Data Validation Report
Not produced
B
Not produced
Not produced
CA Endevor
Load Execution Report
Not produced
Not produced
Not produced
B
CA Endevor
Load Execution Summary
Not produced
Not produced
Not produced
B
 
Load Request Numbers
During execution, the system automatically assigns LOAD request numbers, beginning sequentially with the first LOAD request. All requests within the input data set are numbered. The LOAD request number appears on the
CA Endevor
Data Validation Report,
CA Endevor
Load Execution Report, and
CA Endevor
Load Execution Summary.
These request numbers are particularly useful when looking for requests containing incorrect data. You can use the
CA Endevor
Load Execution Log in conjunction with the
CA Endevor
Data Validation Report to pinpoint those requests causing problems.
Load Execution Log (DDname = C1BMLLOG)
The
CA Endevor
Load Execution Log contains each LOAD request as you coded it, including those requests with syntax errors or incorrect data. When a syntax error is found by the parser, it is noted in the request by the prefix
BSTPPARS:
in the log--immediately following the line in which the error appears.
In the following report, the LOAD request was loaded successfully. The LOAD syntax appears first, in the order in which it was coded. Several informational messages follow, one for each member to be added in the LOAD request. Each message indicates that the member requested has been created, and lists the version number and stage associated with the member. The final message, which is the last line of the report, indicates that the load processing for the request was completed successfully.
If there had been an error in the syntax, however, a report similar to the one illustrated next would have been produced.
In the following example, the LOAD request contains a syntax error in the FROM DSNAME clause. The next line indicates the error; note the line beginning with BSTPPARS.
In this case, no comment was specified although the keyword COMMENT was coded. The system looked for a comment and applied the next word it found in the syntax--the word FROM, based on the FROM DSNAME entry immediately following the OPTION COMMENT clause. The FROM DSNAME command then is misread. Because the from DSNAME command requires both words (FROM and DSNAME) in the clause, the system considers this an error in command wording and therefore an error in syntax.
Note, in the last line of the report, that the processing for this request failed and execution of the job terminated. Even if several other LOAD requests with no errors had been included in the input data set, this one error still would prevent execution of the job.
Data Validation Report (DDname = C1BMLSYN)
The
CA Endevor
Data Validation Report lists the data errors, if any, found in each LOAD request. Only those requests with errors are listed, with the appropriate request number. If there are no errors in any of the LOAD requests, this report is not produced for the job. If data errors do exist, processing is terminated for the request and for the entire job.
Assume that an incorrect system name (“BADSYS”) was specified. a
CA Endevor
Data Validation Report would be produced.
The first line indicates the number assigned to the LOAD request. Use this number to go back to the
CA Endevor
Load Execution Log to find the request and check your data. In this example, only one LOAD request has been entered; therefore the request number is
1
.
The second line notes the error. In the example, this message indicates that the system specified in the request does not exist. If there were additional data errors in this request, they too would be listed here.
The third line indicates the total number of errors in this request only. Only one error exists in the example, as is reflected by the message. If two data errors existed in the request, the request total would reflect that fact.
The final line of the report lists the total number of requests that contained errors. Again, because the example contains only one request, the DATA REPORT FINAL TOTAL is
1
.
Load Execution Report (DDname = C1BMLDET)
The
CA Endevor
Load Execution Report is not produced unless every request in the input data set (DDname C1BMLIN) is correct syntactically and contains no invalid data. Remember that the input data set can contain one request with several members, multiple requests of one member each or any combination of the two. If you are loading several (2 or more) members, whether in a single request or using several requests, you may want to review the
CA Endevor
Load Execution Summary before the
CA Endevor
Load Execution Report. The
CA Endevor
Load Summary alerts you to the number of members that failed load processing in a single request, for every request coded. You can then refer back to the
CA Endevor
Load Execution Report to locate the specific members, in each request, that contain the errors.
The LOAD request has been expanded and reformatted to fit the standard structure (shown in the “Load Request Syntax” section). No SET information was coded for this request. If SET information had been coded, it would appear in the appropriate clauses in the syntax.
Note the informational messages following the request. Details about processing for each member are listed; in the example, each step of the process for every member was successful. Be sure to read these messages carefully, as error and problem conditions are noted here as well as informational messages.
Load Execution Summary (DDname = C1BMLSUM)
As with the
CA Endevor
Load Execution Report, the
CA Endevor
Load Execution Summary is not produced unless every request in the input data set is correct syntactically and contains no invalid data.
This report summarizes the results of processing the requests in the input data set, and provides the following information for every request (by request number):
  • The return code for the request
    . In this example, the return code is
    0000
    , which indicates that processing was successful.
  • The total number of members requested in the LOAD request
    . In this example, a range of members was requested, resulting in a total of
    5
    members to be loaded.
  • The total number of members successfully loaded
    . In this example, all
    5
    members requested were successfully loaded.
  • The total number of members not loaded
    , due to an error. In this example, no members failed processing.
  • The number of members for which footprinting was attempted
    . Footprinting is attempted only for those members that were loaded successfully and for which a FOOTPRINT clause (or SET FOOTPRINT statement) was coded. In this example, footprinting was attempted for all 5 members, as the previous criteria was met for each member. Therefore, footprints attempted reflects a total of
    5
    .
  • The number of members for which footprinting failed.
    Again, this total is based on the number of members eligible for footprinting. In this example, no members failed the footprinting process.
Load Utility Footprint Override Exit
The
CA Endevor
Load Utility provides an external exit routine that can be used to override the member name that the Load Utility footprints during load processing. The default member name that is footprinted is the same as the member name that is specified in the LOAD MEMBER statement. In certain circumstances, though, the default member name may not be appropriate.
For example, assume that the Load Utility is loading a data set that contains linkage editor control statements and the FOOTPRINT statement is pointing to the associated load module library. In this case the Load Utility attempts to footprint the member in the load module library that has the same name as the input element name. However, if the linkage editor control statements contain a NAME statement that created a load module that was different than the control statement member name, the Load Utility may not find the correct load module to footprint. The Footprint Override Exit could be used to supply the correct member name to be footprinted by the Load Utility.
Load Utility Footprint Exit Operation
The name of the Load Utility Footprint Override exit must be C1EXITL1. The exit, if used, must reside in the
CA Endevor
CONLIB library. If the Load Utility cannot locate the exit routine, it does not perform any exit processing. The normal Load Utility functions continue, however.
The exit must be reentrant and reusable. It is called in 31-bit addressing mode.
On entry to the exit, register 1 points to a two-word parameter list. The parameter list and all parameters are in 24-bit addressable storage. The parameter list is defined next:
  • Word 1
    Contains the address of the Load Exit Control Block. The control block is mapped by the @LOADDS macro.
  • Word 2
    Contains the address of a 400 byte work area that is available for the exit. The area is on a double-word boundary and is initialized to binary zeroes for each invocation of the exit.
If the exit decides that the default footprint element name is to be overridden, it must update field EXMBRNM in the Load Exit Control Block with the appropriate member name and set the return code to four. The maximum allowable member name length is eight characters. The EXMBRNM field, however, is 10 bytes long and should be right-padded with blanks.
The exit should set one of the following return codes in register 15 before returning to the Load Utility. If the exit wants to override the default element name, it must set a return code of four.
  • 0
    The exit does not want to override the member name.
  • 4
    The exit wants to override the member name to be footprinted.
  • 8
    The exit encountered an unrecoverable error. The Load Utility will footprint the default member.
LOADDS Load Exit Control Block
The following DSECT maps the Load Exit Control Block:
LOADDS  DSECT EXFUNC  DS  H            FUNCTION CODE EXVER  EQU  1            VERFIY REQUEST EXFOOT  EQU  2            FOOTPRINT REQUEST EX$MAXF EQU  2            FUNCTION MAX VALUE EXSEVI  DS  CL1           MESSAGE SEVERITY SELECTION IND EXMSGI  EQU  C'I'          INFORMATIONAL MESSAGE SELECTED EXMSGW  EQU  C'W'          WARNING MESSAGE SELECTED EXMSGC  EQU  C'C'          CAUTION MESSAGE SELECTED EXMSGE  EQU  C'E'          SEVERE ERROR MESSAGE SELECTED EXDDNM  DS  CL8           DDNAME EXDSNM  DS  CL44          DSNAME EXDATA  DS  CL65          FOOTPRINT REQUIRED DATA
EXMBRNM DS CL10
        MEMBER NAME      ORG  EXDATA EXENV  DS  CL8           ENVIRONMENT EXSYS  DS  CL8           SYSTEM EXSBS  DS  CL8           SUBSYSTEM EXELENM DS  CL10          ELEMENT NAME EXTYPE  DS  CL8           TYPE EXSTGN  DS  CL8           STAGE NAME EXSTG#  DS  CL1           STAGE EXGRP  DS  CL8           PROCESSOR GRP EXLVV  DS  CL2           VERSION CHARACTER EXLVVX  DS  XL1           VERSION (BINARY) EXLLL  DS  CL2           LEVEL CHARACTER EXLLLX  DS  XL1           LEVEL (BINARY)      ORG [email protected]  DS  F            ADDRESS OF PRB FOR MESSAGES EXRESVD DS  4F           ** RESERVED ** EXRQ#LN EQU  *-LOADDS
C1BMLXIT Exit
The exit reads link-edit control cards and extracts the module name specified in the NAME control statement. If found, the exit sets a return code of four to indicate to the Load Utility that an override member name is to be footprinted. The program uses an internal table to determine the element types that are associated with linkage editor control statements. Refer to the program code for information on how to update the table and about the method of operation and program limitations.
The sample exit source is distributed in the uprfx.uqual.CSIQOPTN library.
The exit can be assembled and link-edited using standard procedures. The load module name that is created must be named C1EXITL1 and it must be placed in the
CA Endevor
CONLIB library. The program must be link-edited with the RENT, REUS, AMODE(31), and RMODE(24) attributes.