I haven't encountered a situation where I wanted to run two invocations of a utility concurrently, and I have no problem with using a ddname list should I ever need concurrent utilities. Changing Allocation to support multiple TIOTs within a jobstep would be a massive undertaking, and I can't conceive of a plausible business case.
SVC screening seems like overkill; I would expect a subsystem to be far less fragile. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Wednesday, October 23, 2019 2:54 PM To: [email protected] Subject: Re: Is there a TSO equivalent to JCL DDNAME=? On Wed, 23 Oct 2019 17:34:37 +0000, Seymour J Metz wrote: >I agree that IBM should provide a means to dynamically assign an alias to a >ddname, but IMHO ATTACH is the wrong place to do it. DYNALLOC would seems to >be the obvious place to do it. > An imporrtant use of alternate DDNAMEs is avoiding DDNAME conflicts: concurrently running two utilities both coded to use (e.g.) SYSUT1, but with different data sets allocated, perhaps to generated names. I don't see how this can be accomplished with DYNALLOC aliasing. I'd welcome an enlightening example. The value is greater if the "aliasing" is invisible to the ATTACHed/LINKed subprogram. >In the meantime, it is a SMOP to write a subsystem to redirect the I/O. I >don't recall the file, but on the CBT there is a subsystem to allow utilities >that do not support Wylbur compressed data sets to access them transparently. > Long ago someone posted here that he had accomplished (but not entirely) DDNAME aliasing with SVC screening. >DDNAME= is implemented in the C/I; there should be no need for Initiator >involvement. > I'll stand corrected. In any case, before the job step program gets control. ________________________________________ From: Paul Gilmartin Sent: Wednesday, October 23, 2019 11:20 AM ... It's regrettable that alternate DDNAME requires each program to code for it rather than being a part of ATTACH and transparent to the ATTACHed program. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
