Chapter 16 Testing and Migration
This chapter considers the implications of moving databases from test to production, and how to handle multiple sets of RECONs. It also considers some of the implications of moving from CICS-DL/1 to DBCTL.
Database Names
The rules of DBRC require the database names in RECON be unique. Also, the combination of DBDNAME+DDNAME must be unique. This means you cannot have test and production databases registered in the same RECONs if they have the same names.
This has caused major problems at many CICS-DL/1 sites, where they currently run cloned systems—one CICS-DL/1 region for each application, with the DBD names and ddnames the same, but using different data set names. When they try to combine this all into one DBCTL system, the problem is that the DBD names have to be unique in the IMSGEN
(DATABASE macros). If you want to run without DBRC registration, then you could write an exit to point at different data sets depending on keys say, but if you want to gain the benefits of DBRC, then I don’t see an alternative to renaming things.
Most people run with two sets of RECONs—one for test and one for
production. They use RACF or something similar to ensure people access the correct set of RECONs.
Dynamic Allocation
Test and Production
If you do not haveFORCER specified, you get a warning message (database not registered) when running with the wrong database data sets (i.e., do not match what you have registered in RECON). The job will continue to run. You must use other methods, such as RACF, to ensure that you do not use test databases against the production RECONs and vice versa—see my warning in “FORCER” on page 30.
If you haveFORCER, the job will abend with an authorization failure if the data set name does not match.
Dynamic Allocation
DBRC uses dynamic allocation for the RECONs if no DD statements are present. If a RECON1 DD statement is present, JCL allocation is used. So to use different sets of RECONs, either generate different sets of dynamic allocate modules and STEPLIB to the appropriate ones or use JCL overrides for test.
When I am debugging RECON problems (oh, what a thrill!), I typically take a copy of the RECONs as a first step. I then use DD statements to point at my copy RECONs and play around with these until I have cracked the problem (nothing worse than entering the wrong command against the production RECONs and then spending an hour undoing it). When I have the job stream all correct, I then asterisk out the DD statements and run against the
production RECONs.
Note: One thing that annoyed me intensely when I first started playing with DBRC was that if I entered a string of commands and one of them was wrong, DBRC would stop rather than skipping over it and doing the following ones. Actually, this is very sensible, as it enables you to build things up slowly and in the correct order and not make a total and utter mess of things.
A mixture of dynamic and JCL allocation is not recommended. Imagine the following scenario:
1. Job 1 uses dynamic allocation for all three RECONs.
2. Job 2 has DD statements for RECON1 and RECON2 (forgotten or unaware of RECON3, or copied some test JCL—test regions often run with no SPARE).
Migration
BMC Software, Inc., Confidential and Proprietary Information
Chapter 16 Testing and Migration 171 3. Job 1 gets error on RECON1, triggers copy to spare, and is now running
on RECON2 and RECON3.
4. Job 2 accesses RECON1 and RECON2, finds they don’t match, and stops using RECON1.
5. Job 1 accesses RECON2 and RECON3, finds they don’t match, and stops using RECON3.
So you are rapidly reduced to one RECON. Hopefully, you have coded the parameterNONEWon your RECONs, and no more jobs will start to add to the confusion. For instructions on how to get back to two RECONS and a spare, see “Recovery Following a Discarded RECON” on page 26.
Migration
There is no facility in RECON to merge information from one set of RECONs into another. So when moving databases from test to production, the best thing is to register them, and then image copy them to give DBRC a starting point.
DBCTL
As from IMS V3, the CICS/VS user can access DL/1 databases using the DBCTL address space. Use of this facility means that DL/1 logging, archiving, etc., is performed by DBCTL. The CICS journal only contains CICS information. It does not include any DL/1 database information. See Appendix B, “The Real Rules of Archive” for information on how archive works.
DBCTL users are normally new to IMS and have to suffer some of the things we old IMS lags went through some years ago. The IMS manuals are a good source of information—DBCTL simply assumes that you understand things like IMS logs. Some of the more common problems I come across are:
DBCTL
1. You have to learn about OLDS, SLDS, RLDS, and WADS. Do not forget to set up WADS—they are vital to your performance. Their size in tracks is (1+(OLDSBLKSIZE/2)) x number of OLDS buffers. Put them on high-performance non-volatile storage.
2. You do not have to install a separate DBCTL if you already have an IMS TM control region. The IMS control region contains DBCTL—the manuals hint at this and then tell you no more. Trust me, I know many customers running IMS TM as their “DBCTL server.”
3. You have to set up your archiving scheme (i.e., decide on how many SLDS and RLDS you will produce at archive time) and rewrite your recovery procedures to use these as input.
4. You can avoid sharing by using BMPs—recommended—but don’t forget checkpoint/restart—BMC Software’s APPLICATION RESTART
CONTROL can help you implement and control this much more quickly. 5. You can use Fast Path (still the best performing and most available
DBMS).
6. You do not have Resource Definition Online—you have to use IMS’s rather nasty Online Change feature with all its active, inactive and staging libraries. Alternatively, you could do yourself a favor and have a look at BMC Software’s DELTA IMS® for DBCTL product, which allows you to make dynamic changes.
BMC Software, Inc., Confidential and Proprietary Information
Chapter 17 N-Way Sharing 173