In a recent note, Bruce Hewson said:
> Date: Sat, 21 Apr 2007 01:14:20 -0500
>
> >o So, may I conclude that symbolic DSNAME aliases must not be employed
> > in batch JCL?
>
> Incorrect. SYMBOLICRELATE aliases are the perfect method to make use of
> System Symbols in batch jobs.
>
Well, perceptibly less than perfect, in my judgment:
o This restricts their use to data set name components and excludes other
potential uses, such as in PARM and IF operands.
o z/OS isn't very comfortable with aliases, and this infects users, I infer
from recent contributions to this list. Point of discomfort:
Menu Options View Utilities Compilers Help
------------------------------------------------------------------------------
DSLIST - Data Sets Matching user.TEST.WHEN Data set not cataloged
Command - Enter "/" to select action Message Volume
-------------------------------------------------------------------------------
I user.TEST.WHEN *ALIAS
user.TEST.WHEN.D070420 TSO023
***************************** End of Data Set list ****************************
'user.TEST.WHEN' was not found in catalog.
Command ===> Scroll ===> CSR
... That's just plain false. 'user.TEST.WHEN' was found in the catalog;
that's the only reason it appears in DSLIST. In fact, what wasn't found
was the RELATED name. It would be far more useful if the offending RELATED
name rather than the benign ALIAS name appeared in the message. I can't
even find a way in either ISPF or batch messages to cause the RELATED name
of an unresolved symbolic alias to be displayed.
o By experiment, symbolic aliases work well for existing RELATED data sets
(DISP=OLD or DISP=SHR); they're pretty much useless for NEW data sets
(and that's the form of the most frequently asked question, "How can
I create a data set incorporating the current date in its name?")
In fact, when I try DISP=(MOD,CATLG) and the RELATED data set does not
exist, the job creates a data set with the ALIAS name in the VTOC and
gets NOT CATLGD 2 when it attempts to re-catalog it under the ALIAS
name. That just doesn't feel right: the RELATED name should be the one
that goes in the VTOC, then that should be the one in the new catalog
entry.
Regardless, this appears to refute the rationale repeatedly given for not
supporting the use of system symbols in batch JCL, viz. that the resolved
name must be known early, perhaps by the Converter, or by the JES3 scheduler
(I haven't tested on a JES3 system); at least at job initiation to issue
ENQs. If that rationale doesn't serve to prohibit system symbols in symbolic
aliases, it is likewise invalid rationale for prohibiting their use overtly
in JCL.
> Whereas an ALIAS using RELATE can only be created when the target dataset
> catalog entry exists, the ALIAS with SYMBOLICRELATE will always be created.
> I assume this difference in code path is the reason they chose to use a new
> keyword.
>
.. And ought to be rationale for allowing the SYMBOLIC relate keyword even
when the related name contains no substitutable symbols. I've been told
(only informally, not yet in a PMR I may create) that this is WAD.
> I haven't tested SYMBOLICRELATE alias entries with date or time variables.
>
&YYMMDD works. My fingers aren't fast enough to generate a valid test of
&HHMMSS.
And, I wonder when the binding happens:
o Job initiation?
o Step initiation and allocation?
o OPEN?
o Other (specify)?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
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
