|
I would only add that if your DASD gets full, you can perm apply PTF's that have been temp applied to free up space. Evie Miller ---------- > From: Alan Smith <alans@toorakc.vic.edu.au> > To: 'MIDRANGE-L@midrange.com' > Subject: RE: Managing PTF's...Strategy? > Date: Wednesday, July 08, 1998 1:56 AM > > Hello from Australia. > > Jim, > > Yes, it is completely normal to run from the 'B' side all the time > (generally). > > It is better to keep the temp PTFs as temp PTFs, that way you can remove > one if you start to experience a problem. You should keep up to date > with the CUME releases as well. Review the PTF cover letter that tells > you all about what each PTF is about. You may not need/want to install > all of them if you think your AS/400 environment is not likely to change > dramatically over time. > > I have not ever had a problem with PTFs and have always followed these > guidelines. Generally you only need to permanently apply PTFs before an > upgrade. Then you may get notification from IBM about deleting certain > PTFs before doing the upgrade as well. > > Regarding tape management, it is not generally so much more risky taking > the tapes home (depending on where you live I suppose) than the > potential disaster of have them and your AS/400 burn up, drown, or get > stolen from work at the same time by leaving them there. If you live in > the tornado belt, or other somewhat disaster prone area, either place > may not be all that 'safe'. But at least if a copy is 'offsite' you > will only be inconvenienced by the drive home (and back) to get them. I > take our tapes home. Yes, a tape service could be an ideal solution, > but I would be extremely interested in what they do with them! If you > combine it with a disaster recovery plan for access to your AS/400 data > at another location (another business service provided to the AS/400 > community by several vendors - including IBM) then you have both bases > covered. > > Warm regards from Melbourne, Australia > > Alan Smith > President, COMMON Victoria > Application Div. Mgr. COMMON98 > > MIS Manager, Toorak College > Old Mornington Road > Mount Eliza, Vic 3930 > > Direct: (61-3) 9788-7255 (61 Australia, 3 Victoria) > Switchboard: (61-3) 9788-7200 > Fax: (61-3) 9787-5888 > > Email: Alans@Toorakc.vic.edu.au <mailto:Alans@Toorakc.vic.edu.au> > Website: www.toorakc.vic.edu.au <http://www.toorakc.vic.edu.au> > > > -----Original Message----- > From: Jim Welsh [SMTP:jimwelsh@ix.netcom.com] > Sent: Tuesday, July 07, 1998 12:03 PM > To: MIDRANGE-L@midrange.com > Subject: Managing PTF's...Strategy? > > You Guru's > > I'd like to start a discussion dealing with the management of > PTF's and > Client Access upgrades. > > My own thoughts on this are to keep current and perm apply after > a week > or so if all is well. > > IPLSRC A, B....? > > I've not been involved in operations that much as I've mainly > been > application programming for > the last 10 years. > > Being in a two person shop now where the manager appears to know > less > than I do about *managing* the 400 I'd like some feedback on > some *best > practices* approaches... > > Is it normal to run off IPLSRC B everyday ? > > Is it not more effecient to perm apply your ptf's ? > > How many have been burned by a perm applied ptf that was bad ? > What was the solution ? > > How about tape backup management, isn't it a bit risky to take > backup > tapes home with you > escpecially when your not keeping them in a safe ? > > Everyplace else i've worked has had there tapes picked up by a > service > company ( not sure what exactly they do with them ) : ) > > I'd like to see the two of us run an organized shop with good > practices > in place but right now I think we have much room for > improvement. > > I can't make these decisions but I can make suggestions. Perhaps > after > hearing about what others > are doing I'll have even better suggestions to make. > > Oh where Oh where will I find a well managed IS dept... > > tia > > -- > Jim > I'm surprised anything works at all > http://www.netcom.com/~jimwelsh/welcome/welcome.html > mailto:jimwelsh@ix.netcom.com > > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to > MIDRANGE-L@midrange.com. > | To subscribe to this list send email to > MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.