Hi List,
Thanks to those of you who responded. As Mark pointed out, I could install into
a program controlled TCP/IP library with a USERMOD and perhaps I should. If IBM
distributed TCP/IP with the MOD or LMOD (i.e. FTCHKCMD) defined, I would be
obligated to install with a USERMOD. Since FTCHKCMD is unknown to SMP/E, I
decided to install into our "local" LINKLIB.
It seems to me, however, that this issue could arise with a software component
that is not part of z/OS. As a general rule, our non-z/OS target DSNs (i.e.
true names) include a version-release-level qualifier. Installation and
maintenance is done using these DSNs (which are specified in the DDDEFs). They
are accessed by executables (e.g. JCL and EXECs) via a SYMBOLICRELATE alias
that does not incorporate the version-release-level qualifier (which is
represented in the SYMBOLICRELATE with a symbol).
For example, DSN=SYS2.LINKLIB.Z19 has a SYMBOLICRELATE alias of
SYS2.LINKLIB&MVSDSNQ (the symbol &MVSDSNQ has a value of .Z19 for z/OS 1.9).
This method allows us to upgrade or revert many non-z/OS products simply by
changing the value of a symbol (with a few caveats that I won't discuss here).
It irritated me that RALTER ADDMEM was not cooperating. I found a work-around.
I admit that it's not pretty and I'm not recommending it but it does work. We
have an automated startup process (after IPL). The following command is now
issued after the RACF subsystem initializes:
#RALTER PROGRAM FT* ADDMEM('SYS2.LINKLIB&MVSDSNQ'//PADCHK)
Because it's a command processed by CONSOLE, symbolic substitution occurs:
IEE295I COMMAND CHANGED BY SYMBOLIC SUBSTITUTION
ORIGINAL: #RALTER PROGRAM FT* ADDMEM('SYS2.LINKLIB&MVSDSNQ'//PADCHK)
MODIFIED: #RALTER PROGRAM FT* ADDMEM('SYS2.LINKLIB.Z19'//PADCHK)
If RALTER processing finds that the specified DSN is already defined, it
ignores the request (i.e. we don't end up with multiple occurrences of the same
DSN). Obviously, as the value of the symbol changes (due to upgrades), the
outdated DSN entries will remain undeleted.
Thought that some of you may find this interesting....
Alan
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of
Mark Zelden
Sent: Tuesday, July 13, 2010 05:47
To: [email protected]
Subject: Re: RACF PROGRAM ADDMEM and SYMBOLICRELATE
On Mon, 12 Jul 2010 15:52:29 -0700, Starr, Alan <[email protected]>
wrote:
>Hi list,
>
>I just added an FTP exit to a user loadlib that has a DSN (VTOC entry)
>of
SYS2.LINKLIB.Z19. This dataset is assigned a SYMBOLICRELATE alias of
SYS2.LINKLIB to facilitate z/OS-release-independent accesses.
>
>FTP Server requires access to the FACILITY called BPX.DAEMON which, in
turn, requires that its exits reside in a "controlled" dataset.
>
>I therefore want to RDEFINE PROGRAM FT* ADDMEM(dataset-name//PADCHK)
>
>I strongly suspect (but have not tested) that specifying the alias name
>of
SYS2.LINKLIB is not going to produce the desired effect because the OPENed DSN
(in LNKLST) is SYS2.LINKLIB.Z19 (i.e. the alias was resolved by OPEN and then
forgotten).
>
>I have tried specifying a static system symbol (&MVSDSNQ = .Z19) as
>part of
the DSN - ADDMEM('SYS2.LINKLIB&MVSDSNQ'//PADCHK) - but RACF didn't accept that.
>
>Am I stuck having to specify a full-qualified "truename" and change the
MEMBER segments of all PROGRAM resources every time I upgrade?
>
Yes, if you want to keep using that methodology. Since there should
already be a PROGRAM "*" entry with plenty of "system" libraries specified, why
not just create a USERMOD and link it into hlq.SEZALOAD or you could use
SYS1.LINKLIB (but SEZALOAD seems more appropriate).
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:[email protected]
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
