Paul Gilmartin wrote:
A couple years ago, there was a thread here which advanced the
opinion that it is harmful for vendors to attempt to influence
the customers' choice of data set names for installation of
their products. Incredibly, one of the arguments was, "Well,
you gotta have standards so programmers know where to find
stuff!" You seem to have provided a PITA argument for uniformity.
I believe that ease of installation of "squatty box" products
arises from providing customers guidance in this area, and the
customers' willingness to follow that guidance. Further
benefits for the customer are easy interoperability of
products with less configuration labor, and for the vendors
greater market success.
Agreed. Clearly, if tz/OS was being designed ab initio, a standard data
set naming convention would probably be used. (Then again, in that case
there might not even be data sets as we know them!)
However, after so many decades, we can't expect customers to make
wholesale -- and costly -- "busy work" changes in their production
environments just to be consistent with others running z/OS (including
their competitors).
I don't see nearly as many configurations as a busy consultant like
Mark, But, I have noticed with our customers that the LLQ of
SMP/E-maintained, MVS "classic" data sets seems to always mirror the
DDDEF name in target zone. (In fact, I have *never* seen an exception to
this "rule" with data sets we deliver!) It's the HLQ(s) that seem to be
"fair game" for site-specific customization.
This observation led to the following idea, which I had previously
advanced only to a select few through verbal conversation:
Suppose static system symbols could be created automatically by SMP/E
(or an add-on program using the SMP/E API) for each DDDEF in the target
zone that references an MVS classic data set!
The first 20 symbols would be defined something like this (from my system):
SYMDEF(&BNJPNL1='NETV.BNJPNL1')
SYMDEF(&BNJPNL2='NETV.BNJPNL2')
SYMDEF(&BNJSRC1='NETV.BNJSRC1')
SYMDEF(&CBRDBRM='SYS1.CBRDBRM')
SYMDEF(&CIPLIB='SYS1.CIPLIB')
SYMDEF(&CMDLIB='SYS1.CMDLIB')
SYMDEF(&CNMCLST='NETV.CNMCLST')
SYMDEF(&CNMINST='NETV.CNMINST')
SYMDEF(&CNMLINK='NETV.CNMLINK')
SYMDEF(&CNMPNL1='NETV.CNMPNL1')
SYMDEF(&CNMSAMP='NETV.CNMSAMP')
SYMDEF(&COB2LIB='CALLLIBS.DUMMY')
SYMDEF(&CSSLIB='SYS1.CSSLIB')
SYMDEF(&DBBLIB='SYS1.DBBLIB')
SYMDEF(&DCFASM='SCRIPT.DCFASM')
SYMDEF(&DCFDIST='SCRIPT.DCFDIST')
SYMDEF(&DCFGML='SCRIPT.DCFGML')
SYMDEF(&DCFIMAGE='SCRIPT.DCFIMAGE')
SYMDEF(&DCFLOAD='SCRIPT.DCFLOAD')
SYMDEF(&DCFMAC='SCRIPT.DCFMAC')
SYMDEF(&DCFSAMP='SCRIPT.DCFSAMP')
SYMDEF(&DFQLLIB='SYS1.DFQLLIB')
SYMDEF(&DFQMLIB='SYS1.DFQMLIB')
SYMDEF(&DFQPLIB='SYS1.DFQPLIB')
SYMDEF(&DGTCLIB='SYS1.DFQLLIB')
SYMDEF(&DGTLLIB='SYS1.DGTLLIB')
SYMDEF(&DGTMLIB='SYS1.DGTMLIB')
SYMDEF(&DGTPLIB='SYS1.DGTPLIB')
SYMDEF(&DGTSLIB=SYS1.DGTSLIB')
.
. (there are hundreds and hundreds more))
.
The member containing these symbols could be concatenated with other,
existing IEASYMxx members in parmlib. Like other static system symbols,
these symbols would be created at IPL time and be available to all programs.
IBM- and ISV-distributed CLISTs, JCL, and other program elements that
reference these SMP/E-maintained target libraries could then refer to a
data set name by its symbolic name. For example, instead of specifying:
EX 'SYS1.SBLSCLI0(BLDCDDIR)' we would write something like: EX
'&SBLSCLI0.(BLSCDDIR)' And, backward compatibility would be
automatically maintained for existing programs that don't expect to be
updated in the near-term to take advantage of this new level of indirection.
Although static symbol substitution support is fairly pervasive in some
obvious places within z/OS, it is still missing from some other
equally-obvious places -- such as for the data set command operands in
these examples. Static symbol substitution for data set names would need
a thorough implementation for this scheme to work reliably. (Perhaps the
call to the substitution service should be made from within DYNALLOC
itself to minimize interface points.)
No matter the exact details of implementation, IMHO it would be time
well spent...
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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
