I am going to try to explain how we did this at my last job.
We had 21 z/vm systems all were defined to CSE .. 
Each system had it's own SYSRS volume containing directory and spool space.
Each system had two additional volumes dedicated to paging, tdisk, and more 
spool space.
We did not use Cross system spool or Cross system message (the limit is only 4 
anyway).

All volumes containing minidisks were defined with XLINK statements in the 
system config file.

We had a single source directory for all systems with SYSAFFIN statements where 
required.
We used Dirmaint to synchronize the directory.

If your installation is small enough that Dirmaint is overkill there are other 
options.
A simple solution is to have the ID that issues DIRECTXA on VM-a do a REXEC to 
VM-b to also do a DIRECTXA each pointing to the same source file.

Once CSE is setup and you have your XLINK statements in place you will be able 
to logon the same VM USERID in either LPAR at the same time. The first one to 
logon will be the one that gets R/W access to the minidisks (DO NOT define them 
with MW) the other will not get write access.

You can easily use your 3270 emulator to either LPAR you don't need PVM you do 
need separate IP address for tcpip.

Just a note.. If a disaster should hit and you need to update the directory on 
a dead VM you can do it from the living one by attaching the dead systems 
sysres (probably as 123 unless you changed it) and a set cupid to match the 
dead systems cupid then just run your DIRECTXA and IPL the dead system.

I hope this helps.


  

-----Original Message-----
From: David Kreuter [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 17, 2005 3:20 PM
To: [email protected]
Subject: Re: Two LPARs with one head?

even with raid technology I wouldn't mix directory and page space on the 
same volume. A directory reference of any sort I think would kill the 
paging never-ending-channel program; and vice versa.
Nix, Robert P. wrote:

>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. 
>
>
>  
>

Reply via email to