Yes, we use them extensively; they facilitate easy migration, implementation
and regression. How they are used in a DSN depends upon the dataset's usage.
DLIB datasets contain a qualifier of the form Vvvrr
vvrr = version and release
Target datasets contain a qualifier of the form Vvvrrllw
vvrrll = version, release and modification level
w is a "wave" identifier to differentiate maintenance levels if ll does
not do so
Customized datasets contain two qualifiers: [scope].[designator]
[scope] is the constant GLOBAL, SYSPLEX or IMAGE
[designator] is &SYSNAME when "scope" is IMAGE or &SYSPLEX when "scope"
is SYSPLEX
Functional datasets contain two qualifiers: [scope].[designator]
[scope] is the constant SYSPLEX or IMAGE
[designator] is &SYSNAME.w when "scope" is IMAGE or &SYSPLEX.w when
"scope" is SYSPLEX
w is a "wave" identifier to differentiate reformatting (i.e. upgrades
that require a functional dataset to be reformatted)
There are at least two associated static system symbols for all non-DLIB
datasets associated with a product. SMP/E DLIB DDDEFs point to real DLIB DSNs
and no aliases are defined for them. Each symbolic name indicates the team that
is responsible for it (e.g. Z = z/OS team; N = Networking team; D = Data
management team) and the product (i.e. pppp) with which it is associated. The
following symbols are defined here for Tivoli NetView:
&tppppVRL [for example &NCNMVRL=V050300A]
&tppppFWI [for example &NCNMFWI=A]
The symbolic-relate aliases are defined similar to:
$NT.NETVIEW.CNMCLST symbolic relate to $NT.NETVIEW
.&NCNMVRL..CNMCLST
$NT.NETVIEW.DSIPARM symbolic relate to
$NT.NETVIEW..&NCNMVRL..DSIPARM
$NC.NETVIEW.SYSPLEX.DSIPARM symbolic relate to
$NC.NETVIEW..&SYSPLEX..DSIPARM
$NC.NETVIEW.IMAGE.DSIPARM symbolic relate to $NC.NETVIEW.
&SYSNAME..DSIPARM
$NF.NETVIEW.IMAGE.DSILOGP symbolic relate to
$NF.NETVIEW..&NCNMDOMN&NCNMFWI..DSILOGP [e.g. $NF.NETVIEW.CNM01A.DSILOGP]
The symbolic alias names are generally NOT specified in members of PARMLIB.
Instead the symbolic alias association (i.e. the DSN with embedded symbolics)
is specified in PARMLIB.
For example, PROGxx specifies $NT.NETVIEW .&NCNMVRL..SCNMLNK1
Implementation and regression is often possible by changing the values of the
symbols with SYMUPDTE and activating a new LNKLST.
Advantages:
Implementations and regressions do not require any changes to existing
executables (e.g. JCL and REXX)
The symbolic-relate aliases never need to be redefined (unless a
dataset is retired), even when the associated dataset moves to another volume
Disadvantages:
An extra one-time step to define them
SMP/E maintenance is NEVER done in place. A new set of target datasets
must be defined and a ZONEEDIT is required to change DDDEFs to point to the new
DSNs
I apologize in advance for any inaccuracies in the above. I'm busy today and I
was in a hurry. I nonetheless wanted to post because I believe symbolic-relate
aliases are worth the effort.
Cheers,
Alan
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of
McKown, John
Sent: Thursday, November 03, 2011 9:58 AM
To: [email protected]
Subject: do u? Use SYMBOLICRELATE?
I'm just curious about something. Does anybody use SYMBOLICREATE to create
aliases so that the actual DSN can automatically change based on a static
system symbol? I'm thinking about things such as version numbers or z/OS
&SYSNAME. Does anybody even have system relative DSNs? I'm thinking perhaps
like SYS2.&SYSNAME..PARMLIB with an alias of SYS2.SYSTEM.PARMLIB so that a job
can simply refer to SYS2.SYSTEM.PARMLIB and get the correct, system-specific,
PARMLIB. I'm trying to determine if it is actually useful. My manager likes for
product libraries to have the release/maintenance as a node in the DSN. But
this means that we need to make JCL changes when we upgrade. Or we need to put
the executable libraries in the LNKLST. We currently do the latter, but I don't
really care for it for "low use" products. But is it better to create a normal
ALIAS without the maintenance level and simply reDEFINE the alias when I
upgrade? Rather than change the IEASYMnn member of PARMLIB. Or just!
do it like we do now and require JCL changes so that the JCL itself documents
which version/maintenance level is desired?
This is coming up, in my mind only so far, because I plan to use UNIX sysplex
sharing and use something similar. I plan to have a system-specific version of
then /usr/local subdirectory. In order to simplify things, I'll use a symbolic
link with $SYSSYMR like:
cd /usr
mkdir SY1-local
mkdir SY2-local
ln -s '$SYSSYMR/&SYSNAME.-local' system-local
and then in /etc/profile, have:
export PATH=${PATH}:/usr/system-local/bin:/usr/local/bin
so that a system local version of a program will override the "global"
/usr/local version.
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
[email protected] * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
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
