|
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.
As an Amazon Associate we earn from qualifying purchases.
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.