Published:
December 11 2008, 05:15 PM
|
2 Comment(s)
by
Reg Harbeck
G’day Mainframers,
Don't you just love xmas? Well I will if my better half finds me a more interesting present than 15 pairs of Holeproof socks, 10 pairs of Reg Grundies and a copy of the second-hand book 'The Stray Shopping Carts of North America: A Guide to Field Identification.' Who ever thought 'shopping trolley spotting' could be so much fun...especially when you’re 8853.59 miles away!? Having said that, I do have a nice early xmas present that is actually worth the read..thanks to a great question from Graham in Sydney. So strap yourself in…
Being a guy for whom the verbal discussion has sometimes taken a life of its own, somewhere today I was not only going to create, but also automate – a ‘DB2 Cloning’ process. Firstly, I would have to escape the blather in the back office of that ASP (unnamed to protect the guilty), surely enough to make Alexander Graham Bell cry and my ears throb from the cacophony of abuse the phone was taking. The monologue of a heated twenty minute argument of a self proclaimed systems expert with their spouse was the norm. Why focus on the customers needs when you could publicly air your own issues. To escape the barrage of verbal abuse - I departed to the sanctuary of the customer site - safe from others who feared this domain of business logic and cost justification.
Cloning a DB2 Subsystem – how difficult could it be? Understanding the application specific requirements and incorporate these into the methodology. Take this method, automate it so that a simple change request could initiate this process and complete in a timely manner with little if any customer interaction.
Starting with the high-level steps required to enable ‘Cloning of DB2 Subsystems’
1. Back-up the SOURCE DB2 Subsystem in it’s entirety whilst still up during a period of low data change activity
a. Suspend update activity with the LOG SUSPEND command
b. Dump in parallel the DB2 Catalog (DSNDB06), Directory (DSNDB01), Ancillary (DSNDBnn), LOGS and BSDS. Plus all User Data (page-sets)
c. Resume update activity with the LOG RESUME command
2. Stop and Delete TARGET DB2 Subsystem and Datasets
3. Restore the TARGET with datasets from SOURCE Backup using RENAME option
4. Update the BSDS (DSNJU003 – run DSNJU004 first and a clist to format commands below)
a. NEWCAT, DELETE (dsname=LOGS), NEWLOG (copy, start and end) and DDF
5. Start TARGET DB2 with alternate ZPARM (to defer open of User data) parameter MAINT
a. DSN6SPRM DEFER
6. Delete and Define new DSNDB07 Database
a. Stop DSNDB07, AMS DEL/DEF DSNDB07, Drop and Create DSNDB07
7. Alter Table/Index{space} to new Stogroup and VCAT (matching TARGET standards)
a. Create NEW Stogroup (TARGET VCAT), STOP Pagesets, Alter Page-sets, Start Page-sets {this requires SYSADM auth}
8. Alter Procedure WLM_ENVIRONMENT (if names are subsystem specific)
9. Re-Start TARGET DB2 Subsystem with standard ZPARM
10. Customer specific requirements
Just how easy was that? Luckily I had implemented this since DB2 for OS/390 v4 across the globe (and currently up to DB2 UDB for z/OS v8). Most of the steps that require manual intervention are run in batch with REXX / Clists and my own modified version of DSNTEP2 (removes the formatting of output and allows commands to be executed with set commands within the input stream). This allows a complete batch implementation of the afore mentioned process.The time savings are unbelievable and if your local recovery strategy already employs a Backup of the entire DB2 Subsystem (excluding archives) it would be a simple extension of existing infrastructure.
There are two considerations before jumping head long into this scenario:
1. DB2 Security – keep it out of the DB2 subsystem!
• If internal (using grants – this can be overcome with a script or product)• Preference is to use External security (access control authorization DSNX@XAC or product based) so that it has NO impact with the Clone
2. HIGHLY SENSITIVE DATA - User Data
• Many sites have internal processes and products to scramble data that is of a sensitive nature. This would require the process to run after the CLONE. • Preference to Field Procedures that are applied to the Clone TARGET – this would save an enormous amount of time and only be initiated when data was accessed. Down side is that it may effect performance and capacity testing and not reflect a true image of production
The last step is AUTOMATION – this is NOT specific to any product - and could be integrated into either a ‘Scheduling Package’ or an ‘Automated Operator’ linked to Change Management. It includes only three distinct processes –
Resource Monitoring
TARGET DB2 is a ResourceTARGET DB2 has a number of Status conditionsAvailableDown (clean or failed)Clone in progressUnknown OTHER resources are dependent on TARGET DB2 ResourcesAction Rules are based on Status conditionNotification is based on Status condition
Event management
Procedures are initiated with the Status of a DB2 resource changesScripts can start batch processesBatch Processes have dependencies with other batch ProcessesParallel or single stream rules are based on Batch ProcessesNotification of error or Unknown Status
Command and Response
DB2 commands are issued and responses interpretedStop DB2 (and place in Clone Status)Start DB2 with alternate parameter in Maintenance modeStop DB2 (and place in Down status)Start DB2 (and place in Available status)Errors – unknown and pass to Event for Notification
Finally our Clone of DB2 Subsystem is complete and now it is time to head back to the destruction site. If you require any of the JCL, Clists or SQL – I please send an email to BRUCE. Bruce takes NO responsibility in part of full for any loss of data or expense incurred as a direct or indirect result of the implementation of the afore mentioned process. Happy Hunting and Holidays. Cheers now, Bruce A. Claus
By: Reg Harbeck
Reg Harbeck is CA's Product Management Director for Mainframe Strategy. In the more than two decades since he received his Bachelor's Degree in Computer Science he has worked with operating systems, networks, security and applications on mainframes, UNIX, Linux, Windows and other platforms. Reg...
Read More..