----------------------<snip>----------------------
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).
-------------------<unsnip>--------------------
Changes "by attrition" might work, if you could show a tangible benefit.
---------------------<snip>-----------------
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.
---------------------<unsnip>-----------------
Guilty as charged. I did it for security adminstration reasons, mostly.
And a select few used HLQ's that we already had in use for other purposes.
---------------------<snip>-------------------
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...
------------------------<unsnip>--------------------
Ed, I agree with the concept. But the implementation will be
horrendously expensive. Just providing efficient access to those symbols
across all the "environments" that would need it could be a massive
undertaking. And getting all the ISV's aboard will be nigh-unto
impossible unless you can show them a real benefit on the balance
sheets. THEN you've got to teach the customers how to use it to their
best advantage. GOOD LUCK!!!
----------------------------------------------------------------------
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
