Howard,
The goal here is not to quantify an actual number of hours but to reduce
the work--and the elapsed time--to the point where the answer will be
consistently and reliably 'not too much'. We have the means on the
mainframe platform to identify, collect, and install maintenance with a
minimum of labor. Assuming a regular maintenance cycle--not specific
problem resolution--here's how to do it.
1. Before beginning a maintenance cycle, pull the latest Enhanced Hold
Data
http://service.software.ibm.com/holdata/390holddata.html
or use the hold data returned automatically with ShopzSeries orders. You
should re-pull hold data during the cycle, including one last pull just
before the actual APPLY. Enhanced Hold Data serves two purposes: prevents
PE PTFs from going on; indicates whether a PE PTF is *already* fixed by a
later PTF. If you already have the later PTF RECEIVEd, then APPLY will put
it on; no problem. If you don't already have the later PTF, you have the
option of pulling it or not. If not, the PE PTF will not install. THIS IS
NOT A PROBLEM unless you are experiencing an ongoing failure, in which
case this whole discussion is fairly beside the point.
2. Run APPLY CHECK specifying only this: BYPASS(HOLDSYS) . DO NOT specify
BYPASS(HOLDERR) except under extraordinary circumstances so rare that if I
do it once a year, it's a lot. Pick a filter that fits your goal in view
of the PTF inventory that you have already RECEIVEd. Maybe FORFMID (I
rarely use that, don't understand the need for it in the normal course of
things). Maybe SOURCEID(RSU*), which can be as general or as specific as
you choose. Maybe SOURCEID(HYPER). Whatever filter delineates a range of
maintenance that suits you.
3. Use GROUPEXTEND (GEXT) to make sure you pick up any available PE
resolvers.
4. If you get CC=0 on APPLY CHECK, look for some mistake in the control
statements. CC=0 on a 'mass' APPLY is highly suspicious.
5. If you get CC>8 on APPLY CHECK, look for some mistake in the control
statements. It does happen that SMPE will return CC=12 if no PTFs at all
satisfy the filter. Not a problem unless you're sure that something should
have been selected. Otherwise look for a syntax or logic error.
6. Assuming you get CC=8 (normal in my world), do not be distracted by
irrelevancies. Go straight to the SMPRPT file and find 'CAUSER'. This
report succinctly tells you the *initial* glitch in each of what may be
many chains of errors. The SMPOUT file will enumerate all the errors
encountered, but you only care about the *first* one in each chain. That's
what you see in the CAUSER report.
7. Assuming that you have recent HOLD data, you can generally live with
messages like this:
UA20455 HDZ11K0 GIM35901I 1 ERROR HOLD AA15672 WAS NOT
RESOLVED.
Unless you have some very specific and compelling reason to track this
down, forget about it. It's not our job to resolve every error hold. If
you're queasy, check IBMLINK SIS for the very latest status of the error
APAR (OA12345 or PK12345 depending on the component). Status can range
from OPEN (still being worked on) to CLOSED with no fix available to
CLOSED with an indication that an APAR fix can be requested or an assigned
PTF number is in the works. Unless you have a very strong motive for
obtaining the fix, just let it go.
8. If you see a message that PTF so-and-so would have resolved a PE, then
determine whether the later fix is GA and just not RECEIVEd. If you use
ShopzSeries fastidiously, this condition should be rare because REQs will
be included in every order.
9. A few other 'environmental' problems may show up in the CAUSER report,
such as missing DDDEF. This happens when a PTF introduces a new library or
PATH. There should be a HOLD record to tell you what to do. This happens
but rarely.
10. If you spend more than 30 minutes on the CAUSER report (including
bathroom break and cup refill--previously brewed--then you may be fussing
too much. Again, you're only looking for problems that have simple
solutions: missing GA PTFs, missing data sets, etc. You're a master
mechanic installing OEM parts from a presumably competent supplier. If you
pause to examine each part under a microscope, the customer will be
hitchhiking for the next week.
11. Now you get to look at the ++HOLD records. This will take longer, but
still in low single digit hours. Some tips:
- Ignore all REASON(IPL) records. Face it, in a mass APPLY, you WILL have
to IPL. Period. One IPL covers all, so pay no attention to these records.
- If you see CLPA, no sweat because you know that good practice calls for
CLPA on every IPL and you already do that.
- Scan REASON(RESTART) records and ignore them unless they include
elaborate shutdown and start up instructions. Simple restart is covered by
CLPA.
- REASON(AO) records are strictly for automation. If you have no
customizable product, ignore these. Otherwise check for impact on your
product.
- By far most REASON(DOC) records are FYI, some you can make use of, some
of interest only to IBM or ISV developers. Good bedside reading.
- REASON(ENH) are like DOC but indicate enhancements rather than fixes.
Scan now, read later.
- REASON(ACTION) and REASON(MULTYSYS) need to be read with some care. Some
require action *before* APPLY. Some after. Despite the label, many don't
require any action at all depending on your configuration and environment.
- Some others that you should read: DB2BIND, DEP, DOWNLD, EC, MSGSKEL. You
may or may not need to do something.
12. Assuming you've been left more or less alone to work on this, it
should still be the same day you started at #1. Now here's some tough love
advice. Once you've finished with step #11 and feel that you've done your
homework, take a big deep breath, comment out the CHECK in your job, and
submit it. Don't waste time trying to 'scrub' the job so as to get CC=4.
When the real APPLY is done, look at the CAUSER report again. You should
see only the same messages as in the APPLY CHECK job. If so, take the rest
of the day off. Otherwise deal with any new messages, which will most
likely be data sets running out of space (extents) or directory blocks.
Fix those problems as you normally would and resubmit the *exact same
job*. Repeat this step until the CAUSER report again looks like the APPLY
CHECK. Now take the rest of the day off. You've earned your three square.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Howard Rifkind <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
05/10/2006 11:22 AM
Please respond to
IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Quantifying SME Apply Check Hold Reasons.
My mangement is asking me that after doing an apply check on various
FMID's that I some how quantify how much work there will be to researching
what is needed to resolve these holds.
I have no idea how to measure this. Number of holds, by error hold
reason grouped together...what?
Any suggestions will be appreicated.
----------------------------------------------------------------------
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
