Configuring checkpoint and journal data streams

Overview

The Model 204 sequential file processing facility defines and processes checkpoint and journal data streams. Using the logical I/O stream configurations available through the DEFINE STREAM command, recovery procedures can assure a complete and consistent database across a system failure.

The concatenated and ring configurations help overcome physical hardware and operating system limitations. The parallel configuration allows multiple data set copies. You can use concatenated, parallel, and ring configurations separately or in any combination for checkpoint and journal streams.

Sites with z/OS can also define the checkpoint and journal data streams with GDG data sets. GDG data sets can be the only configuration for your checkpoint and journal data streams or they can be part of your ring, concatenated, or parallel configurations.

This page describes each sequential I/O processing configuration.

DEFINE STREAM command

The Model 204 sequential file processing facility — DEFINE STREAM command — ensures a complete and consistent database across a system failure. The DEFINE STREAM command:

• Logs journal and checkpoint files to sequential data sets
• Automatically switches to alternate data sets on a file-full condition (concatenated and ring stream configurations)
• Writes multiple copies simultaneously (parallel stream configuration)
• Automatically creates a tape backup of checkpoint and journal files (ring stream configuration with tape offload)
• Automatically opens a sequentially numbered data set as needed — GDG data set.

You can copy the contents of a stream to another stream or single data set using the COPY command.

For examples and further explanation of the DEFINE STREAM command, see Example 1: Ring/parallel journal stream.

Using the DEFINE STREAM command

The following considerations apply to DEFINE STREAM commands:

• You must specify DEFINE commands before User 0 input, because both the journal and checkpoint streams are opened before the User 0 input line is processed.
• The order of DEFINE commands is not important. The definition of the stream is resolved at open time.
• Members of a stream are reserved when the stream is open, preventing other Model 204 users from opening them.
• If a ring stream is defined, to prevent exhausting the journal stream capacity, the members in the ring are offloaded to tape as they fill up.
• The control stream is a very small data set and no DCB attributes are required for its allocation.

Note: Do not use the prefix TAPE; it is a reserved prefix used by deferred update data sets. Using this prefix with a dynamically allocated offload stream can cause problems with checkpoint ring streams.

See DEFINE STREAM command for information about how to set up a DEFINE STREAM command with the options suitable to your site.

Off load and control streams overview

The off load stream can be any stream configuration. The next section provides details on offload processing.

Offload is performed via a Model 204 pseudo subtask (PST), if there is a PST available when the offloffload process begins. The number of subtasks specified on User 0's parameter line (NSUBTKS) must specify enough subtasks to include all offload processes that begin during Model 204 operation, such as one subtask for each ring stream defined in the run. If the PST cannot be started, the offload process is done synchronously, using the current user's server.

Pseudo subtasks are discussed in Pseudo subtasks. NSUBTKS is described in NSUBTKS parameter.

The control stream is used during the open process when the ring or GDG stream is used for input. Data on the control stream provides the ability to recreate the status of the ring or GDG stream at the time of its last use as an output stream.

Ring stream configuration

Ring streams reduce the possibility of filling up journal or checkpoint data sets by processing them cyclically. When a ring stream member is full, it is offloaded to separately defined offload data sets. After the offload is complete, the ring member can be written to again as the checkpoint or journal data set. In addition to ring members and offload data sets, a control stream also maintains ring status information.

Ring stream configurations make it possible to write large amounts of journal and checkpoint data without bringing down a Model 204 Online due to space constraints. For this reason, ring journaling is sometimes referred to as perpetual journaling.

Note: Long Online runs involve a trade-off between continuous access and recovery time. When recovery processing searches for checkpoints in offload data sets, recovering a large ring stream configuration can take a long time. Therefore, Rocket Software recommends bringing down an Online periodically even if ring stream configurations are used.

The use of ring streams for checkpointing is compatible with the CPMAX parameter.

