Unload, Reload, and Validate

Information on the Unload, Reload, and Validate utility, also known as program C1BM5000
Endevor 18.1
The following article contains information on the Unload, Reload, and Validate utility, also known as program C1BM5000.
2
Unload, Reload, and Validate Utility
The Unload, Reload, and Validate utility is a backup, recovery, and file validation mechanism for
CA Endevor
VSAM control files (Master Control File, package data sets) and their related base and delta libraries. It allows users to backup (Unload), restore (Reload), and/or validate (Validate) the integrity of one or more
CA Endevor
environments in the event of a physical device failure or site disaster.
The Unload, Reload, and Validate utility provides a point-in-time physical recovery mechanism. The utility can be used to perform the following actions:
  • Unload all or specific environments and/or systems and their related elements/components.
  • Reload all or specific environments and/or systems and their related elements/components.
  • Validate the integrity of all or specific environments and/or systems and their related elements/components.
The Unload, Reload, and Validate utility provides a point-in-time physical recovery mechanism. It allows you to backup (unload), restore (reload), and validate the integrity of one or more
CA Endevor
environments in the event of a physical device failure or site disaster.
The Unload function copies all Master Control File environment information (system, subsystem, type, type sequence, data set, and element master record) to the data set you specify. Then it copies all the elements in full or incremental mode. If an incremental unload is specified on the Unload request, then base and delta information is only copied for elements that have changed since the last unload. During the unload process, validation always occurs to ensure that the elements to be unloaded meet certain integrity criteria. Any corrupt elements are not unloaded. You can run the Validate function independent of the Unload function.
The Reload function restores data from the data sets created by the unload process. You can use the Reload function to recover from hardware failure.
This article discusses the Unload, Reload, and Validate functions performed by program C1BM5000. For each, there is a brief description of the function, a syntax diagram, and a discussion of the rules that each follows.
For the element catalog, the Reload utility uses normal
CA Endevor
inventory management functions which will update the MCF, BASE/DELTA and element catalog and EINDEX where necessary.
ACMQ Files and the Reload Utility
The Reload utility does not update the ACMQ files. The ROOT and XREF files remain at the state that they were in before the reload. ACMQ data is not touched by the Reload utility, but some forms of recovery may require a full or partial rebuild of ACMQ data.
How the Reload utility affects the validity of the ACMQ files in various situations is described next:
  • Suppose you lose a delta and decide to reload the missing pieces.
    In this case the ROOT and XREF files before the reload will contain correct data and thus the reload will not impact the quality of the content.
  • Suppose you lose the ACMQ files.
    In this case reload will not help you. You could restore the data from another type of backup (full volume, IDCAMS), but the ACMQ data could be out-of-sync with the MCF and Catalog data. For this case, you will have to rebuild the ACMQ data sets (BC1JACML)
  • Suppose you want to recover some elements that have been deleted from a full or incremental unload.
    In this case, we recommend using Transfer from unload and regenerate the elements. The Transfer action will rebuild the outputs and the ACMQ data. If you want to use Reload, because you do not want to rebuild the outputs, ACMQ will be out of sync and you must run a partial rebuild of the ACMQ data for these reloaded elements.
Unload Function
This function unloads and validates the contents of the VSAM Master Control Files (MCFs), base and delta files associated with the environments and systems specified on the job request. The file created by the Unload function contains a backup of all internal MCF definitions (system, subsystem, type, type sequence, data set, element master record) and base/delta data (element base, element delta, component base, component delta). Packages contained within a package data set can also be unloaded.
Unload may be run for an entire environment, or for selected systems within an environment. Unload may also be directed to backup an entire package data set or individual packages.
The LRECL of the unload data set must be at least 84 bytes larger than the largest type record length in the unloaded environment or system.
Regardless of whether you specify a full or incremental unload, all Master Control File environment information (system, subsystem, type, type sequence, data set, and element master record) is unloaded to the data set you specify. This step is done so that the environment definitions can be restored from any unload point.
After unloading the environment information, the function unloads elements in a full or incremental mode.
This unloading of environment information and elements occurs in the following order:
  1. Stage 1 internal environment definitions.
  2. Stage 2 internal environment definitions.
  3. Stage 1 elements.
  4. Stage 2 elements.
