The model, APJMLIBR, is used to process CA‑Librarian moves. It uses both the AFOLIBR program and the LIBRCOPY program to perform the moves.
Typically it is desirable to use the AFOLIBR UTILITY copy at the beginning of a Move Cycle, for example, moving the program out of the development test library into a quality assurance library. This way all versions that were created during testing are retained in the quality assurance copy. If you need to back out a move, you can still access prior versions.
After sufficient testing at a quality assurance level, it is desirable to use the LIBRCOPY program, so that only the most recent changes are moved to subsequent levels. The APJMLIBR model supports this type of movement. You define to the model the target move level where LIBRCOPY should be used instead of AFOLIBR. Moves to that level and all higher levels are done using LIBRCOPY. This level is defined globally by setting the $G$LIB_LIBRCOPY_LVL user keyword to the level's one‑to‑four character short name. This can be overridden for any Library Code by setting the LIB_LIBRCOPY_LVL user keyword (no $G$ prefix). The $G$LIB_LIBRCOPY_LVL keyword should be set in either the APJMLEAD or APJMLIBR model. The LIB_LIBRCOPY_LVL override keyword, if used, should be set in the model specifications before including the APJMLIBR model. If neither are specified, LIBRCOPY is used for all moves.
Note: If you specify either the $G$LIB_LIBRCOPY_LVL or the LIB_LIBRCOPY_LVL user keywords, remember to change them if you ever change the corresponding level short name on the Control file. If you fail to do so, the APJMLIBR model aborts the next time it is used.
You can also set the names of the AFOLIBR and LIBRCOPY programs, in case you installed CA‑Librarian using different program names. This is controlled on a global basis by setting the $G$LIBR_PGM and $G$LIBRCOPY_PGM user keywords in either the APJMLEAD or APJMLIBR model. This can be overridden for any Library Code by setting the LIBR_PGM and LIBRCOPY_PGM user keywords (no $G$ prefix) in the model specifications before including the APJMLIBR model. If neither is specified, LIBRCOPY is used for all moves.
In your Library Code, set your Model Specifications as follows:
LIB_LIBRCOPY_LVL = 'LEVL' (only if overriding the default)
INCLUDE APJMLIBR
The APJMLIBR model builds a history record, which can be customized, on the move from the first level. As delivered, the information put into the record is the move request number and the service request data. The level at which the LIBRCOPY utility is used is the point at which the last history record (most likely the one created in the first level move) is carried to the target library, and all prior history records are discarded.
CA‑Librarian release 4.2 uses two types of library structures, the traditional Advanced File Organization (AFO) and the new, wide‑record master file. CA‑PanAPT requires all librarian libraries to be the same type of structure for a specific library code. To alert CA‑PanAPT to the type of master being used, you must supply the access‑method in the Library Maintenance, Level detail panel. For wide‑record masters, 'LW' is the two‑character code that identifies the access‑method. For 'AFO' masters the access‑method code is 'L' which is also the default if the field is left blank. The distinction between library structures is necessary because the new wide‑record structure requires different procedures for utility copies, a one‑step as opposed to the traditional two‑step job.
Note: When dealing with wide‑records, the LIBRCOPY program requires that all members being copied have the same LRECL. Otherwise a non‑zero return code and error messages are given.
To accommodate CA‑Librarian security, the check‑out and move models examine the security fields specified in the library code. A blank security field indicates that there is no internal security. If a site employs the management code, then the four‑digit, base code should be provided in the first four spaces of the security field of the Library Maintenance, level detail panel. If all members in a library have a specific status, the second four‑characters of this security field contains a four‑character status code: TEST; PRD0; PRD1; PRD2. For example, the security field of a library having a base MCD of 1111 and a status of PROD2 is: 1111PRD2__.
Once the Library codes have been set up, the current MCD code is determined by running the command through a provided utility, APC5921, that computes the base code with Today's date. This utility generally acts as a pre‑step to any CA‑Librarian operations. It can massage command streams and, through use of the FAIR routines, determine a member's existence and password. If a member is not found, the command is discarded. In some instances this is desirable as, for example, when a new source code member is deleted from a backup file! However, in an upward move situation the members are expected to be on the origin library, in which case you would not want the commands to be massaged. Any CA‑Librarian commands beginning with '%' rather than '‑' are subject to manipulation by this utility. Commands starting with '‑' are merely read from the APTINPUT file and immediately written out to a SYSIN file for execution in a subsequent step.
|
Copyright © 2004 CA.
All rights reserved.
|
|