For DEFINE STREAM and job control examples, see the Example 1: Ring/parallel journal stream section.

Output ring stream processing sequence

Output ring stream processing for checkpoints and journals follows these steps:

1. Records are written to one of the members of the cyclic group.
2. When a member stream is filled, it is closed and scheduled for asynchronous offloading.

   Offloading starts automatically when a user-specified (AUTOOFFLOAD) number of members become full, and it continues until all full members of the ring are offloaded. The auto-offload threshold cannot exceed the number of ring members minus one.

3. The next member of the ring is opened and output processing to the ring continues.
4. The stream is considered full when all members of the ring become full and the offload stream is full, or when the control stream becomes full.
5. The offload stream is switched when no members are left to offload.

Note: Dynamic allocation of ring stream members can cause unpredictable results during member switching.

Types of off load streams

The offload stream in a ring configuration can be any type: concatenated, ring, or parallel. Concatenated and parallel streams are explained later on this page. And the Example 1: Ring/parallel journal stream section shows a ring configuration with parallel members.

• If the offload stream is a concatenated stream, the current member of the concatenated stream is closed, and the next member is left unopened until further offloading begins.
• If any other type of stream is used for the offload stream, the offload stream is left open when the offload process enters an idle state.

Off loading and the CLOSE option

Offloading activity that occurs when the ring is closed depends on the presence or absence of the CLOSE option on the stream definition.

The default action is to fully offload the ring. This implies that the offload stream is opened (if necessary) and all members of the ring containing previously un-offloaded records are scheduled for offloading.

To bypass the default process, specify CLOSE=NOAUTO, which implies that the offload stream does not contain all the records that have been written to the ring.

Off loading and system termination

Offloading activity that occurs during system termination is dependent on the option used when the ring is closed.

• The default action, if the offload stream is open when an EOJ command is issued, is to leave the offload stream open even if the offload process enters an idle state.

  Leaving the offload stream open allows the contents of the last ring member to be offloaded to the same offload stream member (assuming that the offload stream is a concatenated stream).

• If, prior to the ring stream being closed, the offload process enters an idle state after the EOJ command is issued, the offload stream is closed when the process becomes idle.
• If the option not to have a complete copy of all ring records on the offload stream is taken (CLOSE=NOAUTO), any offload process in progress when an EOJ is issued terminates immediately.

I/O error detection

An I/O error is detected for the entire ring when an I/O error occurs on a ring member while it is filling, a ring member while it is offloading, or a control stream on output.

When an I/O error or a file-full condition occurs on the offload stream during output, the ring does not reflect a file-full condition until all remaining empty members are filled.

Off loading ring streams from disk to tape

To off load ring streams from disk to tape, issue one of the following commands:

• DEFINE STREAM command with the AUTOOFFLOAD option

  Members of ring configurations are automatically off loaded when the number of full members reaches the specified threshold.

• OFFLOAD command issued by the operator any time during system operation

  The ring member being filled when the command is issued is treated as full (at the time of the next write to the ring stream) even if a file-full condition is not reached. Processing is the same as that which occurs automatically when the AUTOOFFLOAD threshold is reached.

  Use OFFLOAD in ring configurations to:

  • Force offloading if the AUTOOFFLOAD threshold has been set to a high value and system shutdown is anticipated before the value is reached
  • Control unplanned requirements of hardware availability, such as tape drives needed for the offload process

  If the ring stream already has an active offload process, the command is ignored.

• The COPY command

  Issue a COPY command to complete offloading ring streams that are interrupted by system failures or for which the CLOSE=NOAUTO option is specified in the ring stream definition. COPY processing reads the entire stream to the point of the system crash and copies it to another stream.

  Use the COPY command if the stream is input to the MERGEJ utility:

  • If the original offload stream is defined as a concatenated stream, and an offload was in progress at the time of the crash, the copying process can be started from the beginning of the offload stream member that was in use at the time of the crash.
  • If the original offload stream was either a data set or any stream configuration other than concatenated, the entire offload stream must be copied.

