A single DD still allows for site defaults and user overrides. Just use concatenated datasets. Of course, it's up to the program to decide if duplicates are honored if specified first vs. last.
In article <cy1pr05mb1993c192cfc179f40523072be4...@cy1pr05mb1993.namprd05.prod.outlook.com> you wrote: > Nothing like a bit of (in)consistency between the compilers! I like the PL/I > option. > ________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Robert Prins <robert.ah.pr...@gmail.com> > Sent: Saturday, February 10, 2018 6:14 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Question for COBOL users > On 2018-02-10 00:30, Charles Mills wrote: > > That is how the C/C++ compiler works. PARM='OPTF(DD:SYSOPTF)' or any other > > valid DD name, or DSN, or zFS name. Only one name, though. > Enterprise PL/I allows multiple DD names, like: > //IBMZPLI EXEC PGM=IBMZPLI, > // REGION=0M, > // PARM=('+DD:PLISTD +DD:PLIDB2 +DD:PLCICS +DD:PLIUSER') > which allows a site to set up defaults, but still giving the user a chance to > override things. Works like a charm! > =DD:PLISTD could be set up to point to the IBMXOnnn members now conveniently > added to the hlq.SIBMZSAM dataset containing such members for all still > supported versions of Enterprise PL/I, an RFE > <https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=80836> > yours truly suggested and that was implemented with EPLI V5.1.0 > And for what it's worth, a SuperC compare of the various members will also > show > all options that have been altered/added with every release of EPLI. > Robert > -- > Robert AH Prins > robert.ah.prins(a)gmail.com > Some programming @ <https://prino.neocities.org/zOS/zOS%20Tools.html> > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Frank Swarbrick > > Sent: Friday, February 9, 2018 3:23 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Question for COBOL users > > > > Our shop currently uses OPTFILE in conjunction with the SQL compiler option > > in order to supply particular SQL "compile" options to the SQL precompiler > > for those COBOL program that have EXEC SQL statements. This allows us to 1) > > avoid having a separate "DB2 batch" and "DB2 CICS" procs. We simply use our > > "standard" batch and CICS compile procs, and the SQL preprocessor is invoked > > if the source code has "PROCESS SQL OPTFILE" at the top. Our "SYSOPTF" has > > the following: > > SQL('STDSQL(YES) SQL(ALL) VERSION(AUTO)') > > > > So the change that you suggest would indeed "break" our environment. Well, > > perhaps not, because I don't think it would do any harm to supply SQL > > options for programs that don't have any SQL statements, but... > > > > My personal wish would be that OPTFILE have an option to specify one or more > > DD names that it would open, rather than SYSOPTF being the only name. If > > that had been available we'd probably use OPTFILE(DB2OPTF) or some such > > thing. Of course that doesn't really solve your particular RFE. Sounds > > like you need a new compiler option that tells the compiler to use SYSOPTF > > if present, but only if the new option is specified. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN