Chapter 17 N-Way Sharing
N-way sharing based on the new Coupling Facility hardware is much easier than the old software-based block-level sharing. It is, however, still inherently complex, and not something to be entered into one wet Tuesday afternoon, because you are feeling bored. Careful planning and a full implementation of DBRC Share Control are prerequisites.
BMC Software will shortly be producing a manual called IMS DB Backup and Recovery With N-Way Sharing, which you should read.
General Observations
The major recommendations here are as follows: • Use an alternative if you can.
— IMS TM sites should use BMPs for batch access to online databases. — CICS/VS sites should use the DBCTL feature and look at BMPs. — Sites wishing to share across two CPUs should consider buying a
bigger CPU.
• Share between online systems if possible. This provides the following benefits:
— easier operations — easier restart — dynamic backout — easier DBRC interface
• Plan carefully, especially in how you are going to distribute the workload. Are you going to have separate systems or cloned systems? Think carefully about naming conventions.
Some Areas to Watch
• Test thoroughly.
• Make your operational procedures as simple and as consistent as you can. For example, always close the log, backout, and restart from last checkpoint in batch. Look at BMC Software’s BATCH CONTROL FACILITY and APPLICATION RESTART CONTROL products to help you in this area.
Some Areas to Watch
Here are a few suggestions/comments/problems I have heard about from customers looking at/implementing n-way sharing:
• RECON performance
The RECONs will be shared among all sharing subsystems. Each of these will be doingENQ/DEQ. It is vital that you tune your RECONs—see Chapter 2, “RECON Setup” for further details—so that they do not become a bottleneck. I expect IBM to offer further solutions to this problem in the future.
• WADS I/O
I am told that the WADS I/O increases when you are using the IRLM—I don’t really know why, but keep a watch on it. WADS are critical data sets, and must perform well.
• PROCOPT=GOT
There used to be a problem with PROCOPT=GOT flushing the complete buffer pool. This has been fixed via APAR No. PN63464.
“GO/GON/GOT all cause all buffers to be invalidated. Since only GOT does a retry and buffer invalidation is part of retry it is the only
PROCOPT that will impact other on-line users. With PROCOPT=GO the results are an ABENDU0849 and with PROCOPT=GON then a GG status is returned. Only GOT does the retry prior to returning the status GG. In IMS Version 5.1 and IRLM Version 2.1 with (CF) coupling facility structures using PROCOPT GOT causes the entire buffer pool to be flushed after the retry.
Code was added to module DFSDLR00 that will check to see if VSAM or OSAM coupling facility structure is being used. If the coupling facility structure is being used we do not invalidate the buffers.”
Recovery
BMC Software, Inc., Confidential and Proprietary Information
Chapter 17 N-Way Sharing 175 • Restarting BMPs on a different IMS
BMPs expect to be restarted on the same IMSID as they ran. BMC Software’s APPLICATION RESTART CONTROL handles this situation.
Recovery
Recovery in n-way sharing brings a whole new set of considerations:
• Finding a timestamp you can recover to is almost impossible (unless you have BMC Software’s RECOVERY MANAGER for IMS) as databases tend to be online to at least one subsystem all the time. BMC Software’s RECOVERY PLUS recovers to any point in time (PIT) feature solves this problem, and RECOVERY MANAGER for IMS will analyze logs for you to find appropriate timestamps and generate the JCL to recover. • Databases have to be taken off all sharing subsystems—this means an
update to your procedures to use theGLOBAL parameter. RECOVERY MANAGER for IMS automates this procedure, and also checks that the database(s) really is/are offline. (COMMAND COMPLETED only means that your syntax is correct, it does not mean that the command has executed!) • Logs have to be merged (=change accumulation) prior to recovery unless
you have RECOVERY PLUS.
• Any recovery scenario which involves a subset of a log is impossible with the standard IMS utilities. The recovery utility is capable of rejecting unnecessary log records, but the change accumulation always includes complete logs. This is described in APAR No. II09694, and here is one of the scenarios, which is not supported by the standard utilities:
Figure 58 Impossible Recovery with Standard Utilities
/DBR NOFEOV /STA /DBR NOFEOV /STA Image Copy Image Copy BMP1 BMP2 T1 T2 T3 T1 T2 T3 Batch job Batch job
Cannot recover to T2 - needs
Cannot recover to T2 - needs
log merge! (II09694)
Recovery
In this scenario, a/DBR NOFEOV has been performed on the online system, e.g. to establish a recovery point. The database is being updated by
online—BMP1—and a batch job prior to the/DBR. If you try to recover later on to the/DBR, you will find it is impossible, because you need to run change accumulation to merge the logs, but change accumulation includes the log records after the/STA.GENJCL.RECOV recognizes this and wants to select the logs instead, but it realizes they need merging so it abends with CC=12. The resolution to the APAR is to amend the IMS/ESA V5 Utilities Reference manual to say:
“A valid timestamp for a partial recovery is any point at which there are no allocations of the DBDS or area and there is not a merge of logs needed that cannot be resolved by running the accumulation utility.”
In other words—avoid the problem!
Fortunately, these problems do not occur with RECOVERY PLUS, as this product will sort/merge and portions of logs as required and reject any unnecessary log records.
Disaster recovery procedures have to be rewritten—see Chapter 18, “Offsite Considerations.”
BMC Software, Inc., Confidential and Proprietary Information
Chapter 18 Offsite Considerations 177