Ring streams and recovery

Input ring streams (recovery)

The definition of the input ring stream must be identical to the definition used when the stream was originally created.

When a ring stream is opened for input, the control stream determines the order in which the ring members are processed.

The last active member is normally the first member from which records are retrieved.

To improve recovery performance if recovery input is a ring stream, the recovery routine first attempts to find the specified checkpoint in the ring members before trying to read the offload stream.

I/O error processing for input ring streams

An I/O error is detected for the entire ring when an I/O error occurs on one of the following:

• Offload stream on input
• Control stream on input
• Ring members on input, except for an active member at the time of a system crash

Ring streams as input to RESTART recovery

The following considerations apply when using ring streams as input to RESTART recovery:

• If all the data is migrated to the offload member (through CLOSE=AUTO, for example), you need to specify only the offload member or the input stream. However, this method of recovery is slow.
• If you are uncertain whether all data has migrated to the offload member, define the input stream again as an exact duplicate of the previous output stream.
• During the recovery run, the DEFINE commands must duplicate the definitions in the previous run, with the following exceptions. The DEFINE STREAM name for the previous:
  • Journal stream should be changed from CCAJRNL to CCARF.
  • Checkpoint stream should be changed from CHKPOINT to RESTART.
  • Sub transaction checkpoint stream should be changed from CHKPNTS to RESTARTS.
• You must code recovery run DEFINE commands before User 0 input.
• AUTOOFFLOAD is an extraneous keyword during recovery, although it is meaningful in output processing.
• The same data sets used during the run must be used in the recovery run with a DISP of OLD.
• If the CCARF stream is defined as a ring, RESTART recovery attempts to find the roll back checkpoint by first searching the ring members. If the checkpoint is not found, the offload stream is opened from the beginning. You can save substantial recovery time by ensuring that a checkpoint is contained within the ring members.

Concatenated stream configuration

A concatenated stream is a group of sequential data sets or streams that are accessed in a serial fashion. I/O is switched to the next member when an end-of-file (EOF) or a stream-full condition is reached.

Concatenated streams reduce the chance of a checkpoint or journal file-full condition.

Processing sequence

Concatenated stream processing follows these steps:

1. All members of the group are opened with a reserve status when a concatenated stream is opened. Open with a reserve status causes Model 204 to:
   • Set up the control blocks necessary to process the stream
   • Enqueue members of the stream to restrict their use as output for other users
   • Perform a recursion check to prevent backward references by any definition in the hierarchy

   Open with reserve status does not mean that a physical open was performed or that the allocation was done.

2. If any errors occur during this process, the concatenated stream is considered unusable. Acquired storage is released and an appropriate error message is issued. The first member is physically opened after all members achieve reserve status. If the physical open fails at this point, the concatenated stream is again considered unusable and processing is terminated.
3. After a successful open, records are read from or written to the member until an end-of-data or file-full condition is detected.
4. The next member in the list is physically opened and processed when the end-of-data or file-full condition is recognized.
5. An I/O error that occurs on any member of the stream is reflected immediately as an I/O error for the entire stream.
6. An end-of-data or file-full condition for the concatenated stream is not recognized until the condition occurs on the last member of the stream.

For an example of a concatenated stream, see the Example 3: Concatenated tape off load stream for z/OS section.

Parallel stream configuration

A parallel stream is a group of sequential data sets or any combination of streams used in a redundant manner. Every I/O to or from the stream is duplicated on each member, as follows:

• Each logical record written to the stream is duplicated on all the members of the stream.
• Each logical record read from the stream causes a read to be performed on all the members concurrently. The stream read is satisfied by the record from the first member of the stream that completes the input operation without error.

A parallel stream is useful when multiple copies of a data set are required.

Parallel streams and recursions

