Point in Time Recovery

18.1
This article describes the
Endevor
Point in Time Recovery (PITR) feature.
The
Endevor
Unload/Reload/Validate utility provides a point of backup recovery mechanism. PITR extends this capability to the recovery of
Endevor
activity 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),
Endevor
Package 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 an
Endevor
request is logged to a journal data set before the change is actually executed by
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
Endevor
without PITR:
EndevorDB
EndevorDB
The following illustrates
Endevor
with PITR:
EndevorPITR
EndevorPITR
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
L-Serv
is set up at your site. You should have access to the following
Common Components and Services
content
.
How
L-Serv
Manages PITR Journal Files
L-Serv
manages the journal data sets as file groups. When you define files to
L-Serv
as members of a group, you can instruct
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
Common Components and Services
Administration Guide.
How to Activate Journaling
After you define the journal data sets to
L-Serv
, activate journaling for the following items:
  • Site level changes (the Package Control File, element catalog, and element catalog index), by specifying a
    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
    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
Journaling applies to any
Endevor
processing 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:
  1. Before executing a request that will change information,
    Endevor
    records the change in the current journal data set.
  2. Endevor
    makes the change.
  3. Upon completion of the update,
    Endevor
    writes 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
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:
  1. PROGX (1.0) copied back to Stage 1.
  2. The MCF record, element base and element delta for PROGX (1.0) are written to the journal.
  3. 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.
  4. The generate processor is executed.
    The PROGX (1.1) MCF record is written to the journal.
  5. 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
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
L-Serv
to submit this job automatically, see How to Define Journaling Components to
L-Serv
.
Setting up the archive files as generation data groups (GDGs) assures that each offloaded journal is fully accessible.
When
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:
  1. It discards records that do not meet the selection criteria.
  2. It discards records that meet the selection criteria but do not meet the from/to date and time criteria.
  3. It sorts the remaining entries by the journal date and timestamp.
  4. It discards any journal entries that have a negative confirmation record.
  5. 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.
  6. It schedules SCL to be written whenever an element master record is created or updated by a journal file transaction.
  7. It deletes the scheduled SCL command whenever the element master record is deleted by a subsequent journal file transaction
  8. 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
    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:
NDVR.GRP1.ARCHDATA
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
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,
L-Serv
automatically selects the next available journal data set for recording subsequent change activity. Optionally, you can instruct
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
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
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
Endevor
journal group ID.
Sizing Considerations
The size of the journal data sets depends on the amount of
Endevor
activity 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
Endevor
action 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
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
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
L-Serv
. Three members are involved in this process:
  • The
    L-Serv
    PROC
  • LDMPARM
  • NDVRPARM
For examples of how to set up journaling, see Implementation Scenarios.
L-Serv
PROC
If you are using an existing
L-Serv
, modify the PROC for that
L-Serv
. If you are creating an L-Serv, write a PROC for that
L-Serv
. This start-up procedure must include an //LDMCMND DD statement, which points to the
L-Serv
parameter data set.
LDMPARM
LDMPARM is the default name of a member in the
L-Serv
parameter data set that contains the parameters for the
L-Serv
to which you want to identify the PITR components. If you are using an existing
L-Serv
, modify the existing LDMPARM member for the
L-Serv
you want to use to include an ATTACH statement specifying the
L-Serv
type (local, remote, or host) and an INCLUDE statement referencing the member NDVRPARM. If you are using a new
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
L-Serv
, with L-Serv's communication server enabled, and specifies NDVRPARM as the member identifying the data sets to be managed by this
L-Serv
.
NDVRPARM
NDVRPARM is the suggested name for a member in the
L-Serv
parameter data set that contains an ADDFILE command for each
Endevor
library or PITR journal data set managed by L-SERV. A sample NDVRPARM member in an instance where
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
Endevor
files to
L-Serv
.
How to Modify the C1DEFLTS Table
In addition to identifying the journaling components to
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
L-Serv
address space being used to implement journaling.
The syntax for including this information in the C1DEFLTS table is shown:
JRNLGRP=(
group id,nnnn
)
The following describes the syntax:
  • group id
    The journal group ID associated with the journal files.
  • nnnn
    The subsystem name for
    L-Serv
    being used to implement journaling. The default
    L-Serv
    subsystem ID is LSRV.
You must include JRNLGRP= statements in the following sections:
  1. 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.
  2. 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
L-Serv
subsystem names for the journal data sets, you must reassemble the C1DEFLTS table to enable journaling.
Implementation Scenarios
The number of
L-Serv
s 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
Endevor
is running on a single CPU.
EndevorPITR2
EndevorPITR2
How to Implement a Single CPU
The steps to implement this configuration are:
  1. Define
    L-Serv
    as Local, using the default subsystem name LSRV.
  2. Create or modify member NDVRPARM, LDMPARM, and the
    L-Serv
    PROC.
  3. 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
Endevor
usage on the CPU where
L-Serv
is managing the journal files, and relatively light usage on the remote CPU (CPU 2).
EndevorMultiple
EndevorMultiple
How to Implement a Multiple CPU
The steps to implement this configuration are:
  1. Set up
    L-Serv
    Host by:
    • Defining it as Host, using the subsystem name LSRV.
    • Creating or modifying members NDVRPARM, LDMPARM, and the
      L-Serv
      PROC, as described earlier in this section.
  2. Set up
    L-Serv
    Remote by:
    • Defining it as Remote, using the subsystem name LSRV.
    • Creating or modifying member LDMPARM, and the
      L-Serv
      PROC, as described earlier in this section. As a remote
      L-Serv
      , it does not manage any files and therefore does not need an NDVRPARM member.
  3. Set up communication between
    L-Serv
    Host and
    L-Serv
    Remote, referring to the
    Common Components and Services
    Getting Started Guide
    as necessary.
  4. 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
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
Endevor
usage on both CPU 1 and CPU 2.
EndevorMultiCPU
EndevorMultiCPU
How to Implement Multiple CPU Using Local Journaling
The steps to implement this configuration are:
  1. Set up
    L-Serv
    1 and
    L-Serv
    2 by:
    • Defining both as Local, using the same subsystem name for each.
    • Creating or modifying members NDVRPARM, LDMPARM, and the
      L-Serv
      PROC, as described earlier in this section.
  2. Modify the C1DEFLTS Table to include entries for
    L-Serv
    1 and
    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
Endevor
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
Endevor
  1. Clean out journal data sets that may contain information, by executing the JCL found in member BC1JJARG in the data set iprfx.iqual.CSIQJCL.
  2. Disable journaling by either issuing the
    L-Serv
    REMOVEFILE command or stop
    L-Serv
    using one of the following console commands:
    /F task,SHUTDOWN /P task
    These commands deactivate all functions running in the
    L-Serv
    address space. For information about
    L-Serv
    system commands refer to the
    Common Components and Services
    Getting Started Guide
    .
  3. After you have successfully removed the files from the control of
    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).
  4. Backup
    Endevor
    , using either the Unload Utility or your regular backup utility.
  5. Delete all the PITR Journal Archives.
  6. Restart
    L-Serv
    by either using the following following START command, or by using the
    L-Serv
    ADDFILE command to issue journaling again.
    /S task parms
Perform Point in Time Recovery
If an
Endevor
Package 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
  1. Execute the
    L-Serv
    LDMAMS utility to offload all used journal data sets.
  2. Disable PITR journaling to keep any new journaling from being issued.
  3. Restore all
    Endevor
    data sets to be recovered from the most current back-up (either
    Endevor
    UNLOAD or similar back-ups).
  4. Execute the
    Endevor
    Recovery utility.
The following sections discuss these steps in detail.
How to Execute the
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
    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
    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
L-Serv
group is not full, this parameter tells
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
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
L-Serv
address space. For more information about
L-Serv
system commands, see the
Common Components and Services
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.
Recover Examples
To recover the package data set for a site, submit the following syntax:
RECOVER PKGDS.
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:
RECOVER ALL.
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:
  • C1MSGS1
    The C1MSGS1 DD statement specifies the destination for the Journal Recovery Execution Report.
  • C1SUMMRY
    The C1SUMMRY DD statement specifies the destination for the Journal Recovery Execution Summary Report.
  • JOURNAL
    The JOURNAL DD statement identifies the data set containing the journal data to be recovered.
  • C1SCL1
    The C1SCL1 DD statement identifies the data set containing the SCL statements written by the Recovery utility.
  • BSTIPT01
    The 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:
  • JRCV032I
    The transaction number, the journal date and timestamps, and the number of records in the transaction.
  • JRCV015I
    The kind of action.
  • JRCV016I
    The
    Endevor
    location associated with the member in the previous message.
  • JRCV031I
    The date and time of the most recent update to the
    Endevor
    entity described in this entry. If no information is available, a NOT FOUND message is returned.
  • JRCV023I
    Indicates that generate SCL has been built for the entity.
  • JRCV025I
    Indicates that the recover utility has issued a generate processor request for the element.
  • JRCV026I
    The
    Endevor
    location associated with the element to be generated.
  • JRCV020I
    Indicates 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:
  • PCF
    Package Control File.
  • MCF
    Master Control File.
  • EBASE
    Element base.
  • EDELTA
    Element delta.
  • CBASE
    Component list base.
  • CDELTA
    Component 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:
  • JRCV100I
    The data set usage by
    Endevor
    . Usage may be any of the following:
    • ECF
      Element Catalog
    • EIX
      Element Catalog Index
    • CBASE
      Component list base
    • CDELTA
      Component list delta
    • EBASE
      Element base
    • EDELTA
      Element delta
    • MCF
      Master Control File
    • PCF
      Package Control File
  • JRCV113I
    The
    Endevor
    location 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.
  • JRCV101I
    Indicates the number of members created in this data set for the period covered by the journal file.
  • JRCV102I
    Indicates the number of members updated in this data set for the period covered by the journal file.
  • JRCV103I
    Indicates 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
Endevor
location (environment, stage) and inventory classification (system, subsystem, and type).