COBOL does NOT demand a DSNAME. It is perfectly happy with DDNAMEs. There were extensions to COBOL to allow a DSNAME via a system variable by playing with the SELECT statement.
Of course, one could ask if the dsname is already in a system variable, why not supply it in the JCL. But I digress. On Sat, 29 Apr 2023 08:58:36 -0500 Paul Gilmartin <0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: :>On Fri, 28 Apr 2023 19:37:39 +0000, Schmitt, Michael wrote: :> :>>I know how to have a COBOL program on z/OS use a data set name that isn't determined until runtime, via an environment variable. My question is can you use one file (i.e. one select/assign and one FD) to write to different DD names, that were already allocated in the JCL? :>> :>When I wear my ill-fitting MVS hat, I find it bizarre that any HLL is :>DDNAME-ignorant. It's what most of them require. Think EXECIO. :>But COBOL ... :> :>A DDNAME is a component of I/O abstraction, a handle for a data set, :>analogous to the way in UNIX that a descriptor is a handle for a :>pathname. And some UNIX utilities accept only pathnames, not :>descriptors. But UNIX-like systems that I nave used, Solaris, Linux, :>MacOS, OMVS, provide a pseudo-mountpoint, "/dev/fd/" to treat a :>descriptor as a pathname. This is not required by POSIX. :>For example: :> exec 42</etc/services :> wc /dev/fd/42 :>... just works. :> :>A modest proposal: Wouldn't it be nice if z/OS provided a pseudo-HLQ :>such as "DDHLQ.<ddname>" to meet the requirements of languages :>such as COBOL which demand a DSN, not a DDNAME, so given :>SYSUT42 a program could form "DSN=DDHLQ.SYSUT42", look it up :>in the catalog, OPEN, and read it. :> :>RFE, anyone? -- Binyamin Dissen <bdis...@dissensoftware.com> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