Model 204 allows only four parallel members and sixteen stream recursion levels. For example, only one member of a two-member parallel stream can have a subsequent parallel stream definition. Likewise, streams may be only sixteen levels deep. If either limit is exceeded. Model 204 displays the following error message:

M204.0093: %C IS A RECURSIVE STREAM DEFINITION

Checkpoint configuration support

You may define the CHKPOINT and CHKPNTS data sets using parallel streams. The only restriction on CHKPOINT and CHKPNTS stream definitions is that they may not contain CMS data sets. There are no restrictions on the type of stream you can use to define the CCAJRNL and CCAJLOG journals.

Parallel stream open processing

Parallel stream open processing does the following:

• Allocates storage for control blocks and buffers for all the member streams:
  • Parallel stream open is successful, if the parallel stream control block can be allocated and the number of members successfully opened is equal to or greater than the user-specified minimum (MINAVAIL parameter).
  • Parallel stream open fails, if the stream control block cannot be allocated, or if the user-specified minimum number of members fails to open. Error messages are displayed in the audit trail and at the user's terminal.
• Enqueues physical data sets
• Opens physical data sets

Output parallel streams processing

Output parallel streams are used for checkpoints and journals. An I/O error or file-full condition detected on a member of an output parallel stream causes all the outstanding output operations on all the available stream members to complete.

The following sequence of events occurs:

1. System detects all error conditions at the same point in time.
2. Status of each member of the parallel stream is examined.
3. Number of currently available members that did not have any error conditions is counted.
4. Subsequent error processing depends on two factors:
   • Revised number of available members
   • User-defined minimum available member value (MINAVAIL parameter)

Note: Parallel output data sets must all use the same device type and space allocation. Do not specify secondary space.

Output error processing

The following rules apply to output parallel stream error processing:

• If the number of available members with no errors remains at or above the specified MINAVAIL value, the available members with errors are logically removed from the parallel stream and considered unavailable for further output operations. A message M204.0096 is displayed in the audit trail and at the operator console for each unavailable member.

  Unavailable members are made available again, if the parallel output stream is rewound.

• If the revised number of available members falls below the specified MINAVAIL value, the parallel processing routine determines the number of records successfully written to each available member stream, regardless of the member's error condition.

  Member streams are processed in order by their respective record counts, starting with the member with the fewest records.

• If the number of members available prior to the error was greater than the specified MINAVAIL value, member streams are made unavailable until the number of available members falls below the MINAVAIL value.

  When the number of available members falls below the MINAVAIL value, or if the number of members available prior to the error was equal to MINAVAIL, the following messages are displayed in the audit trail, at the operator console, and at the user's terminal:

  M204.0095 PARALLEL STREAM stream-name DISABLED. NUMBER OF MEMBERS BELOW MINAVAIL. M204.1826 MEMBER each-member-name OF PARALLEL STREAM stream-name HAS nnn RECORDS

• If any of the selected member streams had either no error conditions or a file-full condition, the parallel stream reflects a file-full condition.
• If all the member streams have I/O error conditions, the parallel stream reflects an I/O error.

Input parallel stream processing

Input parallel streams are used for recovery. When you use the parallel stream for input, you must define the input parallel stream with the same parameters specified in the output definition.

Input stream records are retrieved as follows:

• Records are retrieved simultaneously from all the members, but only one of these members is considered the active member.
• Records retrieved from inactive members are ignored as long as the active member does not encounter an I/O error.
• If the active member encounters an I/O error or an end-of-data condition, the member is closed and the next member in the group is marked as the active member.

The parallel stream input routine uses the same error handling decision logic as output parallel processing, described in the Output error processing section.

Perpetual journaling for z/OS

For z/OS only, Model 204 provides a stream definition of type GDG. A stream defined with the GDG option behaves as a single member ring stream without an offload member. When a GDG generation becomes full, the next generation in sequence is opened. The corresponding generation data set name is written to the stream control file. The control file is written in a readable format so that all members allocated may be inspected.

