Re: BRMS PTF Interpretation

We have 3 LPARS. One of them 'only' controls our backup process. We can update this LPAR and let the PTFs simmer for a while. Although there's not a lot going on in this LPAR, it gives us a sense of confidence if nothing obvious falls over.

Next, we update our test system one week, and production system the next. The only time we let the new PTFs simmer for a longer time is when we put on a cumulative patch or an OS upgrade.

As far as the BRMS updates go, unless the instructions say otherwise, it probably doesn't make a lot of difference if you're only a week or two out of sync, especially if you were in sync to begin with.

--Paul E Musselman



At 7:13 PM -0500 5/16/19, Kevin Monceaux wrote:

Midrange Fans,

I think I'm in the home stretch preparing to start getting our LPARs up to
date on PTFs. I red through more cover letters than one can shake a stick
at today.

The cover letter for SI68855 includes this:

DESCRIPTION OF PROBLEM FIXED FOR APAR SE70391 :
-----------------------------------------------
It is important to keep all systems in a BRMS network at the
same level of BRMS PTFs.
Fixes included in this PTF may reference enhancements. More
information on these enhancements can be found on the BRMS web
page: ....

It goes on to list various fixes in the PTF.

It looks like it's describing the importance of keeping all systems in a
BRMS network at the same level of BRMS PTFs as a problem. And that could be
a problem for some. Is that the description of a problem, or a warning?
I'd love to keep all of the BRMS PTFs on my LPARs at the same level, but I
also need to be able to apply PTFs on my development LPAR and run with them
there for a while to make sure no issues are encountered before applying
them to my other LPARs.




--

Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.