On 2017-01-10, at 17:46, David W Noon wrote: > ... > But we are really discussing COBOL ... > John M. started this thread using COBOL only as an example. He clearly envisioned, even as in the Subject: a system layer enhancement, not compiler, not application.
I echoed agreement. Charles M. followed with FTP as an example. FTP is probably not written in COBOL but contains hard-coded DDNAMES. If this is a COBOL thread it has been much hijacked. >> It's dreadfully wasteful for each application program that needs the facility >> to duplicate the code to process the alternate DDNAME list. > > What list? I am suggesting that any DDNAME that cannot be specified at > design time be made parametric. That is all that COBOL needs to handle > dynamic DDNAMEs. > And other langaages? A vast number of applications have hard-coded DDNAMES. Implementing the parameterization in the system layer would spare making code changes in each. There's some irony here. It appears to me that DDNAMEs were invented as a form of parameterization: they spare application programs the need to be aware of DSN, VOL, UNIT, SPACE, etc. As such, DDNAMEs work splendidly in a uniprocessing context and fail miserably in a multiprocessing context. Consider Charles's FTP example. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