An example of a CCAJRNL stream for an Online run is:

DEFINE STREAM CCAJRNL WITH SCOPE=SYSTEM GDG=J1 CONTROL=CTLJ DEFINE DATASET J1 WITH SCOPE=SYSTEM NEW CATALOG - DSNAME=your.ccajrnl.gdgdsn GEN=+1 CYL PRI nnn UNIT=unit VOLUME=volser DEFINE DATASET CTLJ WITH SCOPE=SYSTEM COND CATALOG TRACK PRI 1 - DSNAME=your.gdgcontrol.dsn VOLUME=volser UNIT=unit

During recovery, the correct GDG generations are automatically opened. When you use a GDG stream for input you must define the GDG input stream with the same parameters specified in the output definition. The corresponding recovery stream would be:

DEFINE STREAM CCARF WITH SCOPE=SYSTEM GDG=J1 CONTROL=CTLJ DEFINE DATASET J1 WITH SCOPE=SYSTEM OLD DSNAME=your.ccajrnl.gdgdsn DEFINE DATASET CTLJ WITH SCOPE=SYSTEM OLD DSNAME=your.gdgcontrol.dsn

Since a GDG data set is dynamically allocated each time it is opened, it must be defined in CCAIN using a DEFINE DATASET command. Otherwise, the Online will terminate during initialization.

Using the GDG option

Attention: If the SCRATCH option is specified and the LIMIT number for GDGs is exceeded, previous generations are deleted. This can result in a non-recoverable Online, because journal members are missing.

Rocket Software strongly recommends that you ensure that the LIMIT parameter specified in the GDG base definition is high enough to accommodate all generations required for an Online run. Also, ensure that the default NOSCRATCH option is specified.

Do not allocate GDGs with the SCRATCH option.

Note: The control stream is a very small data set and no DCB attributes are required for its allocation. Also, do not use GDGs as members of ring or concatenated stream for the CHKPNTS data set since the close process may lose the ability to determine which GDG generation is being filled.

Data Set Control Blocks (DSCBs) and GDGs

If your site uses pattern DSCBs, you might want to insert the SMSLIKE=your.site.gdg option in your DEFINE DATASET command, instead of using the UNIT=unit and VOLSER=volume options, as shown in the following example.

Set up the output stream using the following code as a guide:

DEFINE STREAM CCAJRNL WITH SCOPE=SYSTEM GDG=J1 CONTROL=CTLJ DEFINE STREAM CHKPOINT WITH SCOPE=SYSTEM GDG=C1 CONTROL=CTLC DEFINE DATASET J1 WITH SCOPE=SYSTEM SMSLIKE=pattern.GDG - DSNAME=your.site.GDG GEN=+1 CATALOG TRACK PRIMARY=100 - NEW LRECL=6749 BLKSIZE=6749 RECFM=F RETRYALLOC=3 - RETRYTIME=15 DEFINE DATASET C1 WITH SCOPE=SYSTEM SMSLIKE=pattern.GDG - DSNAME=your.site.GDG.CHKP GEN=+1 CATALOG TRACK - PRIMARY=100 NEW LRECL=6184 BLKSIZE=6184 RECFM=F - RETRYALLOC=3 RETRYTIME=15

Set up the input stream using the following code as a guide:

DEFINE STREAM CCARF WITH SCOPE=SYSTEM GDG=J1 CONTROL=CTLJ DEFINE STREAM CHKPOINT WITH SCOPE=SYSTEM GDG=C1 CONTROL=CTLC DEFINE DATASET J1 WITH SCOPE=SYSTEM OLD DEFINE DATASET C1 WITH SCOPE=SYSTEM OLD

Example 1: Ring/parallel journal stream

This example illustrates a ring output stream having parallel stream members. The use of a ring configuration reduces the chance of the journal stream becoming full. The use of parallel streams as ring and offload stream members reduces the chance of an I/O error disabling the stream.

In this example:

