• Subject: Re: Time for cume PTFs
  • From: rob@xxxxxxxxx
  • Date: Thu, 5 Apr 2001 10:41:21 -0500


1)  Cum's versus groups.
Cum's come out only at great intervals, (or in the case of obsolete
versions of the OS, never).  Groups come out more frequently.  Sometimes as
little as two weeks.  Groups are targeted as specific areas like:  Hipers,
TCP/IP, Database, Save/Restore, various flavors of web servers, JAVA, etc.
Group ptfs have levels like SF99105 is a group ptf for a certain release.
On some of the group ptf's (Why not all?!) you can check the level by doing
a DSPDTAARA SF99105 to see what level you are on and when:  'Group PTF#:
SF99105-03  V4R5M0 10/31/2000'.  Group PTF A may contain several new ptf's
if ordered a month later.  Cum's are a different animal.  You may order
SF99450 but you won't receive that.  Instead you'll receive the latest cum
for 450.  Which may be called C01005450 and appear on your system as
TL01005.  General strategy is to:
a)  Schedule your down time
b)  browse the web for the group ptf's applicable for your release and
applications
c)  Order the latest cum and order the group ptf's, (always hipers,
database, save/restore).  don't order too far in advance
d)  bring system to restricted state
e)  go save, 21, don't let it restart controlling subsystem
f)  apply cum, let it ipl - why ipl?  Once you've filled a 'link loader'
and have to reinstall the OS you don't want to do that again.
g) bring system back to restricted state
h)  load all cum's only ipl after last one

2)  Can this be done in one weekend?
It mainly depends on the speed of your saves and the speed of RCLSTG if you
choose to run that.  Not counting that, yes it can be done in one weekend.
Here we do this on several as/400s every 8 weeks.  Starting Friday at 5p
and most are up by 12N on Saturday.  Only one system skips the rclstg and
that is because that machine normally takes 12 hours to run a rclstg.  We
don't slouch on processors or tape drives.

3)  Should you apply the latest cum's and group ptfs to a dead 400, like a
V3R2 system?
If you have no plans to upgrade, and are not experiencing problems, it may
be tempting to not apply ptf's.  However often in these PTF's are hidden
certain security PTF's that may block critical holes.  Or, maybe, you've
just not hit the 'right condition' that causes a condition that was already
fixed by a certain ptf.
If you are upgrading, then stay current.  Also read the 'Roadmap', there
may be some planning or upgrade ptf's that you may need for the migration.

4)  Given that, aren't we just saving *ALLUSR from the V3R2 box and
restoring to the new box?
He## no!  Read the Roadmap.  There are several upgrade paths.  Read the
Roadmap.  You might be using the 'side-by-side'.  Read the Roadmap.
All-in-all, I think you need to read the Roadmap.  Notice a pattern here?
*ALLUSR will miss many things like:  objects which do not have
observability and won't work, user profiles, tcp/ip configuration, other
configuration issues, and a boatload of other information.  Read the
Roadmap.


Rob Berendt

==================
Remember the Cole!


                                                                                
                                         
                    D.BALE@handleman.co                                         
                                         
                    m                          To:     MIDRANGE-L@midrange.com  
                                         
                    Sent by:                   cc:                              
                                         
                    owner-midrange-l@mi        Subject:     Time for cume PTFs  
                                         
                    drange.com                                                  
                                         
                                                                                
                                         
                                                                                
                                         
                    04/04/01 01:30 PM                                           
                                         
                    Please respond to                                           
                                         
                    MIDRANGE-L                                                  
                                         
                                                                                
                                         
                                                                                
                                         




As promised yesterday with the resolution of our serial number fiasco,
moving
on to my next topic:

I've ordered cume PTFs (SF99vrm) for the V3R2 & V3R7 boxes, which were last
cume'd in '97 & '98.  (How this shop made it through Y2K, I'll never know.)
It's been several years since I've had to work with PTFs.  I have also
downloaded the PSPs (SF98vrm) and am running through those as well.

Through this mailing list, I am aware of the "group" PTFs (database, Y2K,
others?)  Is there a reason why these aren't on the cume PTF?  (Maybe that
was
a bad assumption - Are the group PTFs on the cume?)

Can the cume and group PTFs all be applied in one shot?  Can it be done in
one
weekend?

Since V3R2 is a dead-end, does it make any sense at this point to even
apply
the cume for that?  Eventually, that CISC box will be traded in for (o.k.,
replaced by) a V4R5 or higher RISC box.  Given that, aren't we just saving
*ALLUSR from the V3R2 box and restoring to the new box.  Or is there a
minimum
cume level we need to be at to be able to do that?

Other advice on applying cume & group PTFs are welcome.

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)
+---
| 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].