Unload Control Card
The following syntax provides the parameters for using Unload against an environment or system:
►►─ UNLoad ─┬─ FULL ────────┬───────────────────────────────────────────────────► └─ INCremental ─┘ ►─ ─┬──────────────────────────────────────────────┬───────────────────────────► └─ ENVironment ─ env-name ─ SYStem ─ sys-name ─┘ ►─ TO ─ DDName ─ ddname ─ FROm ─ ENVironment ─ env-name ─ SYStem ─ sys-name ───► ►────┬───────────────────┬─────────────────────────────────────────────────────► └─ CHEckpoint ONLY ─┘ ►─ ─┬────────────────────────────────────────────────────────────┬─ . ─────────►◄ │ ┌──────────────────────────────────────────────────────┐ │ └──▼─ EXCLUDE ENVironment ─ env-name ─ SYStem ─ sys-name ─┴──┘
The following syntax provides the parameters for using Unload against one or more package data sets:
►►─ UNLoad PACkage ─┬─────────────────────────┬─ TO ─ DDName ─ ddname ─ . ────► └─ ID ─ = ─ package-name ─┘
The Unload control card includes the following parameters:
  • UNLOAD
    Specifies the UNLOAD function. You must further qualify the UNLOAD request with one of the following:
    • FULL-Unloads Master Control File environment and related base/delta information for all elements in the environments and systems specified in the FROM statement.
    • INCREMENTAL-Unloads Master Control File information for all elements in the environments and systems specified in the FROM statement. Base and delta information are unloaded only for elements that have changed since the last unload, based on the date/time stamp for each system. Any number of UNLOAD statements may be coded for a single run.
    Any change to an element (SOURCE, MCF fields or STATUS (that is, SIGNED IN)) is considered and the unload incremental occurs for these changes.
  • TO DDNAME
    Identifies the DDname to which the unload data set is assigned for environment and package processing.
    If you specify a DDname, you cannot use the CHECKPOINT ONLY clause.
  • FROM
    Allows you to specify the FROM location for a combination of environments and systems to be unloaded. The qualifying statements are:
    • ENVIRONMENT-Identifies the environment from which information is to be unloaded. A name mask may be used.
    • SYSTEM-Identifies the system from which information is to be unloaded. A name mask may be used.
  • CHECKPOINT ONLY
    Causes a FULL UNLOAD request to simply update the system backup timestamp so you can use something other than the Unload utility to do the full backup and use the Unload utility for incremental backups. Specify the FULL and the FROM clauses when using this option.
    If you specify CHECKPOINT ONLY, you cannot specify a DDname.
  • EXCLUDE
    Bypasses unload processing for the specified environments and systems that are a subset of the environments and systems to be unloaded.
    CA Endevor
    does issue an Enqueue for the environment and system combinations specified on the Exclude clause. You can specify multiple Exclude clauses. Wildcards and placeholders are allowed. For example:
    • If you specify UNLOAD FULL ENV '*' SYS '*' but do not want to process environment ENVTEST system SYSTEST, you would specify:
      UNLOAD FULL FROM ENV '* ' SYS '*' TO DDNAME UNLODNN EXCLUDE ENV 'ENVTEST' SYS 'SYSTEST'
    • If you specify more than one Unload SCL statement and they are identical with the exception of the Exclude clause, then the Exclude clause from the last SCL is the one used.
    • If you specify more than one Unload SCL statement and they are identical except that the Exclude clauses are different and the environment and system combinations to be unloaded overlap, then the most recent Exclude statements apply to the specified environment and systems to be unloaded. For example:
      UNLOAD FULL FROM ENV '*' SYS '*' EXCLUDE ENV 'ENVT*' SYS 'SYST*' TO UNLOAD UNLODNN.
      In this case, when any environment whose name begins with P is about to be unloaded, then any environment with the name PROD and the system name SYSX is excluded. In all other cases, the prior Exclude clause takes effect.
  • PACKAGE
    Required when unloading one or more packages. You may also select a package identifier (ID) to identify the name of a specific package to be unloaded. You can use a name mask. If you do not specify a package ID, all packages in the package data is unloaded.
    For promotion packages, you cannot specify the package ID of individual historic versions. You can specify the fully qualified name or mask package ID of the current version. This unloads the records for all versions of a promotion package.
Full Unloads
All base and delta members and related component list base and delta members are unloaded for each element associated with the environments and systems specified in the UNLOAD request.
Incremental Unloads
Only elements associated with the environments and systems specified in the Unload request that have changed since the last unload is unloaded.
When Unload is successfully run against a system, the Master Control Record for that system is updated with the date/time of the unload. During an incremental unload, the date/time stamp on each element is compared with the date/time stamp on the Master Control Record for the system to which the element belongs. Only those elements with a date/time stamp that is more recent than the date/time stamp in the Master Control File system record is selected during incremental unload processing.
Package Unloads
All packages contained in the package data set defined in the C1DEFLTS table will be unloaded. Optionally, individual packages may be selected for unloading using the ID parameter.
Historic versions of promotion packages are unloaded with the current version. In the unload SCL, you cannot specify the package ID of individual historic versions of a promotion package. This ensures the integrity of the entire package. Always specify the fully qualified or mask package ID of the current version you want to unload. The unload utility unloads the records for all versions of that promotion package.
Validation During Unload
Minimal validation automatically occurs during Unload processing. This ensures that any element which is to be unloaded meets certain integrity criteria prior to being unloaded. No element found to be corrupt will be unloaded. Rather, an appropriate error message is issued indicating the exact nature of the problem. The same processing will occur if the Validate function is run independently.
If an error is detected during Unload processing, it is important to determine the cause of the error and to correct the problem. In most cases (a physical problem) the Reload facility should allow you to accomplish this task by going back to the last good unload point.
For all corrective action, see the message description. For certain logical problems it may be necessary to contact
CA Endevor
Customer Support.
If a validation error occurs during Unload processing the following occurs:
  • If the validation problem affects the element itself, Unload will:
    • Not unload the element.
    • Write an error message indicating the nature of the problem.
    • Write an SCL DELETE statement to the C1SCL1 data set. The SCL contained in the C1SCL1 data set can then be used in a subsequent recovery operation to delete the element before performing Reload processing.
  • If the element itself is intact, but there is a problem in the associated ACM component list, Unload will:
    • Unload the element.
    • Write an error message indicating the nature of the problem.
    • Not unload the component list for the element.
    • Write an SCL DELETE statement with the ONLY COMPONENT clause to the C1SCL1 data set. The SCL contained in the C1SCL1 data set can then be used in a subsequent recovery operation to delete only the element component list before a GENERATE action or Reload processing.
Packages
No validation takes place during a package unload. The package data set is considered to be intact if each package ID can be read successfully.
Unload Recommendations
Unload is designed to easily capture all related parts of the
CA Endevor
structure in a unified manner. This allows for timely physical recovery in the event of a device failure or site disaster.
Performing a needs analysis for your site is the first step in making optimal use of this utility. The criteria that you should consider include the following:
  • Number of environments/systems and related base and delta libraries at your site.
  • Location of files in relation to DASD layout.
  • Current schedule of in-house DASD backup and recovery procedures.
  • Volatility and number of changes.
