I'm a DB2 SysAdm/SysProg and DB2 maint always has reams of hold data. The longer you leave it the bigger the job to wade through it all and build the required jobs. Multiply it by many DB2 sub-systems and the job gets bigger and bigger. You have to have the toleration fixes on the current release of DB2 before you can upgrade to the next release (in case of fallback to the old release with the new release catalog/directory structure) and that can be a big job if you are way back on maintenance. Cheers, Mick.
On 24 November 2016 at 05:35, Edward Gould <[email protected]> wrote: > > On Nov 23, 2016, at 8:32 PM, Joel C. Ewing <[email protected]> wrote: > > > > I think the car analogy with computer systems breaks down on a number > > of points (at least in the case of mainframes): > > (1) while bleeding-edge-current is certainly not essential, the > > further you get behind on software maintenance, the more costly it gets > > in terms of time and person-hours to get reasonably current; and without > > being reasonably current you may not be able to utilize new hardware > > that could be more cost effective, or needed when old hardware dies, or > > needed to adapt to growing business requirements. The cost of failure > > to do preventive maintenance on a car is bounded by the time and cost > > for replacement transportation, no matter how much maintenance was > skipped. > > (2)software maintenance relating to security or data exposures may > > need prompt attention to avoid much more expensive data loss or data > > exposure scenarios, which may also have serious legal implications. > > Failure to do preventive maintenance on a car doesn't generally make it > > more susceptible to hackers or have legal implications, unless you fail > > to repair an obvious safety hazard and that results in a personal-injury > > accident or death.. > > (3)Unexpected failures of a lesser-maintained car more often than > > not just causes a temporary loss of availability which with sufficient > > funds can be easily resolved, as there are many ready substitutes for > > the basic function of transportation. A corporate computer system has > > company-specific data and company-specific applications which cannot > > just be replaced by any generic computer system, and it may be > > impossible for the company to stay in business very long without that > > data and those applications. Recovery from some software failures that > > result in data loss is only possible with adequate DR planning in place, > > and if adequate planning was not in place, recovery may not even be > > possible at any price. While I believe a valid argument can be made > > against applying maintenance just for the sake of maintenance, some of > > the problems addressed by HIPER PTFs are so dire you really don't want > > to wait for that failure to occur before installing the fix. > > > > Even with a car, while it may be cost-effective to avoid or stretch out > > some preventive or recommended maintenance, I strongly suspect it would > > not on balance be cheaper for you to take that to the extreme and, say, > > never change the engine oil (unless of course your plan is to sell > > the.car after a few years without disclosing the potential shortened > > engine life and cheat the next owner). > > Joel C. Ewing > about 20 years ago I worked at such a place. They did NOT believe in > applying maintenance. > Along comes the Y2K problem and they were in a bind (to say the least). > They decided to order a servpac (new at the time). > They were a big user of DB2 (I have no knowledge of it) but they were > really hurting in order to get up to snuff. > They were non going to ORDER COBOL (current as it cost $5 more than the > old) then LE hit them in the face and they *HAD* to order that. That almost > burst their gut. > I am glad I got out of there. > Ed > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
