Being the paranoid sort, I take it further. My second-level maintenance image has everything but page/spool on a single mod9. Before applying maintenance I make a backup of that volume. Once I'm satisfied with the outcome of a maintenance run I do a minidisk-by-minidisk compare of the changed system vs. the backup for all possibly involved userids. The catches deletions as well, and from the difference files I can generate execs to apply the same changes to my running images (includes the SES inventory files). -- Mike Harding
The IBM z/VM Operating System <[email protected]> wrote on 09/24/2010 10:16:26 AM: > From: Kris Buelens <[email protected]> > To: [email protected] > Date: 09/24/2010 10:16 AM > Subject: Re: Applying Maintenance - Best Practice > Sent by: The IBM z/VM Operating System <[email protected]> > > > 2010/9/23 Mike Walter <[email protected]> > > > BTW, after applying maintenance I consider it a good idea for each of the > component which were serviced, to use VMFSETUP so that their disks are > linked and accessed, then issue: FILELIST * * * (TODAY ISO > then browse around to see what was changed. That breeds even *more* > familiarity with VMSES/E and what it has done for you. That familiarity > can be handy when something goes bump in the dark. :-) > > Mike Walter > Hewitt Associates > > Yes, that's what I doo too.... but: > Such a FILELIST will not detect all changes: COPYFILE (OLDDATE is > used during install (and that's fine). So, I wrote a SERVICED EXEC > back in 1998 that consults the VMSES PARTCAT files to see what was > changed, "today" or since a date you pass. VMSES PARTCATs do tell > when a given CMS file has been changed/installed on a minidisk/SFS > dir. Available on request. > > One drawback: it doesn't work after installing an RSU: it will find > every file that is on the RSU as "being" changed, even if you > already had that file living there before the RSU. Not my fault, > but that's what is found in the VMSES PARTCATs. > > -- > Kris Buelens, > IBM Belgium, VM customer support