Use this information to determine how best to use and/or schedule Unload processing.
Locking During Unload Processing
Unload processing maintains a share lock (enqueue) at the environment level, while keeping an enqueue exclusive at the system level. This action allows several unloads to run concurrently against different systems in the same environment.
Unload processing does not begin until the lock can be set (after all activity against the system has ceased). No
CA Endevor
activity can resume until the unload for that system has been completed. The reload function still sets an enqueue exclusive at the environment level, thus it cannot be run while an unload is being performed.
Locking Example 1
A site has only one environment, with all systems pointing to one set of base and delta libraries. A low number of changes are made and there is little concern if a physical problem causes an outage during recovery.
In this situation it may be simpler to back-up all files on a daily basis using the appropriate in-house methods. In the event of a physical problem,
CA Endevor
can be completely restored using the previous evening's backup files.
Locking Example 2
A site has many environments/systems, each with their own base/delta libraries. Any outage affects many people in many areas of the company.
In this situation, full (FULL) and incremental (INC) unloads should be run. In most cases, a full unload job should be scheduled on a weekly basis, and an incremental unload run each night. During a physical failure, you must be able to recognize which unload files pertain to each system. Therefore appropriate naming conventions for the unload files should be adopted.
Align scheduling of Unload processing with in-house backup utilities to determine what unload files need to be applied when a DASD volume is restored. In general, run Unload processing immediately following each backup utility run. This action minimizes the number of “orphan” members that occur during a reload.
Sample Unload Control Cards
To specify a full unload from environment Test, code the following statement:
UNLOAD FULL FROM ENV TEST SYS * TO DDN UNLOD01.
In this example,
CA Endevor
unloads all systems within this environment to an output data set with DDname UNLOD01. This data set must be coded in the Unload JCL.
To specify a package unload, code the following statement:
UNLOAD PACKAGE TO DDN UNLODPKG.
CA Endevor
unloads the entire package data set for this site to an output data set with ddname UNLODPKG. This data set must be coded in the Unload JCL. The JCL which unloads the package can be found in member BC1JUNLD, in the JCL library iprfx.iqual.CSIQJCL.
  • C1BM5000
    The Unload/Reload/Validate Utility program.
  • CONLIB
    Data set name of the installation
    CA Endevor
    CONLIB load library.
  • BSTIPT01
    Required DDname for Unload/Reload/Validate statements.
  • UNLODNN
    This is the DDname for the data set to which the Unload information is written. This parameter must be allocated with a minimum LRECL=4200, a block size 4 bytes greater than 4200, and a RECFM=VB.
    The LRECL should be at least 84 bytes larger than the largest LREC you are unloading.
    This data set should be set up as a Generation Data Group (GDG) with the proper number of levels based on unload frequency.
    We recommend that you adopt a naming convention based on the type of Unload being performed (FULL or INC) and the environment system to which it applies. For example:
  • SPACE=(TRK, (NN,NN))
    Required disk space for the unload data set (omit if tape). To estimate an approximate space allocation for this data set, add the following items:
    • 1105 bytes for each environment definition record on the Master File (1021-byte record length plus 84-byte prefix; the system unloads one environment record for each system, subsystem, type, type sequence, data set, and element master record).
    • The current space taken up by your base and delta libraries (these libraries continue to be written in compressed format).
    • An 84-byte prefix for each base and delta element to be unloaded.
  • C1SCL1
    Required DDname for the data set to which SCL DELETE statements are written.
Reload Function
This function lets you recover a
CA Endevor
VSAM control file (Master Control File or package data set) or a base/delta data set that was lost as the result of a physical device failure or site disaster. Reload restores data from data sets created by the Unload process. The TRANSFER action may be used to transfer elements from an Unload file.
For more information about the TRANSFER action, see SCL Reference.
Reload processing occurs in two phases. Phase one reloads Master Control File environmental definitions (system, subsystem, type, type sequence, data set, and so on) re-establish this information. Phase two reloads elements (element master record, base/delta/component list).
The Reload function, when used in combination with the batch Restore (SCL) action it can also be a powerful tool for recovering most logical and physical problems.
To make the best use of the Reload function, keep in mind the following:
  • Because no active journaling takes place, Reload processing cannot perform “point-of-failure” recoveries. It is intended to be used with proper file/DASD layouts to reduce the impact, across all systems, of a base/delta failure, and to ensure proper inventory synchronization if other outages occur.
  • Reload processing replaces
    CA Endevor
    data set or library contents with unload file contents when:
    • The date/time stamp of a record on the unload file is more recent than the one currently in
      CA Endevor
      .
    • An element currently in
      CA Endevor
      does not meet the Validation criteria (the record in
      CA Endevor
      has a more recent date/time stamp but the Validation process finds a missing base member).
  • This utility is not designed to be used to simply back off or back out a member in a data set.
  • Reload can accept a concatenated input stream of unload files. Because of the date/time checking that occurs, only the latest data is reloaded. However, it is highly recommended that files be ordered from the oldest to the newest. This ensures that the logical cleanup of elements occurs. Failure to do this may result in elements ending up at both stages, out of logical order.
  • The
    CA Endevor
    RESTORE action can use an unload file as input. This action can be used to perform logical recovery by first deleting the element, then restoring from the unload file.
  • The Unload/Reload reports (CONRPT50-55) should be used to determine the status of an unload file. Use the reporting facility whenever you need to itemize the activity contained on one of these files.
