I agree with Gil that by far the most important effect of a usermod based
on an IBM-supplied element to force a 'modid error' in case the original
element is ever hit by a PTF. There may be multiple ways to get the user
element installed as desired in a single step. Whatever. Here's an example
of how we implement a sample source into production. The key is to set the
RMID via UCLIN. The rest is fluff.
//SYSIN DD *
SET BDY(GLOBAL) .
RECEIVE SYSMODS S(CONS001) .
SET BDY(MVST100) .
APPLY S(CONS001) REDO .
UCLIN .
REP SAMP(IEECMDPF) RMID(CONS001) .
ENDUCL .
//SMPPTFIN DD DATA,DLM=$$
++USERMOD(CONS001) REWORK(2007197)
/* This usermod assembles and links SAMPLIB member
IEECMDPF, which allows one to direct console
commands via SYSID prefix rather than ROUTE.
No changes are made to the sample, but UCLIN
sets the RMID in case a future PTF requires the
member to be reassembled.
*/ .
++VER(Z038) FMID(HBB7740) /* ZOS R19 */ .
++ JCLIN .
//ASM EXEC PGM=IEV90,PARM='DECK,NOOBJ,XREF(SHORT)'
//SYSIN DD DDNAME=SAMPLIB
//SAMPLIB DD DSN=SYS1.SAMPLIB(IEECMDPF),DISP=SHR
//SYSPUNCH DD DSN=SYS1.SYSPUNCH(IEECMDPF),DISP=SHR
//LINKEDIT EXEC PGM=IEWL,PARM='XREF,LIST,LET,NCAL,AC=1'
//SYSLMOD DD DSN=SYS1.LINKLIB,DISP=SHR
//SYSPUNCH DD DSN=SYS1.SYSPUNCH,DISP=SHR
//SYSLIN DD *
INCLUDE SYSPUNCH(IEECMDPF)
NAME IEECMDPF(R)
++SRC(IEECMDPF) DISTLIB(ASLIB01) TXLIB(SAMPLIB) .
$$
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
Paul Gilmartin
<paulgboul...@aim
.COM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[email protected] Subject
.edu> Re: SMPE usermod sample
07/02/2009 06:46
PM
Please respond to
IBM Mainframe
Discussion List
<[email protected]
.edu>
On Thu, 2 Jul 2009 20:47:47 -0400, Jeffery Swagger wrote:
>Yes, but this strikes me as incomplete.
>
>I did try an APPLY CHECK of the proposed USERMOD (minus the JCLIN) and
>it appeared to produce the desired result.
>In that a ++EXEC element would be created (target library SISPEXEC) with
>an ALIAS of ONLY copied from SISPSAMP.
>
>However, here's the problem. The shipped IBM element ++SAMP(ISRONLY) has
>no updates associated with it.
>This is telling me, and I could be wrong, that IBM could ship a PTF to
>ISRONLY, and then my ++EXEC is
>out-of-sync because IBM knows nothing of a ++EXEC(ISRONLY). Uh Oh
>
>It seems to me that a complete solution to this problem requires that
>the ++SAMP(ISRONLY) must have the RMID updated.
>That way, if there is an IBM PTF, then SMP/E will detect a MODID error.
>
>Mark Zelden said the following on 7/1/2009 12:58 PM:
>> On Tue, 30 Jun 2009 10:22:01 -0400, Kurt Quackenbush <[email protected]>
wrote:
>>
>>>> Perhaps Kurt Quackenbush (or someone else) would have a better way
>>>> or "more proper" way to do it, but I think this should work:
>>>>
>>>> ++USERMOD (UMISPMZ) .
>>>> ++VER (Z038) FMID(HIF5H02) .
>>>> ++EXEC(ISRONLY) DISTLIB(AISPEXEC) ALIAS(ONLY)
>>>> SYSLIB(SISPEXEC) TXLIB(SISPSAMP).
>>>> ++JCLIN.
>>
I believe (but I'm uncertain) the following:
o You should apply the USERMOD to SAMP(ISRONLY). This
sets the RMID of ISRONLY to UMISPMZ so the MODID
check will happen because the IBM PTF presumably does
not acknowledge UMISPMZ.
o On a subsequent PTF to ISRONLY, SMP/E will ask that
the USERMOD be RESTORED, then re-APPLYed.
o I don't know how effectively to change the SYSLIB.
-- gil
----------------------------------------------------------------------
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
