Paul--I take a little more cautious approach to maintenance than you
do. I **DO NOT-EVER* *put RSU or any kind of maintenance on a
production system or on a "test" system, that being defined as not
really a production system but one that users can get access to in order
to test new or changed application code. I put maintenance and build
new releases on a 2nd level VM system that no one but sysprogs can get
to. When an RSU changes something, after seeing that the change will
even run on the 2nd level, I'll copy to effected mdisks to the 1st level
with a different mdisk address. For RACF, for example, I'd copy to 2nd
level 305 and probably the 490 disks to the 1st level as 1305 and 1490.
Then at the time of the change, I just readdress the old 305 and 490
disks to something else, 2305 and 2490 perhaps, readdress 1305 and 1490
to 305 and 490 and at some quiet time of the day, restart RACF. What
disks you need to play with depends on the component, but, in general,
that's what I do. I always leave comments in the directory entry so I
know the current status of the disks. The mdisk passwords are very
useful for that kind of thing. READ WRITE 53VM0801 is good.
Everyone will have their own ideas as to how to do maintenance, but this
is an approach that has worked for me or at least that I have developed
and followed over the course of 30 years of VM maintenance.
Jim
Feller, Paul wrote:
We have been a z/VM shop for about three years and have applied RSU
maintenance during those three years. We currently are running z/VM 5.3
and are working on applying RSU0801. This is the first time we have
done an RSU with DIRMAINT and RACF in the picture. We are wondering how
other people handle doing maintenance with DIRMAINT and RACF.
Here is what we did.
1) To get the PUT2PROD for DIRMAINT maintenance to work we shutdown the
DIRMAINT guest and all of the DIRSAT guest. (we run three lpars that
share the user directory)
2) To get the PUT2PROD for RACF maintenance to work we shutdown the
effected lpar. The other two lpars stayed up. IPLed the effected lpar
with NOAUTOLOG and XAUTOLOG RACMAINT. We then completed the PUT2PROD.
We then did a SHUTDOWN REIPL of the lpar and came back up normal.
Paul Feller=20
AIT Mainframe Technical Support
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