Reload Control Card
The parameters for using Reload are as follows:
►►── RELoad FROm ─ DDName ddname TO ─ ENVironment env-name ─────────────────────► ►─ SYStem ─ sys-name ─┬─────────────────────────────────────┬─ . ───►◄ └─ OPTion ─ RETain PROcessor HIStory ─┘
The parameters for using Reload for a package data set or one or more specific IDs are as follows:
►►── RELoad ─ PACkage ─┬─────────────────────┬─ FROm ─ DDName ddname ──. ──────►◄ └─ ID ─ package-name ─┘
The parameters for the Reload control card are described next:
  • RELOAD
    Specifies the Reload function of program C1BM5000.
  • FROM DDNAME
    Identifies the DDname to which the input Reload data set name is assigned. Environment and package processing require a DDname.
  • TO
    Allows you to specify the to location for a combination of environments and systems to be reloaded. The qualifying statements are:
    • ENVIRONMENT-Identifies the environments into which information is to be reloaded. A name mask may be used.
    • SYSTEM-Identifies the systems into which information is to be reloaded. A name mask may be used.
  • RETAIN PROCESSOR HISTORY
    Retains the Master Control File last processor information, indicating the date and time when the processor was last executed. If you are sure that the status of the processor output members matches the Master Control File history, you can use this option to retain the last processor information when executing the Reload utility. Do not use this option if the status of the processor output members is not known to be correct.
  • PACKAGE
    Required when reloading a package data set or one or more packages. You may also select a package ID to identify the name of a specific package to be reloaded. You can use a name mask. If you do not specify a package ID, all packages found in the unload data set is reloaded to the package data set defined in the C1DEFLTS table.
    For promotion packages, you cannot specify the package ID of individual historic versions. You can specify the fully qualified name or mask package ID of the current version. This reloads each promotion package version that is missing or that needs to be reloaded due to date validation inconsistencies.
Reloading Master Control File Information
Reload determines the status of the VSAM Master Control File (MCF) and performs a partial or complete reload by comparing each environmental record (excluding element records) on the unload file with the existing MCF.
If the VSAM Master Control File for the environment being reloaded is empty (new file allocated), Reload processing rebuilds the file using the contents of the unload data set(s).
If the Master Control File contains the environmental record, Reload processing does the following:
  • If the system information about the unload file is more recent than the existing system information, the existing information is replaced.
  • If the subsystem information about the unload file is more recent than the existing subsystem information, the existing information is replaced.
  • If the type information about the unload file is more recent than the existing type information, the existing information is replaced. This is done as follows:
    • Information for existing types is not changed.
    • Type sequence types added from the unload file are sequenced after the existing
  • If the approver group/relation information about the unload file is more recent than the existing approver group/relation information, the existing information is replaced.
  • No existing data set information is replaced. Rather, Reload adds any data set information that is not found in the current Master Control File.
Reloading Element Information
After updating and/or rebuilding the Master Control File, elements and component lists will be reloaded based on the date/time stamps of existing elements and component lists.
  • If the element or component list in the unload file is more recent than the existing MCF element or component list, Reload processing will:
    • Replace the existing element master record with the contents of the unload file.
    • Replace the existing base and delta members for the element and/or component list with the contents of the unload file.
    • Write an SCL GENERATE action request for that element to the C1SCL1 data set.
  • If the element or component list in the unload file is not more recent than the existing MCF element or component list, Reload performs validation processing on the element/component list. For a description of this validation process, see Unload Function.
  • If the element fails validation, Reload will:
    • Replace the existing element master record with the contents of the unload file.
    • Replace the existing base and delta members for the element and/or component list with the contents of the unload file.
    • Write an SCL GENERATE action request for that element to the C1SCL1 data set.
  • If the element passes validation the element is not reloaded.
  • If a Stage 2 element is reloaded and the element exists at Stage 1, reload processing will delete the Stage 1 element if the last action date for the Stage 2 element is more recent than the last action date for the Stage 1 element.
Reload and Packages
Reload will compare the date/time stamps of packages from the unload file with the date/time stamps of existing packages in the package data set.
  • If the date/time stamp of the package from the unload file is the more recent than the one contained in the package data set, Reload replaces the existing package.
  • If the date/time stamp of the existing package is more recent than the one contained in the unload file, Reload will not replace the package.