• OFFLOAD member is a parallel stream made up of two tape data sets.
• Members of the ring output parallel streams are disk streams.
• Defined CCAJRNL stream continues to be a valid output stream as long as at least one of each of the parallel members (MINAVAIL=1) remains available for output.

The following figure illustrates the concept of a ring output stream with parallel stream members:

Ring output stream with parallel stream members

DEFINE STREAM example

The following DEFINE STREAM commands produce the configuration shown in the "Ring output stream with parallel stream members" figure, above:

DEFINE STREAM CCAJRNL WITH SCOPE=SYSTEM - RING=(A,B,C) OFFLOAD=D CONTROL=E AUTOOFFLOAD=2 DEFINE STREAM A WITH SCOPE=SYSTEM - PARALLEL=(JRNL1,JRNL2) MINAVAIL=1 DEFINE STREAM B WITH SCOPE=SYSTEM - PARALLEL=(JRNL3,JRNL4) MINAVAIL=1 DEFINE STREAM C WITH SCOPE=SYSTEM - PARALLEL=(JRNL5,JRNL6) MINAVAIL=1 DEFINE STREAM D WITH SCOPE=SYSTEM - PARALLEL=(TAP1,TAP2) MINAVAIL=1 DEFINE STREAM E WITH SCOPE=SYSTEM - PARALLEL=(CTL1,CTL2) MINAVAIL=1

You can use the processing results of this defined CCAJRNL stream as input to recovery.

z/OS JCL

The following example shows z/OS JCL for the ring and parallel journal stream configuration:

//JRNL1 DD DSN=M204.JRNL1,DISP=OLD //JRNL2 DD DSN=M204.JRNL2,DISP=OLD //JRNL3 DD DSN=M204.JRNL3,DISP=OLD //JRNL4 DD DSN=M204.JRNL4,DISP=OLD //JRNL5 DD DSN=M204.JRNL5,DISP=OLD //JRNL6 DD DSN=M204.JRNL6,DISP=OLD //CTL1 DD DSN=M204.CTL1,UNIT=DISK,DISP=(NEW,CATLG) // SPACE=(CYL,(1,1)) //CTL2 DD DSN=M204.CTL2,UNIT=DISK,DISP=(NEW,CATLG) // SPACE=(CYL,(1,1))

Allocate the offload tape data sets dynamically via the DEFINE DATASET command, as in the following z/VSE example.

z/VSE JCL

The following example shows z/VSE JCL for the ring and parallel journal stream configuration:

// DLBL JRNL1,'M204.JRNL1',99/365,SD // EXTENT SYS021,SYSWK1,,,1000,13000 // DLBL JRNL2,'M204.JRNL2',99/365,SD // EXTENT ...... // DLBL JRNL3,'M204.JRNL3',99/365,SD // EXTENT ...... // DLBL JRNL4,'M204.JRNL4',99/365,SD // EXTENT ...... // DLBL JRNL5,'M204.JRNL5',99/365,SD // EXTENT ...... // DLBL JRNL6,'M204.JRNL6',99/365,SD // EXTENT ...... // TLBL SYS041,'M204.TAPE1',99/365 // ASSGN SYS040,TAPE // TLBL SYS040,'M204.TAPE2',99/365 // ASSGN SYS041,TAPE // DLBL CTL1,'M204.CTL1',99/365,SD // EXTENT SYS022,SYSWK2,,,1000,100 // DLBL CTL2,'M204.CTL2',99/365,SD // EXTENT ..... . . // EXEC ONLINE,SIZE=AUTO DEFINE DATASET TAP1 WITH SCOPE=SYSTEM FILENAME=SYS040 DEFINE DATASET TAP2 WITH SCOPE=SYSTEM FILENAME=SYS041 (Other DEFINE statements as shown in the original example) PAGESZ=6184,RCVOPT=9, ...

CMS FILEDEFs

The following example shows the CMS FILEDEFs for the ring and parallel journal stream configuration:

