On Wed, 13 Sep 2006 14:13:56 -0400, David Cole <[EMAIL PROTECTED]> wrote:
>At 9/13/2006 01:30 PM, TMerchant wrote: That's Marchant, thank you. >>But why does it require that previously received maintenance be >>REJECTed and that previously APPLY'ed maintenance be RESTORed? > >Because our maintenance is cumulative, not incremental. > - That means that the latest maintenance file always > contains all maintenance, not just the most recent. There is no reason you couldn't have a new PTF that SUPed all previous maintenance, nor is there any reason you couldn't include all maintenance in a single file. > - That means that the file as a whole has to be APPLY'd to > the instance of the product that existed immediately > after initial install. That is not proper packaging of maintenance. > - That means that all prior maintenance has to be removed > before the new maintenance file can be successfully > APPLY'd. That is because the maintenance is poorly designed. > - And that's what RESTORE and REJECT do. But that is not what RESTORE and REJECT are for. > - And that's why our canned maintenance JCL contains > RESTORE, REJECT, RECEIVE and APPLY, in that order. > In other words, the process is fully automated by a > single job. It sounds to me as if your installation and maintenance processes do not benefit at all from the use of SMP/E > >Note, the only time our maintenance job fails is when the SYSPROG >does an ACCEPT of prior maintenance. Doing that prevents RESTORE from >reverting the libraries to their initial installation state (a state >which the cumulative maintenance file does NOT fit.) Therefore your maintenance is not properly packaged. > >But even that's not so bad, because it also is trivially easy for the >customer to recover simply by rerunning the initial installation >jobs, a process that, for our product, takes about 4 minutes. > >As I said in my initial post, the advantage of cumulative maintenance >over incremental maintenance is that customers, when they eventually >get around to applying maintenance (a far less frequent event than I >would like), need only download the latest maintenance file. They >don't need to go scurrying around looking for older maintenance, and >I don't need to maintain the older maintenance as individual files. > > > > > > >>>Using a system in a way that was never envisioned by the creators >>>can be brilliant innovation. It can also be what is termed "gaming >>>the system"... >> >>Well said > >I prefer to call it, simply, a good idea. > Those are not the words that come to my mind. Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
