MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » October 2004

Re: Which group PTFs do we need?



fixed

The criteria for a ptf to be placed on a cume are based on a few factors:
- Is it a hiper ptf?
- If it is not a hiper ptf, have enough people ordered it that we feel 
safe enough to release it to the masses?

The second one is the catch.  IBM is afraid that a ptf may have went 
through testing.   And it may have been ordered by a dozen or so customers 
and seemed benevolent.  However when released to the masses it hits much 
more of a wider customer base.  Customer's who have a wider variety of 
unique situations:  different hardware, different mix of program products, 
different workload, etc.  And then the ptf might not be so benevolent. IBM 
might have missed some unique situations.

The second criteria does not apply so much to group ptf's.  Yes, they've 
still gone through testing.  And they might have even been prereleased to 
a few customers as a 'test' ptf.  But they're not quite as cautious on the 
volume of customers requesting it.

IBM is giving their customers a choice as to whether they want to do this. 
 I don't feel that group ptf's are quite "dancing on the edge", but others 
might.

I order the cume and any groups that sound sexy to me via ftp.  I use 
image drives to load all them up and set them to apply later.  In other 
words I do the GO PTF, option 8, but no IPL.  I do this during prime 
shift.  Every 8 weeks we IPL.  And I get these ptf's ordered and loaded up 
during the week prior to that weekend.

When I order numerous group ptf's via ftp they come down in one chunk. The 
cume is always a separate chunk.  Same if you order them via CD's.  But 
it's been awhile since I've done that.  I've gotten rather disgruntled 
with the relationship of IBM with the various shipping companies and no 
longer even order them that way "as a backup".

Personally I wouldn't mind more frequent cumes and having all group ptf's 
on the cume, but I can respect customers that might feel differently than 
me.

What grinds me is when a support person says that you should put on a more 
recent group but, for the life of them, cannot point out which ptf, if 
any, on the newer group that wasn't on your older group, might apply to 
your situation.  Don't hear this as often as I used to though.

Multi level group support would be nice.  There's a few days every 8 weeks 
when I have a group that is 'not applied' because I loaded a newer one and 
set it to apply at the next IPL.  Invariably I'll have to open three pmr's 
during that time period.

And I believe that some ptf's actually do get applied even though I told 
it I'll IPL later.  Haven't many of us seen cover letters that say 
something like "this ptf will automatically be permanently applied upon 
loading it" or some such gibberish?

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





"Mark S. Waterbury" <mark.s.waterbury@xxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/26/2004 09:37 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Re: Which group PTFs do we need?






Hello, all:

This whole discussion of "Group PTFs" begs the question, why do we need
"Group PTFs" at all???

I thought the whole idea for CUMulative PTF packages was to make it easy 
for
customers to stay current, packaging ALL of the PTFs they need in one
convenient bundle that could be installed as if it is one large PTF.

But, over the past few years, it seems that IBM has corrupted that concept
by introducing various Group PTFs (for WebSphere, for DB2, for Java, 
etc.),
and this really complicates our lives -- trying to figure out which ones 
to
order, and what sequence to install them, etc.  (And just try to explain 
all
of this to a NEW iSeries customer!)

Also, if I have the latest CUMe PTF package installed, do I really still
need any Group PTFs? If so, why? I thought that was the whole point of 
CUMe
packages?

I was told that IBM supposedly did this (introduced Group PTFs) to reduce
their costs and make it easier for customers to order only those PTFs they
"need" (e.g. all PTFs for DB2 or all PTFs for Java), but in reality, since
customers do not know which Group PTFs are really needed, they ended up
ordering ALL of them (or all the ones they think they needed), so I 
suspect
that IBM's actual costs to create CDs and ship them to customers were
actually higher than staying with the original CUMulative PTF package
concept.

Also, now, with iPTFs and the ability to download the whole PTF package 
via
the Internet, there really is NO cost for burning CDs or shipping, so that
argument goes away also.

Has anyone figured out a good strategy, other than to order ALL of the 
group
PTFs that seem to apply?

And, when you have to install more than one Group PTF, which one do you
install first? The CUMe PTF package, then the group PTFs, or the other way
around?

If I order and apply ALL of the group PTFs, do I still need to order and
install the latest CUMulative PTF package?  And, perhaps more important, 
if
I install the latest CUMe PTF package, do I really need to order and 
install
ANY Group PTFs? If so, why? I mean, isn't the CUMulative PTF package
supposed to contain all of the latest PTFs that I need?

I think this is one area where IBM has really gone "backwards" over the 
past
few years, under the false assumption that this was "progress" -- 
delivering
PTFs to customers faster, etc. -- in reality, they have apparently created
more problems for customers than they solved, IMHO.

I think we were all far better off, and would be so again, if IBM would 
just
get rid of the group PTFs and keep the CUMulative PTF packages more
up-to-date, perhaps refreshing them monthly, since there is no longer any
cost for burning all of those CDs, and shipping, etc. -- just let us
download them, via the (relatively nice) iPTF process.

That's just my opinion -- what do you think?

Regards,

Mark S. Waterbury

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







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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