Ed:
I am not sure I agree.
I swear by the return codes in SMPe Simple rule is anything above a 4
(four) needs attention.
That is as simple as you can get. I never applied maintenance on a
live running system, it was always on a sysres or DLIB(s) on a set of
disks that were mounted as private (non SMS).
The only issue I ever ran into at times were some library did not
have enough library blocks and those were messaged to increase the
space and then the job was resubmitted.
It was a while ago but I think through a CBPDO I put on 4 or 5 years
worth of maintenance (long story) and the only issue I ran into
(other than directory space) was a pre req issue that IBM screwed up
on (it was an issue of TSO/e and TCAS if I remember correctly its
been twenty years).
A return code of 4 to me was goodness. I still looked for problems
but it was a matter of well it ran OK and just checking for an
possible issues that should be looked at.
Once in a great while there was a new library (system or dlib) that
wasn't well documented and it need creation or in one or two cases a
sysres library need additional directory blocks.
One thing I always did after an apply I would backup the drive and
compress every PDS on the volume (same thing with accept but I only
did accepts once a year).
Return code 8 (or above ) was a red flag and it needed some attention.
I was also very careful to read PTF cover letters on anything that
had a interesting hold on the PTF. Usually the holds were enough to
alert of issues during the SMPe process that avoided potential
problems. The record for me was an apply of 3000 PTF's (at one time).
The job lasted for 12 hours and it (after a lot of checking before
hand) ended with a 4.
Ed
On Oct 6, 2012, at 10:48 AM, Edward Jaffe wrote:
n 9/6/2012 8:31 PM, Skip Robinson wrote:
I have never understood the fixation with rock bottom return
codes. SMP/E
maintenance is so much simpler without agonizing over every uneven
cobblestone along the path.
LOL. You have provided an excellent description of, what I consider
to be, the most logical way to use SMP/E. Unless you're trying to
fix a specific problem with a specific PTF, just put on the service
that goes on smoothly and leave everything else alone. Don't sweat
the details!
As a part-time sysprog, I abbreviate your approach even more. I
have no time for pesky 'CHECK' operations. I submit a job that does
an ACCEPT for all 14 DLIB zones we actively maintain. Space
problems and the like are corrected and the job resubmitted if
necessary (usually not). I then submit the job that does an APPLY
for all 14 actively-maintained target zones. Again, space problems
etc. are corrected and the job resubmitted if necessary. The whole
thing usually takes about an hour when there are no space or other
issues. Then we conduct a rolling IPL.
Oh, and did I mention that this is done on a LIVE system? We have
no time or personnel to 'clone' systems, switch between res packs,
etc. for regular maintenance. Our philosophy is similar to that
described by Ed Webb at SHARE in Anaheim in session 11581: A
Different Way to Perform z/OS Maintenance.
https://share.confex.com/share/119/webprogram/Handout/Session11581/A
%20Different%20Way%20to%20Perform%20zOS%20Maintenance.pdf
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
[email protected]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
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
