EndevorLoad Utility enables you to load one or more members (elements), from data sets external to
Endevor, directly to any stage that is defined within an
Endevorenvironment. Using this utility, you can quickly populate
Endevorenvironments 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
EndevorLoad Utility, the inventory structures that you want to populate within
Endevormust be defined.
For more information about defining inventory structures, see Administrating.
This section describes the
EndevorLoad 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
EndevorInventory Analyzer as part of the analysis process. The method used is at your discretion; the results of the load processing are the same.
EndevorLoad Utility is simple to operate and involves two basic steps:
- Creating your requestsThe Load Utility automatically validates each request before it is executed.
- Reviewing the reports producedReports 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
Endevorlocations. 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 theEndevorlocation specified by the TO information.
- Create version 1.0 of an element inEndevor, 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,
Endevorvalidates 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
Endevorlocation specified is valid.
LOAD Request Reports
As request execution progresses, the following reports are produced:
- TheEndevorLoad Execution Log
- TheEndevorData Validation Report
- TheEndevorLoad Execution Report
- TheEndevorLoad 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
EndevorTO 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.
EndevorLoad Utility Requests
This section describes the syntax you use to load elements into environments predefined in
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 alwaysLOAD 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 MEMBERIndicates the member(s) you want to load. The member name can be up tomember10characters 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 DSNAMEIndicates 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.dsnameThe FROM data set can be a partitioned data set (PDS or PDS/E), or aLibrarianorPanvaletlibrary. It cannot be a load library, however; load library members are never loaded to anEndevorenvironment. 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
Endevorlocation 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
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)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.memberYou 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.
If you leave this field blank, the system defaults to the processor group defined on the element's type record.
- CCID ccidYou 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 commentYou can specify a comment to further define the member(s) being loaded. Comments can be up to40characters in length, and must always be enclosed in quotes.
- PROCESSOR GROUP group-nameYou can designate a specific processor group, up to8characters, 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.
- 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 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
LOADand 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.
- Endevorencounters another, like SET statement, which overrides the existing SET statement.
- Endevorencounters 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 DSNAMEThe 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.dsnameThe 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 ENVIRONMENTenv-nameSYSTEMsys-nameSUBSYSTEMsubsys-nameTYPEtype-name[STAGEstage-id].
The information specified in the SET TO statement indicates the
Endevorlocation 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
Endevorlocation 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
Endevorlocation. 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 CCIDccidCOMMENTcommentPROCESSOR GROUPgroup-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 (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.'dsname', 'dsname', 'dsname')...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 ' ' .
Endevorinterprets 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.
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 ALLCLEAR 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 FROMCLEAR FROM clears all SET FROM information previously coded.
- CLEAR TOCLEAR TO clears all SET TO information previously coded.
- CLEAR OPTIONSCLEAR OPTIONS clears all SET OPTIONS information previously coded.
- CLEAR FOOTPRINTCLEAR FOOTPRINT clears all SET FOOTPRINT information previously coded.
Load Utility Reports
The following reports are produced by the
EndevorLoad Utility after execution of the JCL:
- EndevorLoad Execution Log
- EndevorData Validation Report
- EndevorLoad Execution Report
- EndevorLoad Execution Summary
Each of these reports is explained in the following sections.
For examples on their use, see Example of the Load Utility Process.
Endevorpanels and reports, mostly related to footprints, reflect the use of the
EndevorLoad Utility to populate environments. A load indicator ?? the field
LDwhich appears as part of the footprint ?? indicates whether a particular element/member was loaded into
Y, yes) or generated within
The panels affected include the
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
EndevorLoad 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
Data Validation Report
The system automatically checks the content of each LOAD request to ensure that both the input data sets and
Endevorlocations specified are valid. The
EndevorData 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
EndevorLoad 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
EndevorLoad Execution Summary. Using this combination of reports facilitates looking for, and finding, those requests that may contain processing errors.
Load Execution Summary
EndevorLoad Execution Summary, like the
EndevorLoad 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
EndevorLoad 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
EndevorLoad Utility process. This example begins with a LOAD request being entered into
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
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
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
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
EndevorLoad 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
EndevorLoad Execution Log and the
EndevorData Validation Report are produced. If no syntax or data errors exist in the input requests, you see the
EndevorLoad Execution Log, the
EndevorLoad Execution Report, and the
EndevorLoad 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
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:
Syntax Errors Only
Invalid Data Only
Syntax Errors and Invalid Data
Syntax and Data Correct
EndevorLoad Execution Log
EndevorData Validation Report
EndevorLoad Execution Report
EndevorLoad Execution Summary
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
EndevorData Validation Report,
EndevorLoad Execution Report, and
EndevorLoad Execution Summary.
These request numbers are particularly useful when looking for requests containing incorrect data. You can use the
EndevorLoad Execution Log in conjunction with the
EndevorData Validation Report to pinpoint those requests causing problems.
Load Execution Log (DDname = C1BMLLOG)
EndevorLoad 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)
EndevorData 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. an
EndevorData Validation Report would be produced.
The first line indicates the number assigned to the LOAD request. Use this number to go back to the
EndevorLoad 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
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
Load Execution Report (DDname = C1BMLDET)
EndevorLoad 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
EndevorLoad Execution Summary before the
EndevorLoad Execution Report. The
EndevorLoad 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
EndevorLoad 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
EndevorLoad Execution Report, the
EndevorLoad 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 is0000, 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 of5members to be loaded.
- The total number of members successfully loaded. In this example, all5members 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 of5.
- 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
EndevorLoad 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
EndevorCONLIB 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 1Contains the address of the Load Exit Control Block. The control block is mapped by the @LOADDS macro.
- Word 2Contains 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.
- 0The exit does not want to override the member name.
- 4The exit wants to override the member name to be footprinted.
- 8The 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 DATAEXMBRNM DS CL10MEMBER 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
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
EndevorCONLIB library. The program must be link-edited with the RENT, REUS, AMODE(31), and RMODE(24) attributes.