On 02/17/2015 03:58 AM, Jaco Kruger wrote: > The following components are shared between Development and Production > environments > The following components are not shared between Development and Production > environments
Jaco, it's not clear from your post if these passages describe the current=before-split actual state or the future=after-split desired state. As others have mentioned, if this is desired state you can't do (all of) that... or where you "sort of" can, it's not the commonly held meaning of sharing (more on that below, using zWLM as an example). Looking at the Merging doc is a good choice. To the degree the "why"s are described in there, look for cases where it's not merely "which systems" force the change, but which _work_. zWLM example (disclaimer: in a prior life, I was one of the lead perpetrators of goal mode, starting with WSM, but I've been out of that group for 10 years). Velocity goals are intimately dependent on the volume of work, number of CPUs, etc.; see my CMG95 paper for gory details. Regardless of goal type, if you have service classes that before-split run work from both production and development, splitting that workload (which you have no choice in, once you split the sysplex ... WLM doesn't cross sysplex boundaries, period) means that the subset of the workload characterization data each after-split WLM instance sees will be different. Potentially very different. Thus, policy goals will need to be adjusted. The degree of pain associated with this very much depends on the degree to which your before-split policy already separates production and devt work in to distinct service classes. If the before-split policy pretty much partitions work already, then it's only cross-service class effects coupled with "how much of the machine is available to any given class/period" that dominates. If they're all mashed together today, its hard to say much more than "things will change"; if you can partition their reporting before hand, that will help. But you should plan on watching prod Very Carefully after the split to see where goals need to be adjusted, in any case, unless you're system is fundamentally unconstrained. If your policy goals don't work as desired when it IS constrained, you have an upstream problem. Crazy example: if your prod work was all discretionary (below dev), and system CPU is 50%, you might never notice. If something starts looping and the CPU is now at 100%, you Will notice. The only "sort of" cross-sysplex WLM thing you can do is about managing the service definition, not what happens at run time. You can, if you want, use a single service definition "master copy" that you clone across all these (2, here) sysplexes; basically, edit the master whereever it is, export it to a file, move/copy the file (clone it), import it in the other sysplexes. Some people do that; you generally set up service classes and classification rules so that any given sysplex only runs work in "its" subset of the classes. Having extra classes that never receive work in a given sysplex causes minimal overhead. Other more complicated ("more shared") svdefs can be created, but I doubt anyone outside of WLM devt could actually manage it effectively... just too easy to make a mistake. If, in your dev/prod case, dev is "just" a mirror of prod used as a staging area ("same" work, running in same srvclasses, just with looser goals), then the master svdef makes good sense - you can keep the classification rules identical, and just have separate policies activated for dev vs prod. Be wary of creep though - often when dev starts out as a mirrored staging area for prod, over time it gets other work dumped in there never intended to hit prod, i.e. it drifts away from being a simple mirror/staging area. The further it drifts, the less a shared svdef makes sense. -- John Arwe IBM z/VM OpenStack and zKVM ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN