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.
Or something...
________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tom
Ross <tmr...@stlvm20.vnet.ibm.com>
Sent: Tuesday, February 6, 2018 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question for COBOL users
IBM COBOL development needs your help!
We are reviewing a request to change our support for OPTFILE and SYSOPTF
to allow usage of DD SYSOPTF without the compiler option OPTFILE.
For background, this is where you can avoid the 255 character limit for
PARM= in JCL when specifying COBOL compiler options. Currently, if you
specify compiler option OPTFILE, the compiler tries to OPEN the file
allocated to DD SYSOPTF, and read compiler options from that file.
OK, we got an RFE (Request For Enhancement) to have the compiler always
try to use SYSOPTF, with or without the OPTFILE compiler option. The use
of SYSOPTF would then only be controlled by the existence of SYSOPTF.
Our concern is, would this affect current users of SYSOPTF? Are there users
of SYSOPTF with COBOL who sometimes compile with NOOPTFILE and leave the
DD statement for SYSOPFT in their JCL/Changeman compile jobs?
If so, then automatically accessing SYSOPTF without using OPTFILE could
cause problems.
This leads to another question...do any of your shops use OPTFILE and
SYSOPTF for COBOL compiles?
Cheers,
TomR >> COBOL is the Language of the Future! <<
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
