On Thu, 11 Dec 2014 15:35:08 -0800, Charles Mills wrote:
>
>> You can't have an alias of an alias
>
>I can see the analogy to PDSes. Only members can have aliases; aliases can't
>have aliases, right?
>
Gee. No matter how bad something is, if you can find something equally
bad or worse to compare it to, you can call it relatively good.
I can't see any analogy to UNIX symbolic links, which can chain up to
a system defined limit, easily exceeded, with no integrity harm:
user@HOST: ln -s foo bar
user@HOST: ln -s bar foo
user@HOST: ls -Ll foo
foo: Number of symbolic links encountered during path name traversal
exceeds MAXSYMLINKS
>> At job initiation, the initiator ENQs on the alias name. At allocation
>> it ENQs on the related DSN. If there's an ENQ conflict at that point,
>> the job terminates with a JCL error
>
>That sounds terrible. So you are saying that if a long-running job has an
>exclusive ENQ on FOO.BAR.ACTUAL, then every job that wants FOO.BAR.ALIAS
>will take off and run, and then fail at execution time? That sounds like a
>real step backwards. One of the features of OS/360 was "jobs don't run until
>all of the resources that they need are available."
>
Of course, this was broken first by DYNALLOC.
I suppose the expectation of the design is that users will use only the
alias in JCL, and that there won't be multiple aliases. And I wonder how
JES3, with its more sophisticated setup processing, deals with it.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