For promotion packages, the reload utility loads each of the versions that are missing or that need to be reloaded due to date validation inconsistencies.
For example, assume the unload utility was executed against the package file and the package ID of the current version is PKG1 and there are two historic versions: EXAOBHX1 and EXAJHBX2. Assume that the package records for EXAOBHX1 were deleted and the PKG1 and EXAJHBX2 package records remain intact. When you issue the reload for PKG1, the reload utility determines that only package EXAOBHX1 must be reloaded and reloads it.
Locking During Reload Processing
Reload processing will maintain an exclusive lock (enqueue) at the environment level. Reload processing will not begin until the lock can be set (after all activity against the environment has ceased). No
CA Endevor
activity can resume until the reload for that environment has been completed, nor can reload processing run concurrently with UNLOAD processing.
Example 1. Base/Delta Recovery
Problem:
A DASD volume has a hardware failure Tuesday at 10:00 a.m. This pack contained the only base and/or delta libraries defined for all systems in this environment. The volume was backed-up using an in-house backup utility, and unloaded using an incremental unload the evening before. The previous Sunday a full unload was performed.
Solution
: Restore the DASD volume from the latest in-house backup file. After this step has been done, determine to what point the volume was restored (date/time) in relation to the unload files that you have available.
  • If no changes have been made to
    CA Endevor
    data since the last backup, the files should be considered recovered (in sync), and
    CA Endevor
    processing may be continued.
  • If only environmental changes have been made to
    CA Endevor
    since the last backup (no element updates were made), the files should be considered recovered (in sync), and
    CA Endevor
    processing may be continued.
  • If element modifications have been made since the last backup, an out-of-sync condition exists between the base and/or delta libraries and the Master Control File (MCF), requiring the systems to be reloaded. To do so:
    • Itemize the systems affected by the element modifications.
    • Set up a Reload job using as input the last full unload file, and all incremental files that are available up to the point of the failure.
    • Run Reload processing for all the affected systems using the concatenated input of unload files.
    • Use the SCL file (C1SCL1) produced during Reload to run the GENERATE action against the reloaded elements. This will synchronize the outputs.
Once the reload has been completed, Validate processing must be run for each system that was reloaded. This is necessary to identify “orphan” members (members that had been added since the recovery point). To do this:
  • Run Validate processing for all the affected systems.
  • Use the SCL file (C1SCL1) produced by the Validate process to delete each element that failed validation and complete the synchronization process.
  • Note:
    The deleted elements can be manually recovered from a source output library member or an external copy of the source. If a source output library exists, ensure that the members to be recovered are first saved from this library before delete processing is performed. All other changes that have been made since that time has been effectively “rolled back.”
Example 2 VSAM Master Control File Recovery
Problem:
A DASD volume has a hardware failure Tuesday at 10:00 a.m. This pack contained the VSAM Master Control file for one
CA Endevor
environment. The volume was backed-up using an in-house backup utility, and unloaded using an incremental unload the evening before. The previous Sunday a full unload was performed.
Solution
: Restore the DASD volume from the latest in-house backup file.  After this step has been done, determine to what point the volume was restored (date/time) in relation to the unload files that you have available.
  • If no changes have been made to
    CA Endevor
    since the last backup, the files should be considered recovered (in sync), and
    CA Endevor
    processing may be continued.
  • If only environmental changes have been made to
    CA Endevor
    since this last backup (no element updates were made) the files should be considered recovered (in sync). Any environmental changes made since the recovery point has been lost and must be manually recovered. Once this has been done
    CA Endevor
    processing may be continued.
  • If element modifications have been made since the last backup, an out-of-sync condition exists between the Master Control File (MCF) and the base and/or delta library, requiring the systems to be reloaded. To do this:
    • Itemize the system(s) affected by the element modifications.
    • Set up a Reload job using as input the last full unload file, and all incremental files that are available up to the point of the failure.
    • Run Reload processing for all the affected system(s) using the concatenated input of unload files.
    • Use the SCL file (C1SCL1) produced during Reload to run the Generate action against the reloaded elements. This will synchronize the associated outputs.
Elements added since the recovery point can be manually recovered from the contents of a source output library member or an external copy of the source. All other changes that have been made since that time will have been effectively “rolled back.”
If the reloaded SYSTEM requires CCID and/or COMMENT to be specified for actions against its elements, you must insert a SET OPTIONS statement in the generated SCL file (C1SCL1).
Example 3 Package Data Set Recovery
Problem
: A DASD volume has a hardware failure on Tuesday at 10:00 A.M. This pack contained the
CA Endevor
package data set. The volume was backed up using an in-house backup utility the evening before.
Solution
: Restore the DASD volume from the latest in-house backup files. After this step has been done, determine to what point the volume was restored (date and time) in relation to any package unload files you may have available.
  • If no changes have been made to the package data set since the last backup, the data set should be considered recovered (in sync), and
    CA Endevor
    processing may be continued.
  • If any package modifications have been made since the last backup, they are lost. If there is an unload file available that is more recent than the backup from which the data set was restored you can reload the package data set. To do so:
    • Set up a Reload job, using as input any unload file that is more recent than the backup file used to restore the data set.
    • Run Reload processing for all the affected packages or selected package IDs.
