• Subject: Re: Managing PTF's...Strategy?
  • From: "E Miller" <esmiller@xxxxxxxxxx>
  • Date: Wed, 8 Jul 1998 07:53:43 -0500

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
+---


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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 here. If you have questions about this, please contact [javascript protected email address].