NonStop/204 Extending 24*7 Capabilities - Part 2 By James Damon
In the February 2004 issue of CCAPRINT I outlined the new V5R1 feature, NonStop/204, that extends 24*7 capabilities by providing support for third-party backup utilities. The requirement for 24*7 operations is increasingly becoming a matter of necessity at many sites and this feature addresses one aspect of that requirement: the ability to take backups without bringing down the online, bumping users, closing files, or stopping subsystems. In that issue I also discussed the mechanics of implementation, beginning with the CHECKPOINT SET EXTENDED QUIESCE command through to submitting third-party backups of Model 204 files and confirming the success of those backups.
NonStop/204 is supported under all three operating systems: OS, VM and VSE. In this article I provide a concrete example, under OS, of the commands, JCL, and User Language programs that you could adapt to implement NonStop/204 in your environment.
Setting Up the Online If you want to enable NonStop/204, your Online must activate checkpoints by setting RCVOPT to include 1. Generally checkpoints and journals are enabled by setting RCVOPT to 9. You must set two additional parameters, which control NonStop/204: CPQZACTN and CPQZSECS. The Model 204 Command Reference Manual defines them as:
These parameters are usually set in CCAIN and are in effect after Model 204 initialization. The defaults provide a good place to start and are probably adequate for most sites assuming that someone monitors the process and ensures that the extended quiesce is ended after a resonable period of time.
When an extended quiesce starts, the CPQZSECS timer starts. When that timer expires, the action specified in CPQZACTN is taken. You may not know how long the backup job will take, so you estimate 15 minutes and set CPQZSECS to 900. If the backup job has not completed within 15 minutes, the action specified in CPQZACTN is taken. If CPQZACTN is not specified, the default is just to continue waiting another CPQZSECS.
Important Considerations Using Extended Quiesce However, if you are confident that the backup job will complete in 15 minutes, rather than maintaining the extended quiesce indefinitely, you might let the operator decide what to do and set CPQZACTN=X’20’. This results in a prompt to the operator asking whether to issue EOJ, ENDEQ or CONTINUE.
Recalling the Steps to Activate NonStop/204 In Part 1, I introduced the following steps that are involved in taking third-party backups using NonStop/204.
Taking Steps 1-5 in the Online
Supervising the process
You can take care of the first three Online steps in any sequence, but you must complete them before Step 4. The User Language program mentioned in Step 1 could look like the NONSTOP.WAIT procedure in Figure 1. In this case, it first issues BROADCAST URGENT to accomplish Step 2:
Steps 1 & 2: Waiting for Extended Quiesce and Notifying Users
Figure 1. The NONSTOP.WAIT procedure
PROCEDURE NONSTOP.WAITBROADCAST URGENT UPDATING WILL BE SUSPENDED/ IN 5 MINS FOR BACKUPS *SLEEP 300BEGIN AUDIT '-----> WAITING FOR CPQZ TO BE POSTED: $WAIT('CPQZ')' %X = $WAIT('CPQZ') /* WAIT FOR EXTENDED QUIESCE TO BEGIN */ END * /* IF HERE, CHECKPOINT WAS TAKEN AND */ * /* EXTENDED QUIESCE HAS BEGUN */ RESET HDRCTL 3 /* SUPPRESS SYSTEM HEADER AND BLANK */ USE $JOB /* LINE FOR $JOB */ DISPLAY PROC NONSTOP.BACKUP.JOB /* SUBMIT THIRD-PARTY BACKUP JOB */ * THIRD-PARTY BACKUP JOB HAS BEEN SUBMITTED.* WAIT UNTIL THAT JOB POSTS THE ‘QZSIG’ ECB * INDICATING THAT BACKUP JOB HAS COMPLETED BEGIN AUDIT '-----> WAITING ON "QZSIG" - POSTED WHEN BACKUP JOB COMPLETES' %X = $WAIT('QZSIG') /* WAIT HERE UNTIL BACKUP JOB COMPLETES*/* BACKUP JOB HAS COMPLETED - GOOD OR BAD? IF $ECBDGET('CPQZ') = 'GOOD BACKUP' THEN AUDIT '-----> "QZSIG" POSTED - NSTOP/204 BACKUP SUCCESSFUL' ELSE AUDIT '-----> "QZSIG" POSTED - NONSTOP/204 BACKUP UNSUCCESSFUL' END IFEND* /* END EXTENDED QUIESCE NO MATTER WHAT*/ CHECKPOINT END EXTENDED QUIESCE BROADCAST URGENT *** UPDATING HAS RESUMED *** END PROCEDURE
The NONSTOP.WAIT procedure waits at the %X = $WAIT(‘CPQZ’) statement until the system enters the extended quiesce. When that occurs, the CPQZ event control block is posted, the $WAIT is satisfied, and evaulation resumes. This type of procedure can be included at any time after the Online comes up or as part of Online initialization in User 0’s CCAIN stream.
Step 3: Preparing the Online To prepare the Online for extended quiesce, issue the following command:
> CHECKPOINT SET EXTENDED QUIESCE
If the command is successful, the following message is issued:
*** M204.2611: CHECKPOINT SET COMMAND SUCCESSFUL
Step 4: Taking a Checkpoint To establish a checkpoint, issue the following command:
> CHECKPOINT
Step 5. Confirming Extended Quiesce When this CHECKPOINT command succeeds, an extended quiesce is entered. Confirm that extended quiesce has begun with:
> CHKMSG CHECKPOINT COMPLETED ON 04.065 13:02:53.34 SYSTEM ENTERED EXTENDED QUIESCE AT: 04.065 13:02:53, ALL FILE UPDATING REMAINS SUSPENDED
The User Language program in Step 1 (NONSTOP.WAIT) now resumes evaluation at the %X = $WAIT(‘CPQZ’) statement. The program issues the USE $JOB command and submits the third-party backup job to the system. The User Language program then waits for notification from that job, via a BATCH2 job step, that it has completed. Figure 2 is what the third-party backup job, submitted by the NONSTOP.WAIT procedure in Figure 1 with > DISPLAY PROC NONSTOP.BACKUP.JOB, might look like:
PROCEDURE NONSTOP.BACKUP.JOB //CCABKUP JOB(CCATEST),CCATEST,MSGCLASS=A,MSGLEVEL=(1,1),REGION=0M //BACKUP EXEC PGM=ADRDSSU,REGION=8M //SYSPRINT DD SYSOUT=A //OUTDSN DD VOL=SER=BACK01,DISP=SHR,UNIT=3390 //SYSIN DD * COPY DATASET(INCLUDE(M204.DBPROD*.**)) - OUTDD (OUTDSN) - TOL(ENQF) REPLACE //*---------------------------------------------------------------- //* ITFAILED STEP IF BACKUP DID NOT END WITH CONDITION CODE 0 //* EVEN SO, POST ONLINE QZSIG WAITERS //*----------------------------------------------------------------- //ITFAILED EXEC PGM=BATCH2,PARM='CCACRIO,URCTYPE=B',COND=(4,GE,BACKUP) //STEPLIB DD DSN=your_site.V510.LOADLIB,DISP=SHR //CCAOUT DD SYSOUT=A //CCAIN DD * LOGIN BEGIN %X = $ECBDSET('CPQZ','BAD BACKUP') /* SET INFO FOR QZSIG WAITERS */ %X = $POST('QZSIG') /* WAKE UP ONLINE QZSIG WAITERS*/ %X = $JOBCODE(9) AUDIT '-----> QZSIG WAITER: POSTED WITH "BAD BACKUP"' AUDIT '-----> BATCH2 - BAD BACKUP, RETURN CODE: ' WITH $JOBCODE END //*---------------------------------------------------------------- //* ITWORKED STEP IF BACKUP DID COMPLETE WITH CONDITION CODE 0 //* POST ONLINE QZSIG WAITERS //*---------------------------------------------------------------- //ITWORKED EXEC PGM=BATCH2,PARM='CCACRIO,URCTYPE=B',COND=(4,LT,BACKUP) //STEPLIB DD DSN=your_site.V510.LOADLIB,DISP=SHR //CCAOUT DD SYSOUT=A //CCAIN DD * LOGIN BEGIN %X = $ECBDSET('CPQZ','GOOD BACKUP') /* SET INFO FOR QZSIG WAITERS */ %X = $POST('QZSIG') /* WAKE UP ONLINE QZSIG WAITERS*/ %X = $JOBCODE(1) AUDIT '-----> QZSIG WAITER: POSTED WITH "GOOD BACKUP"' AUDIT '-----> BATCH2 - GOOD BACKUP, RETURN CODE: ' WITH $JOBCODE END END PROCEDURE
Supervising the End of the Process After NONSTOP.BACKUP.JOB is submitted, backup processing runs and the Online is notified via one of the BATCH2 job steps--ITWORKED or ITFAILED--of its success or failure. Monitoring the activity of this batch job and monitoring Online activity can be accomplished through a number of Model 204 commands and system commands:
Regardless of which Step runs, the User Language program in Figure 2 resumes evaluation at the %X = $WAIT('QZSIG') statement as a result of the %X = $POST(‘QZSIG’) statement in the backup job. After the User Language program completes evaluation, the extended quiesce is terminated with the CHECKPOINT END E Q command and normal Online processing resumes.
The Steps required to take file backups under the control of NonStop/204 are fairly simple and straightforward. However, as with any backup scheme, this process needs to be thoroughly tested and understood prior to activating it in a production Online environment. Take particular care to ensure that file backups using third-party software completed successfully. In most cases this means that you should manually verify success or failure, even though successful completion is normally detected automatically through the use of conditional job step execution.
Handling SHARED DASD Enqueueing Entries When third-party backup utilities make copies of Model 204 files that are opened for read or update, the shared DASD enqueueing entries established in the FPL page for each file are also copied and become part of the backup file. If that backup copy is subsequently used to restore the file, those shared DASD enqueueing entries may result in spurious shared DASD enqueueing conflicts. If this occurs and the entries are known to be obsolete due to backups taken during extended quiesce, then they can be safely removed with the ENQCTL command. In most cases, Model 204 can remove these obsolete entries automatically.
In Summary NonStop/204 was developed in response to an increasing need at many Model 204 sites to provide 24*7 operations to their end-users. Global commerce and the Internet require continuous data availability for all manner of transactions from users in many different time zones. Prior to Nonstop/204, this data was unavailable during the time required to back up that data when using high-speed, third-party utilities. With Nonstop/204, these utilities can now be used to take Model 204 file backups without bumping users, closing files, or bringing down the Online and provide additional help to customers in their efforts to achieve 24*7 system availability.
System 1032
Synchronizing System 1032 Data with an SQL DBMS By Tym Stegner
It is a fact of life that organizations may need to maintain the same date in multiple databases. Recently a customer posed this question to me, “We need to share data between System 1032 and an SQL-based database. How is this best done to keep the data in both sources current in a timely fashion?”
Running in Parallel System 1032 and an SQL-based database can run in parallel for indefinitely when you take advantage of a variety of methods that can be used to synchronize data between multiple systems. This article reviews the mechanisms for data input and output from System 1032, and suggests methodologies for data sharing and replication between System 1032 and an SQL-based system.
System 1032 Data Flow Moving System 1032 data to and from an SQL database is accomplished in the following manner:
SQL Database Data Flow In SQL-based systems, the standard SQL INSERT and UPDATE commands are available for record-oriented data input and updates. To input records in bulk, examine the SQL-based system documentation for a command-line bulk loader utility used to move data from external files into the new catalogs.
Some SQL-based systems may not offer any data unload utilities. Instead there may be commands to transfer data and schemas between databases. However, the SQL language can often be used in conjunction with spooling utilities to select and format data and output it to a file. Third-party tools may also be available to help you unload data from your SQL-based system.
Lastly, check to see if the SQL-based DBMS has an API that might offer functionality similar to the System 1032 record-transfer APIs.
Handling Parallel Database Systems Given any set of two parallel System 1032 datasets and SQL-based tables, which hereafter I shall call both catalogs, the major logistical problem is determining which catalog is deemed the master copy, or whether there is a master copy. If one System 1032 dataset or SQL-based table is a master catalog, one method is to recreate the other catalog from the master on a periodic basis.
From System 1032 to an SQL-based Database You can use the System 1032 DUMP command to write the System 1032 data to an appropriate columnar or delimited format, create a control file for the SQL database bulk load utility, and add the System 1032 records in bulk to a new SQL-based catalog. From an SQL-based Database to System 1032 You use the SQL-based language utilities and programs to create a flat file that is then be used with PL1032 LOAD or APPEND command to create the new System 1032 catalog. When There Is No To-and-From Mechanism When a direct copy relationship does not exist between the two catalogs, the first consideration is to determine which records need to be replicated to the other catalog. This sort of consideration is driven by the design of the catalogs and the business needs of the organization and, thus, cannot be addressed in this article.
From an SQL-based Database to System 1032 You use the SQL-based language utilities and programs to create a flat file that is then be used with PL1032 LOAD or APPEND command to create the new System 1032 catalog.
When There Is No To-and-From Mechanism When a direct copy relationship does not exist between the two catalogs, the first consideration is to determine which records need to be replicated to the other catalog. This sort of consideration is driven by the design of the catalogs and the business needs of the organization and, thus, cannot be addressed in this article.
Updating Two Sets of Same Records
Once you have chosen the records to be added, deleted, or changed, you can take the time to consider how to go about doing the updates.
Updates from System 1032 to an SQL Database The System 1032 programming language can easily create either flat files for bulk loading, or generate the necessary SQL commands, such as INSERT, DELETE and UPDATE statements, to execute on the SQL-based catalog. Updates from an SQL Database to System 1032 Possibly the most efficient means is to use the TRANGEN utility that I described in CCAPRINT January 2004. The SQL-based updates might be extracted using the previously mentioned utilities. The resulting records are loaded into the System 1032 transaction dataset and posted using the TRANGEN-created dataset update program. Please note that this approach does require a separate program for each unique dataset you plan to update.
Making Updates Efficiently The customer, who asked the opening question, described a program they use to periodically collect updates from their SQL-based database to apply to the System 1032 catalogs. The output consists of a delimited text file containing directory, dataset name, update-type, and the update data. The customer was concerned about doing bulk updates when large numbers of records would be deleted or updated.
At that point, update activity becomes a straight update efficiency situation and the standard System 1032 efficiency rules apply.
1. Suppress keying during updates (key spooling). 2. Periodically rebuild the dataset to compact keys and records. 3. Make bulk updates when system activity is low. 4. Fine tune dataset keys and record structures.
In Summary Short of real data replication, parallel updates of catalogs for data synchronization result in the same sort of updates System 1032 is accustomed to doing anyway.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
