Berry,
what about another idea of maintaining zVM. I have no user data on the
zvm dasds, there is only the software and some config staff, which does
normally not change. So I can copy the zvm system (res spl pag) to other
previously reserved dasds and start zVM from there in second level. Then
I do all the service maintenance and after all tests I change the system
config parameter "offline_at_ipl" on the new dasd's Maint CF1 to the old
zvm dasds (RES, SPL, PAG). When it's done and there is time to reipl. I
backup the RDR/PRT/PUN files if necessary from the old system, restart
from the new vmres and restore the spool files. I don't have to worry
about selecting files to copy and in case of errors. I can switch back
to the old vmres.
Of course the major prereq is that you don't have any user data on the
zvmres. The same thing I do in principle with zVSE DOSRES and SYSWK1
too. This way I have always a fall back when there are problems after
system changes.
kind regards
Franz Josef Pohlen
Berry van Sleeuwen schrieb:
Hello listers,
We are upgrading the zVM 5.4 to RSU 0903. I am looking at enrolling this
upgrade from the install system to our production VM's. Our install VM
contains the full VMSES environment, our production VM's only contain the
productsdisks that are required for running VM. For instance, only MAINT 193
is available in production, the MAINT 493 is only in the install VM.
Basically we would like to transfer only those files that have been changed
by the RSU and/or PTF's. I compare the LISTFILE (ISO for all minidisks from
the old and new install VM to find files that have been changed. Either a
change in date/time, records or blocksize will be noticed, as well as new
files. Next I only select the minidisks that are in the production VM's and
the files on that minidisks that have been changed.
Obviously, some disks can't be tranferred this way, the MAINT 190 is
transferred using DDR so that we transfer the entire disk instead of only
the S-disk.
Now I do see files that have been changed but do not have the filedate set
to the date of applying the RSU. That makes me wonder, could there be a file
that is changed but is not found this way? For instance, a file where a byte
has been changed but that is not reflected in a change in filesizes or
timestamp?
Also, would copying files have impact on other functions? When the 190 or
19E is changed CMS has to be rebuild. Could the same be true for segments
such as HELPSEG or CMSFILES (to name a few)? Segments are copied/transferred
using the DCSSBKUP but are these still valid when individual CMS members are
copied too?
TIA,
Berry.
