We can divide the CAXALOAD control statements into six categories, as shown below:
The syntax for adding or relocating modules in the CP or CMS nucleus is:
{CMSNUC }
{CPIRES }
{CPPAG } [modname modtype] [LANG]
{CPRES }
{CPRESMP }
{CPPAGMP }
If one of these control statements identifies an IBM CP module (defined in an IBM CP LOADLIST), CA ACF2 for z/VM relocates it to the CP nucleus portion the control statement keyword describes.
Note: In z/VM Version 5 Release 1.0 (and above) the entire CP nucleus is resident. Therefore, CPPAG, CPPAGMP, and CPIRES should no longer be used. Only CPRES and CPRESMP are valid in z/VM Version 5 Release 1.0 and above.
Includes the CA ACF2 for z/VM or user modules in the CMS nucleus to manipulate CA ACF2 for z/VM and user CMS modules. Only the CMS CAXALOAD files use it. A portion of the base CMS CAXALOAD control file contains a keyword for managing an CA ACF2 for z/VM module:
************************************************************* * ACF2 MODULES FOLLOW: * ************************************************************* CMSNUC DMSAC0
Do not delete the CMSNUC keyword. You can add additional CMSNUC keywords to customize your CMS load deck. Add these keywords to your own USERCMS CAXALOAD component control file. (See the Bundle Control Statement into Control Files for additional information.)
Includes CA ACF2 for z/VM, IBM, or user modules in the IPL‑resident portion of the CP nucleus.
Includes CA ACF2 for z/VM, IBM, or user modules in the pageable portion of the CP nucleus.
Includes CA ACF2 for z/VM, IBM, or user modules in the resident portion of the CP nucleus.
Includes CA ACF2 for z/VM, IBM, or user modules in the CP resident MP (multiprocessing) nucleus.
Includes CA ACF2 for z/VM, IBM, or user modules in the CP pageable MP (multiprocessing) nucleus.
The filename of the module placed in the CP or CMS nucleus.
The optional filetype of the module placed in the CP or CMS nucleus. If you do not specify a filetype, your site's standard control (CNTRL) file determines the text file search order.
CA ACF2 for z/VM r12 supports the CPMOVIRS, CPMOVPAG, and CPMOVRES keywords to relocate modules. However, future CA ACF2 for z/VM releases may not support these keywords. We recommend you convert these statements for module relocation as follows:
Change to CPIRES
Change to CPPAG
Change to CPRES.
The syntax for deleting modules in the CP or CMS nucleus is:
CPDEL modname
Deletes user‑specified modules from the nucleus
Indicates the module to delete.
INTERCPT control statements gain control before CP or CMS entry points without changing the CP or CMS module source code changes. CA ACF2 for z/VM identifies the front‑ended CP or CMS entry point as the intercepted entry point. It replaces the intercepted entry points by one or more intercepter entry points. These intercepter entry points gain control in a predetermined order before finally giving control to the intercepted entry. It modifies all modules that refer to intercepted entry points to call the identified intercepter entry points.
The syntax to call intercepter entry points is:
[APPEND]
INTERCPT [REPLACE ] intrpt [intrpt1...5]
[CLEAR ]
Identifies entry points to intercept.
Adds a new intercepted entry or appends an intercepter entry to an existing intercepted entry point. APPEND is the default setting.
Adds a new intercepted entry or replaces intercepter entries for existing intercepted entry points.
Removes matching INTERCPT statements. The key is the intercepted entry point.
Specifies the intercepted entry point (required).
Specifies up to five intercepter entry points. When you specify more than one intercepter, the intercepters ordered on the right side of the INTERCPT statement gain control first, moving left until the intercepted entry gains control last. You must specify at least one intercepter.
The following is an excerpt showing how INTERCPT keywords appear in a sample CAXALOAD control file for CP (not necessarily the exact keywords we shipped):
LISTTYPE CP <=== Defines this as a CP load list . * * INTERCEPTED ************* INTERCEPTER ENTRIES * ENTRY LEVEL 1 LEVEL 2 LEVEL 3 LEVEL 4 LEVEL * ******** ******** ******** ******** ******** ***** * INTERCPT HCPCFCMD HCPAF7CF INTERCPT HCPCFPRR HCPAA1RR
This portion of the file contains only one level of intercepters. The intercept hierarchy can specify up to five levels of intercepters. If you specified three intercepters on a control statement, the one immediately after the intercepted entry is the first level intercepter, the middle one is the second level intercepter, and the one on the right is the third level intercepter.
The following is an example of an INTERCPT record that has two intercepter entry points:
INTERCPT HCPCFGII HCPAA9II HCPAB3II
The logic for this intercept record is:
The coded logic for the HCPAB3II and HCPAA9II modules is such that they both have internal calls to HCPCFGII. However, the CA ACF2 for z/VM loader program handles the entry point intercept logic for these modules, and bases pathing on the position of the module in the INTERCPT control record. Do not change any of the supplied INTERCPT records without consulting CA ACF2 for z/VM Technical Support.
The RENAMEXT control statement renames external references. It is a reference to an external routine in a CSECT (a V‑type address constant in assembler). The entry point the rename‑from external reference refers to may already exist. It could also be an unresolved reference.
A text filename limits the rename to apply only in a specified text file. If you do not specify a text filename, the rename applies to all text files containing the rename‑from external reference.
RENAMEXT also changes all CAXALOAD control statement entry point names that match the rename‑from external reference name to the rename‑to name.
The syntax to rename external references is:
RENAMEXT [CLEAR] renfrm rento [textfn]
Identifies external references to rename.
Removes matching RENAMEXT statements. The key is the from and to external reference names. This parameter is optional.
Specifies the rename‑from external reference (required).
Specifies the rename‑to external reference (required).
Specifies the text filename that contains the external references to rename (optional).
An example of a fictional RENAMEXT record is:
RENAMEXT HCPRPICN HCPAF1CN HCPIUG
In this example, the rename‑from external reference is HCPRPICN. (This can be an unresolved reference.) The rename‑to external reference is HCPAFICN. The HCPIUG text file name limits the rename function to only this text file.
The syntax for bypassing intercept processing is:
BYPASS [CLEAR] module [extrn]
Identifies modules that contain external references that are not intercepted.
Removes matching BYPASS statements. The key is the module name and extrn you specified, if any.
Specifies the name of the module containing the external references that intercept processing should not alter (required).
Indicates the external reference in the specified module that is to remain intact during intercept processing (optional).
The extrn operand identifies the only external reference in the module. An example of a fictional RENAMEXT record is:
RENAMEXT HCPRPICN HCPAF1CN HCPIUG
Specify multiple BYPASS statements to identify multiple extrn in one module. A sample of specifying multiple BYPASS statements follows:
BYPASS HCPVIO HCPHVCAL BYPASS HCPSYM
The first BYPASS statement bypasses the external reference HCPHVCAL in the HCPVIO module. With this statement, DMKHVCAL is the only external reference that remains intact during intercept processing. The second BYPASS record bypasses all INTERCPT external reference processing for the module HCPSYM; all external references to HCPSYM remain intact during intercept processing.
Do not insert BYPASS records for any of the INTERCPT records CA ACF2 for z/VM supplies. Improper use of BYPASS records can cause integrity exposures.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|