× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Short answer: Read the instructions.

Longer answer:
http://search400.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid3
_gci1102658,00.html 

Correct answer: It depends...

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group


-----Original Message-----
date: Tue, 27 Jun 2006 08:17:38 -0400
from: rob@xxxxxxxxx
subject: RE: V5r4 Upgrade, IPL required between Cume and Group PTF
        installs

Did anyone suggest applying a group first before a cume?  I didn't see
that.

In theory, Tom, if you put on a cume but do not IPL, and then put on
some groups then the prereq's and coreq's should be there.  I do this on
all cumes, after the first cume from the upgrade, and do not have any
problems.  However I still recommend putting on the cume, IPL, then
groups, etc for immediately after an upgrade.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





qsrvbas@xxxxxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/26/2006 07:12 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
RE: V5r4 Upgrade, IPL required between Cume and Group PTF installs






V5r4 Upgrade, IPL required between Cume and Group PTF installs
midrange-l-request@xxxxxxxxxxxx wrote:

  3. RE: V5r4 Upgrade, IPL required between Cume and Group PTF
     installs (Paul E. Fenstermacher)

You should ALWAYS install the cume, IPL, and then install the groups
after the INZSYS completes when doing an OS upgrade.  I don't remember
the exact terminology but I'm pretty sure you get a message when trying
to install the groups before the INZSYS completes and it won't let you.
When doing a ptf install only I do the groups first then the cume
followed by one IPL.  Has worked for 20 years!

20 years? I don't recall exactly when groups were started, but I'm
pretty 
sure it's a few years less than 20 ago.

I've always wanted the cume done first. That's primarily been because of

supersedes and pre-reqs/co-reqs that some PTFs within a group might
want. 
Also, it's possible that a cume _might_ contain PTFs for the PTF process

itself.

Besides, there are multiple group levels available within a single cume 
level. If you apply group level #1 and then cume #1, why attempt to
apply 
group level #2 before cume #1? It's nonsensical.

I generally want to apply the cume before loading any group. The cume 
should get the system into the best condition that's reasonably possible

in order for the group to load and apply cleanly. Any PTFs that are (1) 
pre-req/co-req for the group and (2) in the cume should then already be
on 
the system.

IMO, the cume is more for general system health while a group is for 
specific areas. I usually want to get all 'Actions' completed for a cume

if needed, before attempting any group. It's just seemed to work out 
better.

AFAIK, PTFs that are supersedes/pre-req/co-req might all be contained 
within a group package. However, at least early on when groups became 
common from IBM, it seemed that far too many PTFs needed 'Actions' that 
required multiple cycles. "PTF x needs PTF y applied PERM first", or 
similar. But getting the cume fully applied seemed to help minimize
those.

Particularly in light of the one-to-many relationship between cumes and 
groups, I'd love to know why groups-before-cumes is important. I'm
always 
open to education. I can see sense in loading both and applying them in
a 
unified cycle, especially when image catalogs are used (and related PTFs

are already applied).

Tom Liotta


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

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.