Nick, >My only advice, if such a thing works, is that you should consider >separate HLQ or EHLQ values for each log stream that has the same name >in both sysplexes. That would avoid thrashing when allocating offload >data sets, where the sysplexes would be competing for the same data >set names. > >I took a look at some old Logger APARs, and found OA12937, which >corrected a ENQ bug with the same log stream name used in multiple >sysplexes in the same GRS complex (one full sysplex, and numerous >monoplexes).
Maybe you misunderstood what I was saying: I am talking genuine parallel sysplex, that for no technical but purely pricing reasons (IBM pricing) has been artificially separated into two subplexes. These two subplexes share of course ISGLOCK and everything that is truly, non-reconfigurably sysplex scope. LOGR is a problem is such a setup, and no amount of naming conventions for offload datasets will help, when the logstream definition is truly sysplex scope (as in operlog). As there is only one logr policy, so there is no way to define two different HLQs for such a log stream. And RRS presents a different problem, as it is frighteningly easy to corrupt RRS logstreams necessitating RRS cold starts. And that is true even when certain parts of the sysplex use different RRS group names. The RRS ISPF application does not care where the logstream is supposed to 'reside', it connects to the 'wrong side' when instructed to do so by a human who doesn't know the implications). That presents a timing exposure, as the wrong half of the sysplex now has a connection to that logstream. If offload happens right then, it may happen on the wrong side. Offload will succeed (with a dataset in master catalog), but the log stream will be corrupted. Hence the requirement to have a pool of volumes for LOGR offload data sets that is accessible to both halves of the sysplex, when each half has it's own SMS configuration and is not supported by IBM to share a pool in two SMSs (even if it works). Hence my 'survey'. The only alternative supported is non- SMS, and to make it go to certain volumes (and not generally storage mounted volsers) is the IEFDB401 exit as described in 'setting up a sysplex' - that apparently nobody uses. Last year we've discussed this, and a suggestion was made to define in the LOGR policy via keyword *where* offload might occur. That would take care of our problem (and I don't think we are the only customer to have such an artificially separated sysplex - I'm apparently the only one paranoid enough not to risk a data integrity problem that RRS answers by cold-starting taking down the new-fangled applications such as Websphere.) Best regards, Barbara Nitz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
