Indeed, IPLER (or alike) is part of the solution to keep the previous copy
of MAINT 190 etc.  With each level of CMS, a set of saved segments goes
along.  In my IPLER package, I explain how we use a naming convention and
associate a set of saved segments for CMS with the 190 disk linked by the
users.

2007/11/15, George Haddad <[EMAIL PROTECTED]>:
>
> Or better still, learn to use an IPLer for loading different CMS levels.
>
> Kris Buelens wrote:
> > VMFREM of the RSU PTF number wouldn't work if you ask me.  The RSU PTF
> > number is just an easy way to order the RSU by using the service
> ordering
> > procedures.
> > And, PUT2PROD, yes, that's the one I don't like: it makes that e.g.
> MAINT
> > 190 and 490 become identical, there goes your fallback.   I change the
> > directory entry of MAINT (and friends) to make the 490 become 190, swap
> 193
> > with 493 etc.
> >
> > 2007/11/14, Hooker, Don <[EMAIL PROTECTED]>:
> >
> >> I'm applying an RSU to our z/VM 5.2 system.  I've already run the
> >> SERVICE exec against the envelope files and plan to do the PUT2PROD
> just
> >> before a scheduled weekend IPL.
> >>
> >> I've been asked how to back it out if there are problems.  Rather than
> >> volume and/or minidisk restores, can I just use VMFREM to back out the
> >> service?
> >>
> >> Would I use: VMFREM PPF SERVP2P <compname> PTF UM97520 (which was the
> >> PTF number for the RSU) against every affected component?  (The
> >> components listed in the SERVICE $PRODS file).  Then IPL?
> >>
> >> Would that work?  Is there another/better way?
> >>
> >> Thanks in advance.
> >> Don
> >>
> >>
> >
> >
> >
> >
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to