On Thu, 25 Aug 2005 14:25:35 -0700, George Kozakos <[EMAIL PROTECTED]> wrote:
>We are looking at merging 2 SYSPLEXes which are 20 KMs apart. Our first >step is to create a Bronze-PLEX as described in SG26-6818 Merging >Systems into a SYSPLEX. The driver is to achieve single SYSPLEX >pricing. >We are also looking at ISGNQXIT as it can modify resource names which >may be useful in specific cases. Anybody used that? Another idea is to >capture the enqueue workload from SYSPLEX A and redrive it on SYSPLEX >B. Anyone done this? George; I'm using the GRS exit across sysplexes you mentioned but keep in mind that it forces a HW reserve at DASD level so the integrity is preserve. The exit does have some limitations, one of them is that it does not guarantee integrity at member level (for a pds/e). For PDSE you can actually corrupt the dataset. But what surprise me from your post is that you want to merge the sysplexes to save mony because the PSLC pricing model. It is important that you don't forget that sysplex is about sharing. Having a parallel sysplex for minimun sharing is, IMHO, a contradiction. You have exploiters such as OPERLOG, WLM, and many plexes (like SMSPLEX, OAMPLEX, among other) that could compromise the final intention of your approach. I don't know how much you will save, but I'm under the impression that the cost of maintaining a configuration merged in the way you mentioned can be more expensive than staying in your actual configuration (in terms of the people effort) Also, there is some considerations for the Couple Datasets. You mention of having two copies. How?. Using DASD replication?. There are some limitations for DASD replication when there are Sysplex datasets involved. Despiste all these "warning" you can still can achieve what you want, only that you will find dificulties for tasks such as: performance tuning, WLM (that by the way, WLMPLEX must be equal to the SYSPLEX, i.e. if you have three systems, WLM must see the three sysplexes). Ah, I'm handling two parallel sysplexes (separate DASD, separate CFs, same CPCs) and I have to plan for merging them. But the way I'm doing is first at all, select a unique product for each major component: Security, Scheduling, Content Manager, Tape manager, Storage Manager, Automation, etc, etc). Nowadays all of these are different software: Top Secret vs Security Server, Control-M/R vs Tivoli WLS, Control-D vs MOBIUS, Control-T vs DFSMSrmm, CA-DISK vs DFSMSdss and DFSMShs and Control-O vs System Automation. We have decided that is better to migrate to an unified software configuration that maintain different products with the same people. Needles to say, having different products can lead to delays in implementing new z/OS versions, especially for the ISV products. We all here want a simplified operations sysplex towards the true Parallel Sysplex escence: Continuos Operations. But, you might have a different goal. Regards, Giovanni ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