FILEDEF JRNL1 mode DSN M204 JRNL1 FILEDEF JRNL2 mode DSN M204 JRNL2 FILEDEF JRNL3 mode DSN M204 JRNL3 FILEDEF JRNL4 mode DSN M204 JRNL4 FILEDEF JRNL5 mode DSN M204 JRNL5 FILEDEF JRNL6 mode DSN M204 JRNL6 FILEDEF CTL1 mode DSN M204 CTL1 FILEDEF CTL2 mode DSN M204 CTL2

Allocate the offload tape data sets dynamically via the DEFINE DATASET command, as in the previous z/VSE example.

Example 2: Parallel checkpoint stream

The following example uses a parallel stream of disk data sets. Because you can use the CPMAX parameter to prevent the checkpoint stream from filling up, define the stream as parallel and not as a ring. The parallel stream also provided duplicate copies of the checkpoint stream.

Conceptually, the checkpoint stream is as shown in the following figure:

Checkpoint stream

DEFINE STREAM command for parallel checkpoint stream

The DEFINE STREAM command used for the parallel stream in the "Checkpoint stream" figure above is:

DEFINE STREAM CHKPOINT WITH SCOPE=SYSTEM - PARALLEL=(CHKA,CHKB,CHKC) MINAVAIL=2

The following considerations apply to this DEFINE STREAM command:

• Only one DEFINE STREAM command is required for this configuration of a checkpoint stream.
• To guarantee that you always have at least two good copies, set MINAVAIL to 2.

  The CHKPOINT stream continues to be valid output as long as at least two of the parallel members remain available for output.

Recovery processing

For a recovery run, the following User 0 input line is required:

DEFINE STREAM RESTART WITH SCOPE=SYSTEM - PARALLEL=(CHKA,CHKB,CHKC) MINAVAIL=2

Note: Only the STREAM option of the DEFINE command is valid for a recovery processing.

z/OS JCL

The following example shows the z/OS JCL for a parallel checkpoint stream configuration:

// CHKA DD DSN=M204.CHKA,DISP=OLD // CHKB DD DSN=M204.CHKB,DISP=OLD // CHKC DD DSN=M204.CHKC,DISP=OLD

z/VSE JCL

The following example shows the z/VSE JCL for a parallel checkpoint stream configuration:

• Original run

  // DLBL CHKA,'M204.CHKA',99/365,SD // EXTENT SYS021,SYSWK1,,,1000,13000 // DLBL CHKB,'M204.CHKB',99/365,SD // EXTENT SYS021,SYSWK1,,,1400,13000 // DLBL CHKC,'M204.CHKC',99/365,SD // EXTENT SYS021,SYSWK1,,,2700,13000

• Recovery run

  // DLBL CHKA,'M204.CHKA',,DA // EXTENT SYS021,SYSWK1,,,1000,13000 // DLBL CHKB,'M204.CHKB',,DA // EXTENT SYS021,SYSWK1,,,1400,13000 // DLBL CHKC,'M204.CHKC',,DA // EXTENT SYS021,SYSWK1,,,2700,13000

CMS FILEDEFs

The following example shows the CMS FILEDEFs for a parallel checkpoint stream configuration:

FILEDEF CHKA mode DSN M204 CHKA FILEDEF CHKB mode DSN M204 CHKB FILEDEF CHKC mode DSN M204 CHKC

Example 3: Concatenated tape off load stream for z/OS

If tape drives are limited and you cannot dedicate one drive for a tape offload stream, you can define the offload stream as a concatenated stream. When the offload stream is concatenated, each member is physically opened only when an offload is required and is automatically closed when the offload is completed.

With the use of dynamic allocation during open, a DEFINE DATASET command for each member of the concatenated offload stream is sufficient to ensure that tape drives are allocated during offload processing and freed when the offload completes. When the offload process is idle, tape drives are not necessary. No DD card referencing the offload stream should be present.

