RATS ... again I got interrupted from finishing that thought.
> In the VM/CMS world, everything always lives on its own disk. You
> want the C compiler? Link its disk and access it. (Where in Linux
> speak that would be equiv to hot-plugging the media and mounting it.
> Please forgive me since most of you are well aware of the
> correlation.) This is all the more elegant because you can, in the
> VM/CMS model, have multiple installations, multiple releases
> concurrently. You can upgrade without interrupting active work. The
> compiler is owned by a virtual machine called (perhaps) IBMC.
So ... to round that out ...
You might have the prior release owned by virtual machine IBMC
on his 110 disk and the new release on his 120 disk. In CMS,
the way we do things is:
cp link ibmc 110 999 rr
access 999 q
to use the old release of the C compiler, or
cp link ibmc 120 aaa rr
access aaa q
to use the new release. While there are several addresses
used by CMS virtual machines which are kind of known ahead of time
(I mentioned the 19x range), there are also plenty of open slots.
Pick an open slot, link the required disk there, then 'access'.
In CMS, you also have to find a free mode letter, kind of like
finding a mount point in Linux. I used the same mode letter in both
examples above, since in CMS you really cannot use both compilers
at the same time. The question from Agblad Tore made me think about
sharing specific packages in Linux. So stretching the story a little,
maybe we could (in Linux):
hcp link ibmc 112 999 rr
chccwdev -e 999
mkdir -p -m 555 /opt/ibm/c11
mount /dev/disk/by-path/ccw-0.0.0999 /opt/ibm/c11
or
hcp link ibmc 122 aaa rr
chccwdev -e aaa
mkdir -p -m 555 /opt/ibm/c12
mount /dev/disk/by-path/ccw-0.0.0aaa /opt/ibm/c12
In this case, I used a different mount point for each release
of the compiler, because with Linux being a multi-user system,
a Linux virtual machine might use both releases simultaneously.
This is just a crude example. Does it make sense?
The example owning virtual machine, IBMC, has at least four disks
110 for V1.1 of XL C/C++ for z/VM
112 for some mythical equivalent for Linux at rev 1.1
120 for V1.2 of XL C/C++ for z/VM
122 for some mythical equivalent for Linux at rev 1.2
These addresses truly are arbitrary as far as VM is concerned.
User IBMC never logs on. The "client" virtual machines can link
these disks at any address they like.
There is an XL C/C++ for Linux but I have no idea what its
version/release/mod numbers are. (And it might only support the
Power architecture. Dunno! Outside the scope of this thread.)
-- R; <><
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
