RE: Perm. apply PTF's thoughts

My strategy has been s follows:

1. I read the weekly PTF newsletter to see if there's anything new that
will impact my company.  Only load individual PTFs, including HIPERs, if
I'm encountering a specific problem and need a PTF to fix it.  The
exception is that I will try to review & apply security PTFs
individually.  This is the 'if it ain't broke, don't fix it' strategy.
Hey, a HIPER may be a HIPER but I'm still not going to load it unless it
addresses a problem I already have or feel I might encounter. 

2. CUMs & group PTFs .. I do like to stay relatively current, but not
bleeding edge.  When a new CUM is announced, I promptly ignore it for a
couple of months.  Then I'll permanently apply the existing PTFs before
loading the new CUM on our dev system.  Load the new PTFs on our
development system.  Do any specific testing if there's a problem I want
fixed or a new feature I might use.  Otherwise let it sit in normal
usage on the dev box for at least a month.  Then permanently apply the
existing PTFs on the production system.  And only then will I
temporarily apply the current CUM/groups to the prod box.

3. New OS releases are handled much the same way CUMs are.  I do issue a
permanent apply of existing PTFs before doing the OS upgrade to clean
things up.  I just do it about a week ahead of time so it doesn't impact
the timing of the upgrade itself.
  
I'm actually loading V5R1 CUM3007 on our prod box today.  It's been
running w/o problems on our dev box since late Feb.

Oh, regarding saves: The prod box gets a GO SAVE/21 weekly so I always
have a current SAVSYS to back out/recover from.  The dev box only has
*ALLUSER type data saved regularly so I specifically do a 21 or just a
SAVSYS before any major loading of PTFs.

One nice thing about this strategy is that the IPLs to apply PTFs are
generally not that bad as you're never apply too many PTFs at any one
time.

There are exceptions.  The driver for doing CUM 3007 was to get the PTFs
for Type2 IFS directories.  We have tens of thousands of IFS files in a
couple thousand directories, a fair bit of which is served up by the
(original) web server using Net.Data macros to read the directories and
create dynamic web pages listing IFS docs for the users.  Anything at
all to improve that performance is worth doing.  Anyway, the exception
comes into play that for V5R1 support of the Type2 dirs, the relative
PTFs need to be permanently applied.  So after the CUM is loaded I'll
permanently apply the relative PTFs needed for Type2 dir support (vs. my
preference which would be to leave them temporarily applied).

Of course, I do this in my SPARE time...

- John

-----Original Message-----
From: Mike.Crump@xxxxxxxxxxxxxxxx [mailto:Mike.Crump@xxxxxxxxxxxxxxxx] 
Sent: Friday, March 28, 2003 7:34 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Perm. apply PTF's thoughts


Folks,

Historically, I've been remiss about permanently applying PTF's.
Originally, my thought process was that normally you see it as an item
on new releases with corresponding instructions to clean up disk space.
I've never had storage problems around new release installs so I have
forsaken that process in the name of time.

I'm beginning to wonder how wise that is.  Doesn't that leave some
potential for PTF *SAVF's and other objects (potentially IFS) out there
for cleanup?  And couldn't those objects be in many different places on
the system (QSYSDIR, QIWS, QDNS, stream files in IFS directories, etc)?
What do other people do with regards to perm apply of PTF's?  Do you
think it is easier to perm apply PTF's prior to a new release as opposed
to cleaning their tracks later or never?


Michael Crump
Saint-Gobain Containers
1509 S. Macedonia Ave.
Muncie, IN  47302
(765)741-7696
(765)741-7012 f
(800)428-8642

"We will meet that threat now with our Army, Air Force, Navy, Coast
Guard, and Marines so that we do not have to meet it later with armies
of firefighters and police and doctors on the streets of our cities."
George W. Bush  March 19, 2003

www.standwithbush.com




_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not use, disclose 
or distribute this e-mail without the author's prior permission.  We have taken 
precautions to minimize the risk of transmitting software viruses, but we 
advise you to carry out your own virus checks on any attachment to this 
message.  We cannot accept liability for any loss or damage caused by software 
viruses.