Point in Time Recovery
This article describes the
CA EndevorPoint in Time Recovery (PITR) feature.
CA EndevorUnload/Reload/Validate utility provides a point of backup recovery mechanism. PITR extends this capability to the recovery of
CA Endevoractivity that has occurred since the last backup.
PITR lets you recover changes made since the last backup to Element Catalog (ECF), Element Catalog Index (EIX),
CA EndevorPackage Control File (PCF), Master Control File (MCF), and base and delta libraries.
PITR does not include a mechanism to back up and recover source output libraries or processor outputs (for example object modules, load modules, listings). Source output libraries and processor outputs may be backed up during normal processor execution and recovered through manual procedures, or regenerated after the PITR process has been completed.
PITR builds GENERATE SCL for elements that have been affected by the recovery process.
PITR is based on change journaling. This fact means that each change created by a
CA Endevorrequest is logged to a journal data set before the change is actually executed by
CA Endevor. Once the change has been made, a confirmation record is written to the journal, indicating whether the change was successful or unsuccessful.
The following illustrates
CA Endevorwithout PITR:
The following illustrates
CA Endevorwith PITR:
CA L-Serv must be enabled to use the PITR feature. We recommend that when implementing the PITR feature you have available someone who is familiar with how CA L-Serv is set up at your site. You should have access to the following CA Common Services content.
How CA L-Serv Manages PITR Journal Files
CA L-Serv manages the journal data sets as file groups. When you define files to CA L-Serv as members of a group, you can instruct CA L-Serv to perform the following actions:
- Select specific files in a group for recording data.
- Switch to other files in the group when one file becomes full.
- Submit a batch job automatically to offload the information from files that are full.
For more information about file groups, see the CA Common Services for z/OS
How to Activate Journaling
After you define the journal data sets to CA L-Serv, activate journaling for the following items:
- Site level changes (the Package Control File, element catalog, and element catalog index), by specifying a CA L-Serv Group ID in the JRNLGRP parameter in the TYPE=MAIN section of the C1DEFLTS table.The TYPE=MAIN JRNLGRP parameter is required if PITR is activated.
- Element and environment definition changes (Master Control File, base and delta libraries), by specifying a CA L-Serv Group ID in the JRNLGRP parameter in the appropriate TYPE=ENVIRONMENT section of the C1DEFLTS table.For more information about how to specify group IDs in the C1DEFLTS table, see How to Modify the C1DEFLTS Table.
Journaling applies to any
CA Endevorprocessing that changes the information in the data sets (ECF, EIX, PCF, MCF, base, and delta libraries) that are under the protection of journaling.
There are three steps in the journaling process:
- Before executing a request that will change information,CA Endevorrecords the change in the current journal data set.
- CA Endevormakes the change.
- Upon completion of the update,CA Endevorwrites a confirmation record to the journal data set indicating whether the update was successful or failed.
If any of these three steps is not completed, the requested action fails.
If CA L-Serv is not available, or none of the specified journal data sets are available, or all journal data sets are full, the requested action fails.
Example: Using the Journaling Process
Assume that element PROGX, version 1.0, is located at Stage 2 in the development environment, and that a modified version of PROGX is being added to Stage 1. The journaling activity that takes place at each step of the ADD action is described in the following items:
- PROGX (1.0) copied back to Stage 1.
- The MCF record, element base and element delta for PROGX (1.0) are written to the journal.
- PROGX (1.0) compared with modified version being added, and a delta is created.The MCF record, element base and element delta for PROGX (1.1) are written to the journal.
- The generate processor is executed.The PROGX (1.1) MCF record is written to the journal.
- The component list is updated.The PROGX (1.1) MCF record, component base and component delta are written to the journal.
In general, all components associated with a change to an element are written to the journal data set. This point means that, for example, if a source change is made, the MCF record, element base and element delta are written to the journal. If an element component list is modified, the MCF record, component base and component delta are written to the journal.
How to Offload Journal Data Sets
You can instruct CA L-Serv to automatically submit a batch job when the current journal data set in a group becomes full. This job offloads the information to an archive file, reinitializes the data set, and begins writing to the next data set in the group.
For more information about how to set up CA L-Serv to submit this job automatically, see How to Define Journaling Components to CA L-Serv.
Setting up the archive files as generation data groups (GDGs) assures that each offloaded journal is fully accessible.
When CA L-Serv starts up, if it detects either a full or partially full journal data set it invokes the archive JCL for that data set.
The Recovery Utility
The Recovery utility uses the journal archive files as input. The utility allows you to do the following:
- List the transactions in the archive files.
- Recover these transactions from the archive files.
The Recovery utility uses the recovery utility control statements to determine which transactions to recover.
The offloaded journal data sets can be concatenated in any order since all journal log entries are sorted prior to processing.
The recovery utility processes the journal information in the following order:
- It discards records that do not meet the selection criteria.
- It discards records that meet the selection criteria but do not meet the from/to date and time criteria.
- It sorts the remaining entries by the journal date and timestamp.
- It discards any journal entries that have a negative confirmation record.
- It compares the journal file footprint dates and times with the footprint dates and times in the current MCF, PCF, and ELIB VSAM base and delta libraries, replacing files as necessary from the journal in the backup files.
- It schedules SCL to be written whenever an element master record is created or updated by a journal file transaction.
- It deletes the scheduled SCL command whenever the element master record is deleted by a subsequent journal file transaction
- After all the journal transactions have been processed the utility writes all remaining scheduled SCL statements to the C1SCL1 data set.
How to Enable Journaling
- Step 1. Determine Naming Conventions
- Step 2. Write Archive JCL
- Step 3. Allocate Journal and Archive Data Sets
- Step 4. Define the Journaling Components to CA L-Serv
- Step 5. Modify the C1DEFLTS Table
How to Determine Naming Conventions
The first step in enabling journaling is to decide on a naming convention for the following:
- PITR journal data sets.
- Journal group IDs used to reference groups of journal data sets.
- Generation data groups (GDGs) to be used as archive files.
The naming conventions presented next are only suggestions.
Consider including the group ID in the names of both the journal and the archive files. For example, four journal files in a group named GRP1 might be named as follows:
NDVR.GRP1.JOURNAL1 NDVR.GRP1.JOURNAL2 NDVR.GRP1.JOURNAL3 NDVR.GRP1.JOURNAL4
The corresponding GDG might be named as follows:
CA L-Serv accesses the journal data sets using a journal group ID. Each journal group ID can reference one or more journal data sets. The data sets associated with a particular group ID can be the journal data sets for a Package Control File, the data sets for a particular environment, or a combination. Group names can be up to four characters in length.
The PITR process can be streamlined somewhat by using a single group ID for all the journal data sets at a site.
For suggestions on setting up groups for journal data sets, see Implementation Scenarios.
How to Write Archive JCL
When CA L-Serv tries to write to a journal data set that is full, it marks the data set as unavailable and issues a console message.
When a data set becomes full, CA L-Serv automatically selects the next available journal data set for recording subsequent change activity. Optionally, you can instruct CA L-Serv to submit automatically a batch job to offload the journal information to a sequential file (for example, to a tape), switch to the next available journal data set, and reinitialize the journal data set that has just been offloaded.
The automatic offloading of journal data set information is implemented using the ARCHIVE command of the CA L-Serv LDMAMS utility.
The JCL for archiving full journal data sets is in member BC1JJARC in iprfx.iqual.CSIQJCL. To use this JCL, modify it as necessary and include it in the data set referenced in the JCLLIB DD statement of the CA L-Serv start-up member in your site PROCLIB.
How to Allocate Journal and Archive Data Sets
Journal files are VSAM ESDS data sets. Create these data sets with the utility IDCAMS.
Journal files should be allocated with a maximum record size of 32,760. Journal archive files should have an LRECL of 32,756, and a maximum length of 32,760.
The files to be used to archive full journal data sets are best set up as generation data groups (GDG).
Separate journal data sets and journal archive GDGs should be defined for each
CA Endevorjournal group ID.
The size of the journal data sets depends on the amount of
CA Endevoractivity at your site and the size of your elements. Here are some general guidelines to follow:
- Environment and package records take up a relatively small percentage of the total space.
- When a journal data set is full, it is archived. The next journal data set must be at least large enough to accept the journal records created during the time while the preceding data set is being archived.
- We recommend using three or four journal data sets. Remember that smaller journal data sets require less time to archive, making them available again for journaling more promptly.
For example, consider a site with an average element size of 1,000 lines, with 500 updates per day to these elements. Since most actions involve one write of an element base, element delta, component list base, and component list delta, and two writes of the MCF, a size calculation would appear as follows:
- Element base and delta, 1,000 lines @ 80 characters 80,000
- MCF update1, 100
- Component list base and delta, 100 lines @ 100 characters 10,000
- MCF update1, 100
- Total bytes, allowing for approximation 100,000
Assuming 45,000 bytes per track, this means that an average
CA Endevoraction requires 2.5 tracks of journal data set space.
Assuming 500 transactions per day, there needs to be 1,250 tracks of journal data set space to handle one day's activity.
Allocating this space amongst three journal data sets means that each journal data set would be approximately 420 tracks. In this scenario, you might consider allocating a fourth journal data set to handle the package and environment definition updates.
Recommended Journal Data Sets
We recommend that at least two journal data sets, and preferably four, be allocated for each group. This practice lets CA L-Serv switch to the second journal data set when the first data set becomes full and, optionally, to submit a batch job to offload and reinitialize the first journal data set.
The JCL for defining a generation data group and journal data sets is in member BC1JJDEF in the iprfx.iqual.CSIQJCL data set. Before submitting this job, perform the following actions:
- Specify the name for the GDG. Consider including the group ID of the related journal group in the GDG name.
- Change as necessary the maximum number of data sets to be retained in the GDG. The default in this example is 100.
- Change the names of the journal data sets in the job according to your naming standards.
- Specify values for cylinders (CYL) and volume (VOLSER).
Do not specify a secondary extent for the cylinder allocation. Doing so prevents the journal files from filling up, defeating the purpose of journaling.
How to Define the Journaling Components to CA L-Serv
After allocating the journal files and defining a generation data group (GDG) for the archive files, you must define the journaling mechanism to CA L-Serv. Three members are involved in this process:
- The CA L-Serv PROC
For examples of how to set up journaling, see Implementation Scenarios.
CA L-Serv PROC
If you are using an existing CA L-Serv, modify the PROC for that CA L-Serv. If you are creating an L-Serv, write a PROC for that CA L-Serv. This start-up procedure must include an //LDMCMND DD statement, which points to the CA L-Serv parameter data set.
LDMPARM is the default name of a member in the CA L-Serv parameter data set that contains the parameters for the CA L-Serv to which you want to identify the PITR components. If you are using an existing CA L-Serv, modify the existing LDMPARM member for the CA L-Serv you want to use to include an ATTACH statement specifying the CA L-Serv type (local, remote, or host) and an INCLUDE statement referencing the member NDVRPARM. If you are using a new CA L-Serv, create this member.
An example of the syntax for the statements to be included in the LDMPARM member is shown next:
ATTACH FILESERVER,SERVERTYPE=HOST,COMMSERVER(operands) INCLUDE NDVRPARM
When included in a new or existing LDMPARM member, this syntax specifies a Host CA L-Serv, with L-Serv's communication server enabled, and specifies NDVRPARM as the member identifying the data sets to be managed by this CA L-Serv.
NDVRPARM is the suggested name for a member in the CA L-Serv parameter data set that contains an ADDFILE command for each
CA Endevorlibrary or PITR journal data set managed by L-SERV. A sample NDVRPARM member in an instance where CA L-Serv is being used to manage journal data sets is shown next:
************************************************************* *** JOURNAL FILES ************************************************************* ADDPOOL 13 (32768,100) ADDFILE JRNL1 uprfx.uqual.ugrpid.JOURNAL1 GROUP=ugrpid, OPTION=(SUBMIT) POOL=13, JCLMEMBER=BC1JJARC ADDFILE JRNL2 uprfx.uqual.ugrpid.JOURNAL2 GROUP=ugrpid, OPTION=(SUBMIT) POOL=13, JCLMEMBER=BC1JJARC ADDFILE JRNL3 uprfx.uqual.ugrpid.JOURNAL3 GROUP=ugrpid, OPTION=(SUBMIT) POOL=13, JCLMEMBER=BC1JJARC ADDFILE JRNL4 uprfx.uqual.ugrpid.JOURNAL4 GROUP=ugrpid, OPTION=(SUBMIT) POOL=13, JCLMEMBER=BC1JJARC
The ADDFILE and GROUP= clauses are required for journal files. The OPTION=(SUBMIT) and JCLMEMBER= clauses are required for automatic archiving. The ADDPOOL and POOL= clauses are optional but recommended.
Do not use the APPEND parameter of the ADDFILE statement when identifying journal files or
CA Endevorfiles to CA L-Serv.
How to Modify the C1DEFLTS Table
In addition to identifying the journaling components to CA L-Serv, you also must modify the C1DEFLTS table to include the journal group IDs for the journal files, and to identify the subsystem name associated with the CA L-Serv address space being used to implement journaling.
The syntax for including this information in the C1DEFLTS table is shown:
The following describes the syntax:
- group idThe journal group ID associated with the journal files.
- nnnnThe subsystem name for CA L-Serv being used to implement journaling. The default CA L-Serv subsystem ID is LSRV.
You must include JRNLGRP= statements in the following sections:
- The TYPE=MAIN section of the C1DEFLTS table to enable journaling in the Package Control File.The TYPE=MAIN JRNLGRP parameter is required if PITR is activated.
- Each TYPE=ENVIRONMENT section of the MCF base and delta libraries (VSAM and non-VSAM) for which you want to enable journaling.
If you want to use the same journal group ID for more than one environment, include the journal group ID in each environment section of the C1DEFLTS table. We recommend that PITR be specified for all environments defined in the C1DEFLTS.
Journal Group Examples
Examples of the JRNLGRP= parameter syntax to be included in the TYPE=MAIN section and the TYPE=ENVIRONMENT sections of the C1DEFLTS are shown next:
C1DEFLTS TYPE=MAIN, X JRNLGRP=(group id,nnnn) GRP ID/SUBSYS NAME FOR PITR X C1DEFLTS TYPE=ENVRNMNT, X JRNLGRP=(group id,nnnn) GRP ID/SUBSYS NAME FOR PITR X
Reassemble the C1DEFLTS Table
After including the group IDs and CA L-Serv subsystem names for the journal data sets, you must reassemble the C1DEFLTS table to enable journaling.
The number of CA L-Servs required to implement PITR depends on the site configuration. This section presents common single and multiple CPU implementation scenarios, and provides guidelines for each.
Single CPU Implementation
The following is an example of a single CPU implementation. This configuration is suitable for sites where
CA Endevoris running on a single CPU.
How to Implement a Single CPU
The steps to implement this configuration are:
- Define CA L-Serv as Local, using the default subsystem name LSRV.
- Create or modify member NDVRPARM, LDMPARM, and the CA L-Serv PROC.
- Modify the C1DEFLTS table.For more information about modifying the C1DEFLTS table, see "How to Modify the C1DEFLTS Table".
Multiple CPU Implementation Using Remote Journaling
The following is an example of a multiple CPU implementation with all journaling taking place on CPU 1. This is referred to as remote journaling. Use this configuration at sites where there is relatively heavy
CA Endevorusage on the CPU where CA L-Serv is managing the journal files, and relatively light usage on the remote CPU (CPU 2).
How to Implement a Multiple CPU
The steps to implement this configuration are:
- Set up CA L-Serv Host by:
- Defining it as Host, using the subsystem name LSRV.
- Creating or modifying members NDVRPARM, LDMPARM, and the CA L-Serv PROC, as described earlier in this section.
- Set up CA L-Serv Remote by:
- Defining it as Remote, using the subsystem name LSRV.
- Creating or modifying member LDMPARM, and the CA L-Serv PROC, as described earlier in this section. As a remote CA L-Serv, it does not manage any files and therefore does not need an NDVRPARM member.
- Set up communication between CA L-Serv Host and CA L-Serv Remote, referring to theCA Common Services for z/OSGetting Started Guideas necessary.
- Modify the C1DEFLTS table.For more information about modifying the C1DEFLTS table, see How to Modify the C1DEFLTS Table.
Performance Considerations for a Multiple CPU Implementation Using Remote Journaling
Because it requires only one set of journal data sets, this scenario represents the easiest way to set up PITR in a multiple CPU operating environment.
There is a trade-off to this scenario, namely that handling journaling remotely is somewhat slower than local journaling.
Multiple CPU Implementation Using Local Journaling
A Multiple CPU implementation with CA L-Serv controlling both the journal files and the ELIBs, with journaling taking place on each CPU is shown next. Use this configuration at sites where there is relatively heavy
CA Endevorusage on both CPU 1 and CPU 2.
How to Implement Multiple CPU Using Local Journaling
The steps to implement this configuration are:
- Set up CA L-Serv 1 and CA L-Serv 2 by:
- Defining both as Local, using the same subsystem name for each.
- Creating or modifying members NDVRPARM, LDMPARM, and the CA L-Serv PROC, as described earlier in this section.
- Modify the C1DEFLTS Table to include entries for CA L-Serv 1 and CA L-Serv 2.For more information about modifying the C1DEFLTS table, see "How to Modify the C1DEFLTS Table".
Performance Considerations for a Multiple CPU Implementation Using Local Journaling
Because this scenario requires two groups of journal data sets, performing periodic backups is somewhat more complicated. The trade-off is that journaling executes somewhat more quickly when it is performed locally.
Perform Periodic Backups of
When journaling is enabled, it is important to manage the archive files carefully. Perform periodic backups before the GDG becomes full.
To perform periodic backups of
- Clean out journal data sets that may contain information, by executing the JCL found in member BC1JJARG in the data set iprfx.iqual.CSIQJCL.
- Disable journaling by either issuing the CA L-SERV REMOVEFILE command or stop CA L-Serv using one of the following console commands:/F task,SHUTDOWN /P taskThese commands deactivate all functions running in the CA L-Serv address space. For information about CA L-Serv system commands refer to theCA Common Services for z/OS Getting Started Guide.
- After you have successfully removed the files from the control of CA L-SERV, change the SHR(1 3) to SHR(3 3). To do this, run job BC1JLSRV supplied in your iprfx.iqual.CSIQJCL library. This job is intended to ALTER the SHR attributes of the Master Control File (MCF), Package and ELib data sets from SHR (1 3) to SHR (3 3).
- BackupCA Endevor, using either the Unload Utility or your regular backup utility.
- Delete all the PITR Journal Archives.
- Restart CA L-Serv by either using the following following START command, or by using the CA L-SERV ADDFILE command to issue journaling again./S task parms
Perform Point in Time Recovery
CA EndevorPackage Control File, Master Control File, base library or delta library is lost, you can perform a point in time recovery. Before performing Point in Time Recovery, verify that there are no empty GDGs.
To perform a point in time recovery
- Execute the CA L-Serv LDMAMS utility to offload all used journal data sets.
- Disable PITR journaling to keep any new journaling from being issued.
- Restore allCA Endevordata sets to be recovered from the most current back-up (eitherCA EndevorUNLOAD or similar back-ups).
- Execute theCA EndevorRecovery utility.
The following sections discuss these steps in detail.
How to Execute the CA L-Serv LDMAMS Utility
The next step is to offload all used journal data sets to sequential data sets. The sample JCL for offloading journal data sets can be found in member BC1JJARG in iprfx.iqual.CSIQJCL. Before using this sample JCL, do the following:
- Replace UGRPID with the CA L-Serv group ID for the journal data sets.
- Replace uprfx.uqual.ugrpid.JRNLDATA with the GDG name used at your site for the archive data sets.
- If the CA L-Serv load library has not been included in LINKLST, specify the load library data set name in the STEPLIB DD statement. Otherwise remove the STEPLIB DD statement.
- Specify the unit, volser, and space parameters for the journal archive data set.
The ARCHIVE statement in this sample differs from the statement used to archive data sets that are full. The difference is the SWITCH parameter. When a data set in a CA L-Serv group is not full, this parameter tells CA L-Serv to switch to the next data set in the group after archiving whatever data is in the data set.
How to Disable Point in Time Recovery Journaling
Disable journaling by either issuing the CA L-SERV REMOVEFILE command or by using one of the following console commands:
/F task,SHUTDOWN /P task
These commands deactivate all functions running in the CA L-Serv address space. For more information about CA L-Serv system commands, see the
CA Common Services for z/OS Getting Started Guide.
How to Restore the Data Sets to Be Recovered
The first step in the Point in Time Recovery process is to restore the data sets that have been lost to the point of their most recent backup. This makes them available to the Recovery utility.
The utility uses the restored data sets as a baseline, recovering any transactions that have taken place since the most recent backup. Do this using the recovery procedure at your site.
How to Execute the Recovery Utility
The Recovery utility (program BC1PJRCV) uses the offloaded journal information to recover transactions that have occurred since the last backup.
Recovery Utility Syntax
The following is the syntax for the recovery utility:
┌──ALL──────────────────────────┐ ►►──┬─RECOVER─┬──¤──┼───────────────────────────────┼─¤──────────────────────────────────────────────► └─LIST────┘ ├─PKGDS─────────────────────────┤ ├─ENVironment──environment-name─┤ └─SYStem──system-name───────────┘ ►───¤──┬──────────────────────────────────┬──¤──.────────────────────────────────────────────────────►◄ ├─FROM DATE──date──┬────────────┬──┤ │ └─TIME──time─┘ │ └─TO DATE──date──┬────────────┬────┘ └─TIME──time─┘
This syntax is described as follows:
- RECOVER /LIST(Required) The RECOVER or LIST keyword must be the first word in the syntax. Use LIST if you want to list the contents of a journal file before recovering it.
- PKGDS(Optional) Indicates that you want to recover the package data set for the site.
- ENVIRONMENT(Optional) Indicates that you want to recover the named environment.
- SYSTEM(Optional) Indicates that you want to recover the named system.
- ALL(Default) Indicates that you want to recover the element catalog, element catalog index, package data set, MCF, base, and delta library information.
- FROM DATE, TIME(Optional) Allows you to specify a date and time from which you want to start recovering information.
- TO DATE, TIME(Optional) Allows you to specify a date and time through which you want to recover information.
To recover the package data set for a site, submit the following syntax:
To recover MCF, base and delta information for environment PROD, submit the following syntax:
RECOVER ENV PROD.
To recover MCF, base and delta information for environment PROD, system Finance, submit the following syntax:
RECOVER ENV PROD SYS FINANCE.
If, for some reason, the PROD environment should be restored as it was on July 19th (as opposed to all logged changes) the following clause would be specified:
RECOVER ENV PROD TO DATE 19JUL92 TO TIME 08:00.
The following statement would recover all logged changes (contained in the input sequential journal files) for the Package Control File and for all environments:
You can find the JCL to run the recovery utility in member BC1JJRCV in iprfx.iqual.CSIQJCL.
The statements in the JCL are described in the following list:
- C1MSGS1The C1MSGS1 DD statement specifies the destination for the Journal Recovery Execution Report.
- C1SUMMRYThe C1SUMMRY DD statement specifies the destination for the Journal Recovery Execution Summary Report.
- JOURNALThe JOURNAL DD statement identifies the data set containing the journal data to be recovered.
- C1SCL1The C1SCL1 DD statement identifies the data set containing the SCL statements written by the Recovery utility.
- BSTIPT01The BSTIPT01 DD statement contains syntax for this run of the Recovery utility.
Journal Recovery Execution Report
The Recovery utility automatically produces a two-part Journal Recovery Execution report. The Journal Recovery Execution Log contains the following sections:
- Transaction detail
- Transaction summary
The Journal Recovery Execution Summary contains the following sections:
- Data set activity summary
- SCL statement summary
- Processor execution summary
The Journal Recovery Transaction Detail Report
The transaction detail section of the Journal Recovery Execution Log reports on each journal transaction that is recovered. The following list shows the messages contained in the transaction detail section and the information provided by each message:
- JRCV032IThe transaction number, the journal date and timestamps, and the number of records in the transaction.
- JRCV015IThe kind of action.
- JRCV016ITheCA Endevorlocation associated with the member in the previous message.
- JRCV031IThe date and time of the most recent update to theCA Endevorentity described in this entry. If no information is available, a NOT FOUND message is returned.
- JRCV023IIndicates that generate SCL has been built for the entity.
- JRCV025IIndicates that the recover utility has issued a generate processor request for the element.
- JRCV026ITheCA Endevorlocation associated with the element to be generated.
- JRCV020IIndicates that the journal entry has been recovered, and provides the return code for the recovery process.
The Journal Recovery Journal Input Record Summary
The Journal Input Record Summary lists the number of records of each record type handled by the recovery utility. The following are the abbreviations used in this report:
- PCFPackage Control File.
- MCFMaster Control File.
- EBASEElement base.
- EDELTAElement delta.
- CBASEComponent list base.
- CDELTAComponent list delta.
The Journal Recovery Data Set Activity Summary
The data set section of the Journal Recovery Execution Report describes the activity recorded in the journal file for each data set in the journal file. The messages contained in this section are described in the following:
- JRCV100IThe data set usage byCA Endevor. Usage may be any of the following:
- ECFElement Catalog
- EIXElement Catalog Index
- CBASEComponent list base
- CDELTAComponent list delta
- EBASEElement base
- EDELTAElement delta
- MCFMaster Control File
- PCFPackage Control File
- JRCV113ITheCA Endevorlocation associated with the file. For example, a file used to store element base records might be used for base records associated with a particular environment, stage, system, and type. A Master Control file on the other hand is associated with only an environment and stage.
- JRCV101IIndicates the number of members created in this data set for the period covered by the journal file.
- JRCV102IIndicates the number of members updated in this data set for the period covered by the journal file.
- JRCV103IIndicates the number of members deleted in this data set for the period covered by the journal file.
The Journal Recovery SCL Statement Summary
The SCL statement summary portion of the Journal Recovery Execution Report shows the number of GENERATE statements written by
CA Endevorlocation (environment, stage) and inventory classification (system, subsystem, and type).