Minimizing checkpoint timeouts in a Model 204 Online
By Jim Damon
A checkpoint in a Model 204 Online is a critical, systemwide event. It marks a point in time when all files currently opened for update in that Model 204 system are at a known point of physical consistency. It also marks:
Frequent checkpoints are essential for ensuring rapid recovery in the event of a system failure.
A checkpoint can occur only when all update transactions have reached a point of commit. This means that files might be open for update, users might be running update applications, but all those applications have issued a COMMIT statement and have not yet executed another UPDATE statement following the COMMIT statement.
A checkpoint timeout occurs when an attempt to take a checkpoint fails, because Model 204 detects at least one in-flight transaction that has not yet issued a COMMIT statement.
Checkpoint timeouts are inefficient, because:
Repeated checkpoint timeouts generally indicate long-running update transactions, which:
The most common cause of checkpoint timeouts involves the following, generalized type of transaction, which fails to commit prior to a READ SCREEN statement. In the following example, an implicit COMMIT occurs at the END statement:
BEGIN FS1: FD criteria END FIND FR FS1 CHANGE... CHANGE... ... READ SCREEN X ... END
In the previous example, an update transaction begins with the first CHANGE statement and remains active across the READ SCREEN X statement. This transaction prevents checkpoints and causes checkpoint timeouts until the user reaches the END statement, is timed out, or is bumped.
Effective applications ensure that all update transactions are committed prior to the next interaction with the user (READ SCREEN statement, $READ function, and so on). For example:
BEGIN FS1: FD criteria END FIND FR FS1 CHANGE... CHANGE... COMMIT READ SCREEN X ... END
You can evaluate applications for potential checkpoint timeouts using the MONITOR CHKP USERLIST command, shown in Figure 1. The columns you need to examine are highlighted in bold in the figure.
>MONITOR CHKP USERLIST 98.028 JAN 28 18.41.46 PAGE 10 *** LATEST SUCCESSFUL CHECKPOINT COMPLETED AT: 98.028 18:30:10.32 *** 2 CHECKPOINTS HAVE SINCE TIMED OUT *** 6431 RECORDS CURRENTLY IN CHKPOINT STREAM *** 1 CHECKPOINTS CURRENTLY IN CHKPOINT STREAM *** 5 USERS CURRENTLY HAVE CHECKPOINTS INHIBITED
All the users in the Figure 1 example are inhibiting checkpoints. However, UID73 and UID27 are inhibiting checkpoints across a user interaction, probably a READ SCREEN:
After issuing the MONITOR CHKP USERLIST command, as in Figure 1, you can enter a subsequent MONITOR (8,21) SL command to identify which APSY, PROCFILE, and PROC each user is running so that you can make the appropriate code changes to minimize checkpoint timeouts.
In addition to writing update applications that issue frequent COMMIT statements and always issue COMMIT statements prior to any user interaction (such as a READ SCREEN statement), set the following CCAIN parameters to the values indicated:
Monitor the status of checkpoints on a regular basis to ensure that new applications do not increase the frequency of checkpoint timeouts. In addition, test all recovery jobs on a regular basis to guarantee that roll-back/roll-forward recovery runs correctly and rapidly when required.
See the Model 204 System Manager's Guide and the Model 204 Command Reference Manual for more information on checkpoints, checkpoint timeouts, and the MONITOR command.
System 1032/OpenVMS migration issues
by Nancy Diettrich
System 1032 is closely integrated with the Digital operating system, OpenVMS. With the arrival of OpenVMS Version 7.1, the extensive changes made to the operating system have implications for System 1032.
Nearly all versions of System 1032 run on OpenVMS Version 5.5-2. Also, many sites run older versions of System 1032 (for example, Version 9.4) with OpenVMS Versions 6.1 and 6.2 on both VAX and Alpha platforms. CCA knows of no issues with those configurations.
When your site decides to upgrade to OpenVMS Version 7.1, however, take note of the following guidelines.
For VAX platforms
If you plan to run OpenVMS Version 7.1 on a VAX platform:
For Alpha platforms
If you plan to run OpenVMS Version 7.1 on an Alpha platform:
Note: You must download the AXP_SIMSHR.EXE file as type Image or Binary. CCA recommends that you download directly to your OpenVMS server, bypassing the PC.
Upgrading back-to-back
If you upgrade both OpenVMS and System 1032, install in the following order:
If your site has already installed a compatible version of System 1032, only steps 1 and 3 are necessary.
If you have any questions or problems installing System 1032, contact CCA Customer Support at 508-270-6666 ext. 700 from 9:00 a.m. to 6:00 p.m. Eastern time.
The System 1032 community at CCA is intently watching the negotiations between Digital Equipment Corporation and Compaq Computer. CCA is especially watchful of the publicity Digital has given the OpenVMS operating system. You can visit the following Web sites for news from the participants:
For the views and comments of others in the industry you can visit:
Deja News provides a searchable interface to discussion forums on the World Wide Web, including USENET discussion groups. Try searching for OpenVMS, Digital, and/or Compaq.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
