If I went this route, the second LPAR would never (well, except in the situation where the main LPAR was down and things needed to happen) place a directory online. And putting a directory online would have to trigger the DIAG 3C in the other system somehow. Change of timestamp on a file or some such flag... Something that the slave LPAR could check, and wouldn't have to update to keep things straight.
The backup plan would be to have two directories (probably at the head of each LPAR's first paging volume), and have a way to pass the directory from one to the other, probably, again, having the second LPAR look at a common disk for the USER DIRECT and checking timestamps to tell it if an action is necessary. -- Robert P. Nix Mayo Foundation RO-CE-8-857 200 First Street SW 507-284-0844 Rochester, MN 55905 ----- "In theory, theory and practice are the same, but in practice, theory and practice are different." -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Monday, October 17, 2005 1:46 PM To: [email protected] Subject: Re: Two LPARs with one head? er I must be getting old but I would be hesitant about sharing the physical directory space amongst lpars. CP treats the directory space as virtual storage, mapping it with the same i/o algorithms as paging - goodness indeed. Mutiple writing to directory space outside of CSE/DIRMAINT makes me queasy. It's dumber and easier to use some sort of CMS service mechanism that does directory updates to multiple directories. Even loading directory from another system would make me uncomfortable. You could change the size of the virtual pages required for the directory, and the chances of a muffed pointer increase exponentially. David Rob van der Heij wrote: >On 10/17/05, Rich Greenberg <[EMAIL PROTECTED]> wrote: > > > >>Two systems with the same directory would probably work. I have never >>done it, but I have loaded a directory from another system. You need to >>run a small BAL program to issue a diagnose on the target system for it >>to become the active directory on the target system. I have the program >>somewhere but can't put my hands on it at the moment. >> >> > >This gets tricky. The SYSAFFIN is resolved at DIRECTXA time, so that >does not help you to make things different. When you share the same >object directory, you need to issue diag3C to invalidate the in-core >copy on all the systems except the one that ran DIRECTXA (since that >does the 3C after the object directory has been written). Failure to >do so may eventually produce UDR001 abends (in addition to confusion). > >Rob >-- >Rob van der Heij rvdheij @ gmail.com > > > > >
