Point in Time Recovery
This article describes the
EndevorPoint in Time Recovery (PITR) feature.
EndevorUnload/Reload/Validate utility provides a point of backup recovery mechanism. PITR extends this capability to the recovery of
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),
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 an
Endevorrequest 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
The following illustrates
L-Servmust 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-Servis set up at your site. You should have access to the following
Common Components and Servicescontent.
L-ServManages PITR Journal Files
L-Servmanages the journal data sets as file groups. When you define files to
L-Servas members of a group, you can instruct
L-Servto 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
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 aL-ServGroup 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 aL-ServGroup 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
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,Endevorrecords the change in the current journal data set.
- Endevormakes the change.
- Upon completion of the update,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.
L-Servis 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
L-Servto 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-Servto submit this job automatically, see How to Define Journaling Components to
Setting up the archive files as generation data groups (GDGs) assures that each offloaded journal is fully accessible.
L-Servstarts 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 toL-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:
L-Servaccesses 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
L-Servtries 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-Servautomatically selects the next available journal data set for recording subsequent change activity. Optionally, you can instruct
L-Servto 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
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-Servstart-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
Endevorjournal group ID.
The size of the journal data sets depends on the amount of
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
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
L-Servswitch 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
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:
For examples of how to set up journaling, see Implementation Scenarios.
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-Servparameter data set.
LDMPARM is the default name of a member in the
L-Servparameter data set that contains the parameters for the
L-Servto which you want to identify the PITR components. If you are using an existing
L-Serv, modify the existing LDMPARM member for the
L-Servyou want to use to include an ATTACH statement specifying the
L-Servtype (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
NDVRPARM is the suggested name for a member in the
L-Servparameter data set that contains an ADDFILE command for each
Endevorlibrary or PITR journal data set managed by L-SERV. A sample NDVRPARM member in an instance where
L-Servis 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
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-Servaddress 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 forL-Servbeing used to implement journaling. The defaultL-Servsubsystem 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
L-Servsubsystem names for the journal data sets, you must reassemble the C1DEFLTS table to enable journaling.
The number of
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
Endevoris running on a single CPU.
How to Implement a Single CPU
The steps to implement this configuration are:
- DefineL-Servas Local, using the default subsystem name LSRV.
- Create or modify member NDVRPARM, LDMPARM, and theL-ServPROC.
- 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
Endevorusage on the CPU where
L-Servis 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 upL-ServHost by:
- Defining it as Host, using the subsystem name LSRV.
- Creating or modifying members NDVRPARM, LDMPARM, and theL-ServPROC, as described earlier in this section.
- Set upL-ServRemote by:
- Defining it as Remote, using the subsystem name LSRV.
- Creating or modifying member LDMPARM, and theL-ServPROC, as described earlier in this section. As a remoteL-Serv, it does not manage any files and therefore does not need an NDVRPARM member.
- Set up communication betweenL-ServHost andL-ServRemote, referring to theCommon Components and ServicesGetting 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
L-Servcontrolling 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
Endevorusage on both CPU 1 and CPU 2.
How to Implement Multiple CPU Using Local Journaling
The steps to implement this configuration are:
- Set upL-Serv1 andL-Serv2 by:
- Defining both as Local, using the same subsystem name for each.
- Creating or modifying members NDVRPARM, LDMPARM, and theL-ServPROC, as described earlier in this section.
- Modify the C1DEFLTS Table to include entries forL-Serv1 andL-Serv2.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 theL-ServREMOVEFILE command or stopL-Servusing one of the following console commands:/F task,SHUTDOWN /P taskThese commands deactivate all functions running in theL-Servaddress space. For information aboutL-Servsystem commands refer to the.Common Components and ServicesGetting Started Guide
- After you have successfully removed the files from the control ofL-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).
- BackupEndevor, using either the Unload Utility or your regular backup utility.
- Delete all the PITR Journal Archives.
- RestartL-Servby either using the following following START command, or by using theL-ServADDFILE command to issue journaling again./S task parms
Perform Point in Time Recovery
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 theL-ServLDMAMS utility to offload all used journal data sets.
- Disable PITR journaling to keep any new journaling from being issued.
- Restore allEndevordata sets to be recovered from the most current back-up (eitherEndevorUNLOAD or similar back-ups).
- Execute theEndevorRecovery utility.
The following sections discuss these steps in detail.
How to Execute the
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 theL-Servgroup 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 theL-Servload 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-Servgroup is not full, this parameter tells
L-Servto 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-ServREMOVEFILE command or by using one of the following console commands:
/F task,SHUTDOWN /P task
These commands deactivate all functions running in the
L-Servaddress space. For more information about
L-Servsystem commands, see the
Common Components and ServicesGetting 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.
- JRCV016ITheEndevorlocation associated with the member in the previous message.
- JRCV031IThe date and time of the most recent update to theEndevorentity 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.
- JRCV026ITheEndevorlocation 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 byEndevor. 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
- JRCV113ITheEndevorlocation 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
Endevorlocation (environment, stage) and inventory classification (system, subsystem, and type).