Sample Reload Control Cards
The following request specifies that environment TEST and all systems in this environment are to be reloaded. UNLOD01 is the DDname assigned to the input data set that contains the data to be reloaded. This data set must be coded in the Reload JCL.
RELOAD FROM DDN UNLOD01 TO ENV TEST SYS *.
UNLODPKG is the DDname assigned to the input data set that contains the data to be reloaded. This data set must be coded in the Reload JCL. The JCL which unloads the package can be found in member BC1JRELD, supplied in your iprfx.iqual.CSIQJCL library.
  • C1BM5000
    The Unload/Reload/Validate Utility program.
  • CONLIB
    Data set name of the installation
    CA Endevor
    CONLIB load library.
  • BSTIPT01
    Required DDname for Unload/Reload/Validate statements.
  • UNLODNN
    The target DDname of the unload data set name specified for this Reload operation.
  • C1SCL1
    Required DDname for the data set to which the SCL GENERATE statements produced by the Reload operation will be written.
  • C1RLDWK*
    Pre-allocates work files so that site does not have to rely on
    CA Endevor
    for temporary allocation.
Validate Function
This function lets you ensure the integrity of one or more existing
CA Endevor
environments and/or systems and their related elements and components.
The Validate function performs a series of checks against the contents of the VSAM Master Control File(s), and the related base and delta libraries associated with the environments and systems specified on the job request. These are the same checks performed as part of Unload processing, allowing this function to operate in a standalone mode.
Validate may be run for an entire environment, or for selected systems within an environment. There is no validation processing currently available for the package data set.
The Validate function should be run any time there is a question about the integrity of an environment/system, and with a reload operation. An unload does not do the same checking against the files as a validate.
Validate Control Card
The parameters for the Validate control card are as follows:
►►──VALidate──ENVironment──environment-name──SYStem──system-name──.──►◄
The parameters for the Validate control card are described next:
  • VALIDATE
    Specifies the Validate function of program C1BM5000. You must further qualify the Validate request with one of the following:
    • ENVIRONMENT-Identifies the environments for which information is to be validated. A name mask may be used.
    • SYSTEM-Identifies the systems from which information is to be validated. A name mask may be used.
    Any number of Validate statements may be coded for a single run.
Validate Processing
Validate processing performs a series of checks against the contents of the VSAM Master Control Files, and the related base and delta libraries. These checks include:
  • MCF to base to delta relationship verification.
  • Footprint correlation.
  • Physical base/delta member counts.
  • Insert/delete counts.
  • Delta level verification.
If an error is detected it is important to determine the cause and to correct the problem. In most cases (a physical problem) the Reload facility should allow you to accomplish this task by going back to the last good unload point.
Validate checks Master Control File and element information in the following order:
  1. Stage 1 internal environmental definitions.
  2. Stage 2 internal environmental definitions.
  3. Stage 1 elements.
  4. Stage 2 elements.
If an error is encountered during Validate processing the following will occur:
  • If the validation problem affects the element itself, Validate will write:
    • An error message indicating the nature of the problem.
    • An SCL DELETE statement to the C1SCL1 data set. The SCL contained in the C1SCL1 data set can then be used in a subsequent recovery operation to delete the element prior to performing Reload processing.
  • If the element itself is intact, but there is a problem in the associated ACM component list, Validate will write:
    • An error message indicating the nature of the problem.
    • An SCL DELETE statement with the ONLY COMPONENT clause to the C1SCL1 data set.
The SCL contained in the C1SCL1 data set can then be used in a subsequent recovery operation to delete only the element's component list prior to a GENERATE action or Reload processing.
Sample Validate Control Card
The following request specifies that environment Test and all systems in this environment are to be validated:
VALIDATE ENV TEST SYS *.
The JCL which validates the package can be found in member BC1JVALD, supplied in your iprfx.iqual.CSIQJCL library.
  • C1BM5000
    The Unload/Reload/Validate Utility program.
  • CONLIB
    Data set name of the installation
    CA Endevor
    CONLIB load library.
  • BSTIPT01
    Required DDname for Unload/Reload/Validate statements.
  • C1SCL1
    Required DDname for the data set to which the SCL DELETE statements produced during Validate processing is written.