Model 204 Ring Streams and Perpetual Journaling - Part 3
by Jim Damon
In Part 1 of this article (March 98), I outlined the basic mechanism of ring-stream journaling.
In Part 2 (April 98) I reviewed the following:
In this article, Part 3, I conclude the series with:
A ring-stream journal cannot be read by AUDIT204 or by the REGENERATE command. Therefore, a ring-stream journal must be converted to a single, sequential dataset for subsequent use by these utilities. This involves reading, in the correct order and using the CONTROL stream, all ring members and all offload datasets defined to the stream and copying that data to a single, sequential dataset.
Use the COPY STREAM command to accomplish this conversion and archival of a ring-stream CCAJRNL:
COPY STREAM ring-stream-name TO sequential-ddname JOURNAL
The stream definition must match exactly the original CCAJRNL definition with one exception: the name must be other than CCAJRNL. The following definitions, schematic, and COPY STREAM command illustrate this technique.
JCL and DEFINE commands required for the COPY STREAM command are:
//CTL DD SN=JRNL.CTL,SPACE=(TRK,(1,1)),... //JRNL1 DD DSN=CCAJRNL1,SPACE=(CYL,90),... //JRNL2 DD DSN=CCAJRNL2,SPACE=(CYL,90),... //JRNL3 DD DSN=CCAJRNL3,SPACE=(CYL,90),... //JRNLOUT DD DSN=CCAJRNL.ACHIVE,DISP=(,CATLG), // UNIT=CART,... //CCAIN DD * DEFINE STREAM JRNLIN WITH SCOPE=SYSTEM - RING=(JRNL1,JRNL2,JRNL3) - OFFLOAD=JRNLOFF - AUTOOFFLOAD=2 - CONTROL=CTL - CLOSE=NOAUTO DEFINE STREAM JRNLOFF WITH SCOPE=SYSTEM - CONCATENATE=(OFFL25,OFFL50,OFFL75,OFFL100) DEFINE DATASET OFFL25 WITH SCOPE=SYSTEM - DSN=OFFL25 VOLUME=TAP001 LABEL=SL - POSITION=1 UNIT=3480 DEFINE DATASET OFFL50 LIKE OFFL25 WITH - SCOPE=SYSTEM DSN=OFFL50 VOLUME=TAP002 DEFINE DATASET OFFL75 LIKE OFFL25 WITH - SCOPE=SYSTEM DSN=OFFL75 VOLUME=TAP003 DEFINE DATASET OFFL100 LIKE OFFL25 WITH - SCOPE=SYSTEM DSN=OFFL100 VOLUME=TAP004
Typical ring-stream CCAJRNL schematic is:
The COPY STREAM command is:
COPY STREAM JRNLIN TO JRNLOUT JOURNAL
Use the COPY STREAM command to archive a previously created ring-stream CCAJRNL before the stream is used again, either by a subsequent recovery run or by a subsequent Online run. In addition, this process reuses the original CCAJRNL ring-stream definition in subsequent runs, with no changes whatsoever. This is particularly important, because reusing the same tapes for the offload stream is really what makes the ring-stream definition completely reusable. Also, using the DEFINE DATASET command for each member in the offload stream (assuming tapes are being used) avoids dedicating a tape drive for the entire run. A tape drive is dynamically allocated when each offload operating occurs and is freed at the end of that offload. If the definitions are accomplished using JCL - DD statements, then a tape drive must be allocated for the entire run, for each DD.
As an aside, the COPY STREAM command can serve as a very useful utility for copying any sequential dataset from volume to volume or to make backups of sequential, non-Model 204 files. This is true under all operating systems: VSE, VM or OS/390, and MVS.
When running roll-forward recovery, the CCAJRNL dataset created in the failed run is referenced through the DDname - CCARF in the recovery run. If CCAJRNL was a ring-stream in the failed run, the definition for CCARF in the recovery run must match that definition exactly. This simply means using the CCAJRNL ring-stream definition from the failed run and renaming it to CCARF.
JCL and DEFINE commands required for CCARF are:
//CTL DD DSN=JRNL.CTL,SPACE=(TRK,(1,1)),... //JRNL1 DD DSN=CCAJRNL1,SPACE=(CYL,90),... //JRNL2 DD DSN=CCAJRNL2,SPACE=(CYL,90),... //JRNL3 DD DSN=CCAJRNL3,SPACE=(CYL,90),... //JRNLOUT DD DSN=CCAJRNL.ARCHIVE,DISP=(,CATLG), // SPACE=(CYL,990),... //CCAIN DD * DEFINE STREAM CCARF WITH SCOPE=SYSTEM - RING=(JRNL1,JRNL2,JRNL3) - OFFLOAD=JRNLOFF - AUTOOFFLOAD=2 - CONTROL=CTL - CLOSE=NOAUTO DEFINE STREAM JRNLOFF WITH SCOPE=SYSTEM - CONCATENATE=(OFFL25,OFFL50,OFFL75,OFFL100) DEFINE DATASET OFFL25 WITH SCOPE=SYSTEM - DSN=OFFL25 VOLUME=TAP001 LABEL=SL - POSITION=1 UNIT=3480 DEFINE DATASET OFFL50 LIKE OFFL25 WITH - SCOPE=SYSTEM DSN=OFFL50 VOLUME=TAP002 DEFINE DATASET OFFL75 LIKE OFFL25 WITH - SCOPE=SYSTEM DSN=OFFL75 VOLUME=TAP003 DEFINE DATASET OFFL100 LIKE OFFL25 WITH - SCOPE=SYSTEM DSN=OFFL100 VOLUME=TAP004
Although a new CCAJRNL dataset is required for the recovery run, it can be a small (CYL,(5,5)) non- ring, sequential dataset, because it receives very little data and has no use after the recovery step, even if that step fails and a secondary recovery is required.
Managing Data Connections
By David Stone and Ann Hulsing
Part 1 of this article (June 98) described the design of a typical ODBC-enabled Web application. This article, Part 2, discusses the management of data connections.
You can create a connection to System 1032 data at the Web application level, session level, or Web page level. Where you decide to manage a connection depends on how you plan to use that connection. Choosing the wrong level might require more resources than necessary, or might degrade performance, or both. This article discusses how connections function at each level, to help you choose which level to employ.
Data connections stored at the application level are also called shared connections, because all application users can share the same data connection. Although shared connections utilize the fewest resources, they have the following drawbacks:
Of the several methods to maintain per-user context for shared data connections, you can create the following
The most popular method of maintaining context information is to use a "cookie," which is a small amount of information sent by a Web server to a Web browser. A cookie is stored on the client system, and is retrieved only by the application that created it. A cookie can contain any required data and an expiration date. A cookie without an expiration date is deleted when the Web browser exits. Some cookies have expiration dates measured in years. These are often used by sites to remember who you are and what you were doing the last time you visited their sites.
Microsoft Internet Information Server (IIS) uses cookies to maintain Session Objects. IIS sends a cookie that expires at application timeout (20 minutes). This cookie is passed back to the Web server with each request and is updated as necessary.
Your application can create and use cookies to maintain context information as well. You can also create data connections at the application level, but store context-sensitive information about the connections at the session level. This is a best-of-both- worlds solution, because you do not have to code your application to manage the context information; you can use the built-in mechanisms of the Session Object to manage the information for you.
Data connections stored in the Session Object are private connections. Each Web user has one or more dedicated data connections. Because data connections are attached to an individual user, you can prompt the user for a user name and password to use when connecting to the data source. This is a close approximation to a client/server application.
A drawback to using session-level data connections is having enough resources, because each data connection requires a separate process on the System 1032 data server. Furthermore, Session Objects require a reasonably long timeout period, to give a user time to read the page and decide what to do next. IIS has a 20-minute timeout by default, so a data connection can persist for 20 minutes after the user finishes with the application.
Because of the timeout, it is possible that, at any particular time, many more connections to the data server might exist than actual Web users. While the processes serving up the data might be hibernating, they still require resources on the VMS system and still impact performance.
You can also create data connections at the individual page level. This involves creating the connection, retrieving the data, closing the connection, formatting the page, and presenting it to the Web browser. The advantages of page-level connections are:
The significant drawbacks to page-level connections are:
Note: Unless each request takes a long time to fill, the arrival time of the requests makes it unlikely that the maximum number is ever reached.
To make better use of per-page connections, use connection pooling, a feature of both IIS and Netscape Enterprise Server. When you employ connection pooling, the data connection is not necessarily closed when directed by the Web application. Instead it is placed into a pool of available data connections. If another connection is opened to the same data source using the same user name and password, then the existing connection is taken off the pool and given to the requester. This saves time and resources, and another connection is not opened. If no one requests the data source within a timeout period, then the connection is closed. If there are more requesters than connections in the pool, then a new connection is created.
Connection pooling is most efficient with data sources that have hardcoded user names and passwords. Potentially, all connections might be used from an available pool. In the case of the 100 users previously described, there would be far fewer actual connections, because many of the requests would be filled from the pool.
Limiting the number of data connections
To manage resources most effectively, develop applications that limit the number of data connections created at any one time. This is most easily accomplished by tracking the number of open connections in the Application Object. When the maximum number of connections is reached, you can:
The solution you choose is dependent on your application:
Part 3 of this article, to appear next month, will address frequently asked questions about database and Web application design.
Contact CCA Webmaster Copyright 2008