Conceptually, the stream configuration is shown in the following figure:

Stream configuration

DEFINE STREAM commands

The DEFINE STREAM commands used for the concatenated stream shown in the "Stream configuration" figure, above:

DEFINE STREAM CCAJRNL WITH SCOPE=SYSTEM - RING=(JRNL1,JRNL2,JRNL3) OFFLOAD=JOFFLOAD - CONTROL=JCTL CLOSE=NOAUTO AUTOOFFLOAD=2 DEFINE STREAM JOFFLOAD WITH SCOPE=SYSTEM - CONCATENATE=(TAP1,TAP2) DEFINE DATASET TAP1 WITH SCOPE=SYSTEM - DSNAME=M204.TAPE1 UNIT=TAPE CATALOG DEFINE DATASET TAP2 WITH SCOPE=SYSTEM - DSNAME=M204.TAPE2 UNIT=TAPE CATALOG

The following considerations apply to this DEFINE STREAM command:

• The AUTOOFFLOAD value of 2 triggers the offload process when ring members JRNL1 and JRNL2 fill up.

  At this point, the concatenated offload member TAP1 is physically opened and a tape mount is requested.

• When the offload of JRNL1 and JRNL2 completes, TAP1 is closed and the tape drive is freed. Other tape mounts are not requested until the offload process is once more triggered, this time when JRNL3 and JRNL1 fill up.
• If JRNL3 does not fill up before termination processing, other offloads cannot be done, because the DEFINE STREAM command specified CLOSE=NOAUTO.

JCL for concatenated offload

The JCL required for the ring members and the control data set is:

//JRNL1 DD DSN=M204.JRNL1,DISP=OLD //JRNL2 DD DSN=M204.JRNL2,DISP=OLD //JRNL3 DD DSN=M204.JRNL3,DISP=OLD //JCTL DD DSN=M204.JCTL,DISP=OLD

Troubleshooting GDG streams using specific generations

In the unfortunate event that when using GDG streams, you need to use specific generations for recovery, take the following steps in the following example:

1. Your Online job using a journal GDG stream crashes. It creates journals G0001V00 and G0002V00.
2. You incorrectly submit the Online again without running recovery. This run creates journal G0003V00.
3. You bring down the second Online and want to run recovery for the first Online. Note that only files that were not updated in the second run can be recovered via RESTART recovery. Files that were updated in the second run would require media recovery.

At this point, you can no longer use the GDG stream definition for CCARF because the GDG stream control data set now points to G0003V00 as the current generation.

To recover from the initial crash, you must determine all of the generations used in that job and create single input data sets for CCARF and RESTART (if you used a GDG stream for checkpointing).

For example, if the run that crashed created generations 1 and 2 for the journal and 97 through 100 for the checkpoint, you could create single data sets with the following JCL:

//CCARF EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //* combine all journal generation data sets into one file: //SYSUT1 DD DISP=SHR,DSN=xxx.CCAJRNL.G0001V00 // DD DISP=SHR,DSN=xxx.CCAJRNL.G0002V00 //SYSUT2 DD DISP=SHR,DSN=xxx.single.CCARF //SYSIN DD DUMMY //* //RESTART EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //* combine checkpoint generation data sets into one file: //SYSUT1 DD DISP=SHR,DSN=xxx.CHKPOINT.G0097V00 // DD DISP=SHR,DSN=xxx.CHKPOINT.G0097V00 // DD DISP=SHR,DSN=xxx.CHKPOINT.G0098V00 // DD DISP=SHR,DSN=xxx.CHKPOINT.G0099V00 // DD DISP=SHR,DSN=xxx.CHKPOINT.G0100V00 //SYSUT2 DD DISP=SHR,DSN=xxx.single.RESTART //SYSIN DD DUMMY

The single data sets can then be used in your recovery job. If you need to use specific generations for media recovery, special considerations apply when using GDG streams.