Exactly. DD's were invented as a method of virtualizing dataset references. You can write a program to read and write FILEIN, and later someone can decide FILEIN is really SYS1.FOOBAR.DATA. They were invented specifically to AVOID having every language or every application program need to devise a way of determining the name of the files to process. Remember the post here a week or two ago "how do I modify a program to make a fixed tax rate into a parameter?" Imagine if every program were coded to process some specific dataset name and had to be modified to process another dataset, or if every program had a unique and local way of accepting one or more dataset names as a parameter.
As Gil, says, the designers missed the mark, slightly. Entry and return is not unique: it's same for a jobstep program, a called program, or a subtask (unlike in VSE, IIRC). PARM= is not unique: I can ATTACH a program and make it think it is seeing PARM= data. But DD's are unique: there is only one FILEIN per address space. Charles <snip> 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
