|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
