Someone else commented on the RESTORE question, but I'd like to expand on
it. In general, I see little reason ever to RESTORE a usermod. Yes, I know
the book says to do it, but it strikes me as extra work to arrive at the
same (intermediate) spot: code returned to its original, unmodified state.
With the right combination of REWORK and PRE values, you should seldom
(never?) need to REJECT or RESTORE a usermod.
For example, we maintain a ZAP usermod to an RMM table in order to mimic
behavior of a previous product around which countless production processes
have been built over the years. (Thanks to Monsignor Wood, that cross will
be lifted from our shoulders in R11 according to a new Health Check.)
Unfortunately the table moves around not only in new releases, but also
rather frequently by PTF. The same ZAP replacements work every time, but
almost always at a different offset. This usermod automatically gets its
name inserted as UMID in order to trigger a regression message whenever
that CSECT gets hit by a PTF. Hence no UCLIN is required. A few of points.
1. One 'unnatural' step is necessary at the start of each iteration: APPLY
SELECT the colliding PTF with BYPASS(ID). That's about the only time I ever
do such a thing.
2. In order to determine the new offset, we pretty much have to install the
PTF anyway before reworking the usermod.
3. By updating the REWORK value with the date of update, we don't need to
REJECT the usermod. As long as the new REWORK is higher (EBCDIC collating
sequence) than the old one, the usermod is re-received.
4. By updating the PRE values with the latest PTF, SMPE understands where
the usermod fits in the hierarchy, i.e. on top of all other sysmods.
Here's what the current usermod wrapper looks like.
//SMPCNTL DD *
SET BDY(GLOBAL) .
RECEIVE SYSMODS BYPASS(APPLYCHECK) .
SET BDY(MVST100) .
APPLY S(RMM0004) REDO .
//SMPPTFIN DD DATA
++USERMOD(RMM0004) REWORK(2009174 ) .
++VER (Z038)
FMID(HDZ1190)
PRE(
UA34754
UA39850
UA43733
UA90496
UA47393
) .
++ZAP(EDGVRECM) .
[rest of zap code goes here]
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
Jeffery Swagger
<jeff...@comcast.
NET> To
Sent by: IBM IBM-MAIN@bama.ua.edu
Mainframe cc
Discussion List
<ibm-m...@bama.ua Subject
.edu> Re: SMPE usermod sample
07/09/2009 05:40
PM
Please respond to
IBM Mainframe
Discussion List
<ibm-m...@bama.ua
.edu>
Yes, this is essentially what I do too.
The problem I have with changing the RMID via UCLIN approach is that you
have to (I believe) undo it via UCLIN at RESTORE time. I prefer not to
have to that.
As an aside, the thing I do in cases like this is to replace the SAMP
with something like this:
++ SAMP(ISRONLY)
*******************************************
* See USERMOD xxxxxxx *
*******************************************
This both updates the RMID so I get MODID error if IBM updates the SAMP
and provides some doc if somebody is looking at the SAMP library.
And it's not my idea. It's something, like so many things I do, that got
posted on this list ???? years ago. I have no shame when it come to
using the ideas of the more knowledgeable people on this list. :-)
--
Jeff
<snip>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
