RE: Which group PTFs do we need? -- MIDRANGE-L

Fantastic idea!

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





"John Brandt Sr." <pgmr@xxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/26/2004 10:07 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?






I have offered my services to IBM to pull the current licensed programs 
from
a machine (partition...) and compare it to the PTF releases and
automatically list/download the appropriate PTF's to that machine, thus
automating the process like the windblows update site.
No response.

John Brandt 
iStudio400.com 
(903) 523-0708 
Home of iS/ODBC - MSSQL access from iSeries and RPG. 




-----Original Message-----
From: Mark S. Waterbury [mailto:mark.s.waterbury@xxxxxxx]
Sent: Tuesday, October 26, 2004 9:37 AM
To: Midrange Systems Technical Discussion
Subject: Re: Which group PTFs do we need?
Importance: High


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.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/04
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.782 / Virus Database: 528 - Release Date: 10/22/04
 
--
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.