Re: Question for COBOL users
On Fri, 16 Feb 2018 11:13:05 -0800, Tom Ross wrote: > >In response to other posts and Frank, I agree that we should answer the >RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD" > Yaaay! Now you may have to deal with, "But that's not the way we planned to do it." If PARMDD refers to a SYSIN it supports symbol substitution (almost) like EXEC PARM=. There are a few annoying differences. Of course, PARMDD may be a concatenation of library option members (like SYSOPTF). And someone suggested using DDNAME= for more flexibility (again, like SYSOPTF). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
>FWIW, I am guessing "255" was simply a brain-glitch for 100, and had no >basis in any actual technology. Charles, you nailed my brain fart exactly! In response to other posts and Frank, I agree that we should answer the RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD" 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
Re: Question for COBOL users
On Wed, 14 Feb 2018 13:52:35 -0600, Paul Gilmartin wrote: >I remain puzzled that a need with a solution as obvious as PARMDD >causes an RFE. I agree. The customer who wants the COBOL compiler to always use SYSOPTF could just as easily code PARMDD instead, and get the functionality that they requested. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Wed, 14 Feb 2018 11:41:31 -0800, Charles Mills wrote: >FWIW, I am guessing "255" was simply a brain-glitch for 100, and had no >basis in any actual technology. > On Tue, 13 Feb 2018 15:42:20 -0800, Tom Ross wrote: >... >Someone else asked what the COMPILER limit for reading the PARM= >options string is, but there is none. There is a JCL/JES limit of >255 bytes. There is no limit for SYSOPTF (using OPTFILE). > I remain puzzled that a need with a solution as obvious as PARMDD causes an RFE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
FWIW, I am guessing "255" was simply a brain-glitch for 100, and had no
basis in any actual technology.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Wednesday, February 14, 2018 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question for COBOL users
So I figured I'd test this, rather than just guessing or trying to remember
what is true.
//CLGO JOB ,'COMPILE/LINK/GO',NOTIFY=&SYSUID
// SET COBLIB=IGY.V5R2M0
// JCLLIB ORDER=(&COBLIB..SIGYPROC)
//*--*
//CLGO EXEC IGYWCLG,GOPGM=TEST1,
// LNGPRFX=&COBLIB,
//* PARM.COBOL='TEST',
//* PARM.LKED='LIST=NOIMP MAP XREF LET=0',
//* PARM.GO='THIS IS A TEST'
// PARMDD.COBOL=PARMS,
// PARMDD.LKED=PARMS,
// PARMDD.GO=PARMS
//COBOL.SYSIN DD *
ID DIVISION.
PROGRAM-ID. 'TEST1'.
PROCEDURE DIVISION.
DISPLAY 'TEST1'
STOP RUN.
END PROGRAM 'TEST1'.
//COBOL.PARMS DD *
TEST
RULES(ENDPERIOD,EVENPACK,LAXPERF,NOSLACKBYTES)
ARITH(EXTEND)
CODEPAGE(1047)
DLL
INITCHECK
PGMNAME(LONGMIXED)
NOADATA
NOADV
AFP(VOLATILE)
ARCH(9)
QUOTE
AWO
BLOCK0
BUFSIZE(3)
NOCICS
NOCOMPILE(S)
CURRENCY('Y')
DATA(31)
NODBCS
NSYMBOL(DBCS)
NODECK
NODIAGTRUNC
DISPSIGN(SEP)
NODUMP
NODYNAM
NOEXIT
NOEXPORTALL
NOFASTSRT
FLAG(W,W)
NOFLAGSTD
HGPR(PRESERVE)
INTDATE(ANSI)
/*
//LKED.PARMS DD *
LIST=NOIMP,
MAP,
XREF,
LET=0,
/*
//GO.PARMS DD *
THIS IS A TEST
/*
//GO.SYSOUT DD SYSOUT=*
//
Results:
PP 5655-W32 IBM Enterprise COBOL for z/OS 5.2.0
Date 02/14/2018 Time 11:30:16 Page 1
Invocation parameters:
TEST RULES(ENDPERIOD,EVENPACK,LAXPERF,NOSLACKBYTES) ARITH(EXTEND)
CODEPAGE(1047) DLL INITCHECK PGMNAME(LONGMIXED)
AFP(VOLATILE) ARCH(9) QUOTE AWO BLOCK0 BUFSIZE(3) NOCICS NOCOMPILE(S)
CURRENCY('Y') DATA(31) NODBCS NSYMBOL(DBCS) NODECK NODIAGTRUNC
DISPSIGN(SEP) NODUMP NODYNAM NOEXIT NOEXPORTALL NOFASTSRT FLAG(W,W)
NOFLAGSTD HGPR(PRESERVE) INTDATE(ANSI)
So I would say that the assertion that there is some limit of 255 characters
appears to not be true. The limit of 100 for PARM is still true, but using
PARMDD seems to allow more than 255, and I'm guessing up to whatever the
PARMDD limit is (32767?).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
So I figured I'd test this, rather than just guessing or trying to remember
what is true.
//CLGO JOB ,'COMPILE/LINK/GO',NOTIFY=&SYSUID
// SET COBLIB=IGY.V5R2M0
// JCLLIB ORDER=(&COBLIB..SIGYPROC)
//*--*
//CLGO EXEC IGYWCLG,GOPGM=TEST1,
// LNGPRFX=&COBLIB,
//* PARM.COBOL='TEST',
//* PARM.LKED='LIST=NOIMP MAP XREF LET=0',
//* PARM.GO='THIS IS A TEST'
// PARMDD.COBOL=PARMS,
// PARMDD.LKED=PARMS,
// PARMDD.GO=PARMS
//COBOL.SYSIN DD *
ID DIVISION.
PROGRAM-ID. 'TEST1'.
PROCEDURE DIVISION.
DISPLAY 'TEST1'
STOP RUN.
END PROGRAM 'TEST1'.
//COBOL.PARMS DD *
TEST
RULES(ENDPERIOD,EVENPACK,LAXPERF,NOSLACKBYTES)
ARITH(EXTEND)
CODEPAGE(1047)
DLL
INITCHECK
PGMNAME(LONGMIXED)
NOADATA
NOADV
AFP(VOLATILE)
ARCH(9)
QUOTE
AWO
BLOCK0
BUFSIZE(3)
NOCICS
NOCOMPILE(S)
CURRENCY('Y')
DATA(31)
NODBCS
NSYMBOL(DBCS)
NODECK
NODIAGTRUNC
DISPSIGN(SEP)
NODUMP
NODYNAM
NOEXIT
NOEXPORTALL
NOFASTSRT
FLAG(W,W)
NOFLAGSTD
HGPR(PRESERVE)
INTDATE(ANSI)
/*
//LKED.PARMS DD *
LIST=NOIMP,
MAP,
XREF,
LET=0,
/*
//GO.PARMS DD *
THIS IS A TEST
/*
//GO.SYSOUT DD SYSOUT=*
//
Results:
PP 5655-W32 IBM Enterprise COBOL for z/OS 5.2.0 Date
02/14/2018 Time 11:30:16 Page 1
Invocation parameters:
TEST RULES(ENDPERIOD,EVENPACK,LAXPERF,NOSLACKBYTES) ARITH(EXTEND)
CODEPAGE(1047) DLL INITCHECK PGMNAME(LONGMIXED)
AFP(VOLATILE) ARCH(9) QUOTE AWO BLOCK0 BUFSIZE(3) NOCICS NOCOMPILE(S)
CURRENCY('Y') DATA(31) NODBCS NSYMBOL(DBCS) NODECK
NODIAGTRUNC DISPSIGN(SEP) NODUMP NODYNAM NOEXIT NOEXPORTALL NOFASTSRT
FLAG(W,W) NOFLAGSTD HGPR(PRESERVE) INTDATE(ANSI)
So I would say that the assertion that there is some limit of 255 characters
appears to not be true. The limit of 100 for PARM is still true, but using
PARMDD seems to allow more than 255, and I'm guessing up to whatever the PARMDD
limit is (32767?).
Would this be a way to satisfy the need for this RFE? They could do
PARMDD=SYSOPTF in their JCL and not need to specify OPTFILE at all.
From: IBM Mainframe Discussion List on behalf of Tom
Ross
Sent: Tuesday, February 13, 2018 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question for COBOL users
We added OPTFILE as a response to customer request, I believe it was
well before PARMDD, but not positive.
Someone else asked what the COMPILER limit for reading the PARM=
options string is, but there is none. There is a JCL/JES limit of
255 bytes. There is no limit for SYSOPTF (using OPTFILE).
It seems pretty clear that we cannot change the default behavior to
read SYSOPTF whenever it is present, regardless of OPTFILE, so we
will probably add another (sigh) compiler option
>There is nothing to prevent a user or product to go ahead and use
>PARMDD, and it could point to the program's (compiler's) specific
>overrides. The program (compiler) can only read the PARM for the
>length it specifies (100/255) until modified to allow a parm length of
>32K. Maybe a couple releases down the road you can give a warning
>message that the program (compiler) specific parm will be removed.
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
Re: Question for COBOL users
On Tue, 13 Feb 2018 20:00:47 -0600, Jim Ruddy wrote: >Wouldn't a 64K byte parameter list run into problems with programs such as >HLASM, compilers, and other programs which allow an optional DD name list to >be passed as a second parameter when invoked from a program? As I recall, they >detect whether the DD name list is passed by testing the high bit - the "sign" >bit - of the first parameter. > No, they test the high bit of the *address* of the first parameter. (VL is not supported in 64-bit mode.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
Nevermind - wrong bit - been too long and too long of a day. Sorry. Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
Wouldn't a 64K byte parameter list run into problems with programs such as HLASM, compilers, and other programs which allow an optional DD name list to be passed as a second parameter when invoked from a program? As I recall, they detect whether the DD name list is passed by testing the high bit - the "sign" bit - of the first parameter. Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Tue, 13 Feb 2018 17:46:28 -0800, Charles Mills wrote:
>And no real reason a program could not support 64ki-1 bytes. Not looking at
>the specs for "standard linkage" but there is no real good reason to treat the
>length as signed.
>
Tradition? ("real good reason"?)
A while ago, I experimented.
BPXBATCH reasonably processes x''.
Rexx address LINKMVS considers >=x'8000' a syntax error.
HLASM reasonably processes x'7FFF'. At x'8000' it issues several hundred
thousand
lines of error messages then program checks. Ugh! Sign extension?
BPXWDYN reasonably processes X'37FF'. At x'4000' it fails, expecting a
null-terminated
string rather than a CALL-style parm. This has been documented as a
restriction ever
since my RCF. The reporting is not ideal.
>Beyond that would require a significant change in the linkage.
>
Yes.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
And no real reason a program could not support 64ki-1 bytes. Not looking at the specs for "standard linkage" but there is no real good reason to treat the length as signed. Beyond that would require a significant change in the linkage. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 13, 2018 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question for COBOL users On Wed, 14 Feb 2018 00:00:10 +, Farley, Peter x23353 wrote: > >PMFJI here but the limit with PARMDD is 32K I believe. JES/JCL limit is 100, >not 255. The COBOL questions is, does the compiler correctly process PARMDD >input > 255 characters, and if so which version(s)? Only V5+? I could >understand V4 not supporting it, but not V5+. > This is hardly such a novelty: for a half-century the Assembler CALL/LINK/ATTACH macro could invoke the compiler with up to 32Ki-1 bytes in PARM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross wrote: >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! << We use OPTFILE to supply Compiler defaults. We specify it as the first parm to the Compiler and then specify any options we want to override or options that are not in the defaults after OPTFILE. Since we always use OPTFILE, we always have a SYSOPTF DD statement supplied also so we would be OK with this change. However, I see the following statements in the COBOL Programming Guide: The precedence of options in the SYSOPTF data set is determined by where you specify the OPTFILE option. For example, if you specify OPTFILE in the invocation PARM string, an option specified later in the PARM string supersedes any option specified in the SYSOPTF data set that conflicts with it. (Conceptually, OPTFILE in an options specification is replaced with the options that are in the SYSOPTF data set; then the usual rules about precedence of compiler options and conflicting compiler options apply.) This seems to imply that options specified as Compiler Parms before OPTFILE could be overridden by options in SYSOPTF. If that's the case and COBOL was changed to always use SYSOPTF, would the options in SYSOPTF be processed before any Parm options or after all Parm options? I see in your latest posting that you will probably need to add a new Compiler option. The manual also says that OPTFILE cannot be set as an installation default option. Maybe if it was allowed to be an installation default, that would satisfy the RFE? Maybe with an additional parameter for an installation default to specify when SYSOPTF is to processed, first or last? -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Wed, 14 Feb 2018 00:00:10 +, Farley, Peter x23353 wrote: > >PMFJI here but the limit with PARMDD is 32K I believe. JES/JCL limit is 100, >not 255. The COBOL questions is, does the compiler correctly process PARMDD >input > 255 characters, and if so which version(s)? Only V5+? I could >understand V4 not supporting it, but not V5+. > This is hardly such a novelty: for a half-century the Assembler CALL/LINK/ATTACH macro could invoke the compiler with up to 32Ki-1 bytes in PARM. >-Original Message- >From: Behalf Of Tom Ross >Sent: Tuesday, February 13, 2018 6:42 PM > >We added OPTFILE as a response to customer request, I believe it was >well before PARMDD, but not positive. > >Someone else asked what the COMPILER limit for reading the PARM= >options string is, but there is none. There is a JCL/JES limit of >255 bytes. There is no limit for SYSOPTF (using OPTFILE). > I'm sticking with the consensus of 100 bytes. But do you mean that CALL, etc. can invoke COBOL with the much longer PARM? That this has been true for many releases? >It seems pretty clear that we cannot change the default behavior to >read SYSOPTF whenever it is present, regardless of OPTFILE, so we >will probably add another (sigh) compiler option > In your first ply you said that the motivation was that the requestor was too close to the (255?) 100-character limit to accommodate one more option, so a different option provides no relief. (Well, minimal, insofar as it's shorter than the 7 characters in "OPTFILE".) Has PARMDD been suggested to the requestor? AFAICT, the only distinction between EXEC PARM= and PARMDD is that the latter can not end with a blank. PARMDD should provide the solution; the RFE should be rejected. >On Mon, 12 Feb 2018 12:08:16 -0600, Mike Schwab wrote: [ Header synthesized -- gil] >>There is nothing to prevent a user or product to go ahead and use >>PARMDD, and it could point to the program's (compiler's) specific >>overrides. The program (compiler) can only read the PARM for the >>length it specifies (100/255) until modified to allow a parm length of >>32K. Maybe a couple releases down the road you can give a warning >>message that the program (compiler) specific parm will be removed. Tom has said COBOL has no such limit, so no problem. The JCL limit is unlikely to change (although that should have been done long ago.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
Tom, PMFJI here but the limit with PARMDD is 32K I believe. JES/JCL limit is 100, not 255. The COBOL questions is, does the compiler correctly process PARMDD input > 255 characters, and if so which version(s)? Only V5+? I could understand V4 not supporting it, but not V5+. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Tuesday, February 13, 2018 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question for COBOL users We added OPTFILE as a response to customer request, I believe it was well before PARMDD, but not positive. Someone else asked what the COMPILER limit for reading the PARM= options string is, but there is none. There is a JCL/JES limit of 255 bytes. There is no limit for SYSOPTF (using OPTFILE). It seems pretty clear that we cannot change the default behavior to read SYSOPTF whenever it is present, regardless of OPTFILE, so we will probably add another (sigh) compiler option >There is nothing to prevent a user or product to go ahead and use >PARMDD, and it could point to the program's (compiler's) specific >overrides. The program (compiler) can only read the PARM for the >length it specifies (100/255) until modified to allow a parm length of >32K. Maybe a couple releases down the road you can give a warning >message that the program (compiler) specific parm will be removed. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
We added OPTFILE as a response to customer request, I believe it was well before PARMDD, but not positive. Someone else asked what the COMPILER limit for reading the PARM= options string is, but there is none. There is a JCL/JES limit of 255 bytes. There is no limit for SYSOPTF (using OPTFILE). It seems pretty clear that we cannot change the default behavior to read SYSOPTF whenever it is present, regardless of OPTFILE, so we will probably add another (sigh) compiler option >There is nothing to prevent a user or product to go ahead and use >PARMDD, and it could point to the program's (compiler's) specific >overrides. The program (compiler) can only read the PARM for the >length it specifies (100/255) until modified to allow a parm length of >32K. Maybe a couple releases down the road you can give a warning >message that the program (compiler) specific parm will be removed. 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
Re: Question for COBOL users
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
you wrote:
> Nothing like a bit of (in)consistency between the compilers! I like the PL/I
> option.
>
> From: IBM Mainframe Discussion List on behalf of
> Robert Prins
> 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-5637Cary, NC 27513
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Mon, 12 Feb 2018 12:08:16 -0600, Mike Schwab wrote: >There is nothing to prevent a user or product to go ahead and use >PARMDD, and it could point to the program's (compiler's) specific >overrides. The program (compiler) can only read the PARM for the >length it specifies (100/255) until modified to allow a parm length of >32K. Maybe a couple releases down the road you can give a warning >message that the program (compiler) specific parm will be removed. > Where is the COBOL compiler's limit on PARM length documented? In view of the wealth of options available in COBOL even 255 (which an earlier ply in this thread suggested was an error) seems uncomfortably small. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
There is nothing to prevent a user or product to go ahead and use
PARMDD, and it could point to the program's (compiler's) specific
overrides. The program (compiler) can only read the PARM for the
length it specifies (100/255) until modified to allow a parm length of
32K. Maybe a couple releases down the road you can give a warning
message that the program (compiler) specific parm will be removed.
On Mon, Feb 12, 2018 at 11:49 AM, Frank Swarbrick
wrote:
> Nothing like a bit of (in)consistency between the compilers! I like the PL/I
> option.
>
> From: IBM Mainframe Discussion List on behalf of
> Robert Prins
> 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.
>>
>> --
>> 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
Nothing like a bit of (in)consistency between the compilers! I like the PL/I
option.
From: IBM Mainframe Discussion List on behalf of
Robert Prins
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.
>
> --
> 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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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.
--
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
Re: Question for COBOL users
You could fake what you want and/or work around the proposed IBM change by
using DDNAME and a symbol, right?
// SET OPTF=SQLOPTS or one of the other names below
//* Or could be a parm on the PROC invocation
...
//SYSOPTF DD DDNAME=&OPTF
//SQLOPTS DD ...
//OPTCOMP DD ...
//DEBUGCMP DD ...
//NOOPTS DD DUMMY
Charles
-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.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
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.
Charles
-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.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Fri, 9 Feb 2018 23:23:15 +, Frank Swarbrick wrote: > >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. > Good idea. Best might be the list of DDNAMEs, although that could be accomplished by JCL DD concatenation. >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. > I thought the objective of the RFE was to circumvent the 100-byte JCL PARM limit. Doesn't PARMDD suffice for that? I'd be inclined to reject the RFE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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.
Or something...
From: IBM Mainframe Discussion List on behalf of Tom
Ross
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
Re: Question for COBOL users
On Wed, Feb 7, 2018 at 9:18 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 6 Feb 2018 16:42:54 -0600, Paul Gilmartin wrote: > >>I see no mention there of a "255 character limit". Am I looking in the wrong >>place? > > The limit on PARM is 100 characters, as you noted in an earlier append. > Tom made a mistake. > >>Why not simply relax the 100 (255?) character limit on JCL PARM? > > This has been discussed at length here. Let's not do it again, please. > > -- > Tom Marchant PARMDD gives you 32KiB -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Tue, 6 Feb 2018 16:42:54 -0600, Paul Gilmartin wrote: >I see no mention there of a "255 character limit". Am I looking in the wrong >place? The limit on PARM is 100 characters, as you noted in an earlier append. Tom made a mistake. >Why not simply relax the 100 (255?) character limit on JCL PARM? This has been discussed at length here. Let's not do it again, please. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross wrote: > >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. > Doesn't IBM reserve DDNAMES beginning with "SYS" for IBM's own use? If so, then unless IBM makes an affirmative statement that with NOOPTFILE SYSOPTF is ignored, IBM should be free to take any action whatever with that DDNAME. I know a precedent where IBM changed behavior of a DDNAME with no previous meaning. If IBM strives for minimum disruption, even of nonconforming use, choose a different DDNAME, say SYSOPTX, and specifi that: o With OPTFILE, SYSOPTF supplies options. o With NOOPTFILE, SYSOPTF is ignored, but if SYSOPTX appears in the job step, that DDNAME supplies options. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
PARM='GROUNDHOG DAY' Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, February 6, 2018 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question for COBOL users You must keep reinventing the wheel until you get it right. Meanwhile no dessert for you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
You must keep reinventing the wheel until you get it right. Meanwhile no dessert for you. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 06, 2018 2:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Question for COBOL users On Tue, 6 Feb 2018 17:11:08 -0200, Paulo Roberto Leonardo Pereira wrote: > >Look at this > >https://www.ibm.com/support/knowledgecenter/en/SSR27Q_4.0.7/com.ibm.rat >ional.rtc.rdz.doc/topics/rdzrtcz_int_user_build_jcl.html > I see no mention there of a "255 character limit". Am I looking in the wrong place? > >Em 06/02/2018 17:02, Paul Gilmartin escreveu: > >> On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross wrote: >> >>> For background, this is where you can avoid the 255 character limit >>> for PARM= in JCL when specifying COBOL compiler options. ... >> In what context does PARM= have a 255 character limit. I had always >> thought it was 100. >> >> But doesn't PARMDD provide a (cumbersome) circumvention? On Tue, 6 Feb 2018 17:01:29 -0500, Steve Smith wrote: >Really? What kind of "business requirement" is behind that? In any >case, I could only vote "who cares?" > Yup. >I am sure that there are plenty of potential objections, but it seems >to me that HLASM, Binder, and compilers should just drop their >individual parm DD support, and have them all just go with PARMDD. > How many times must this wheel be reinvented? >I don't see that PARMDD is cumbersome, certainly no more than keeping >up with multiple ways to accomplish it. > Why not simply relax the 100 (255?) character limit on JCL PARM? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Tue, 6 Feb 2018 17:11:08 -0200, Paulo Roberto Leonardo Pereira wrote: > >Look at this > >https://www.ibm.com/support/knowledgecenter/en/SSR27Q_4.0.7/com.ibm.rational.rtc.rdz.doc/topics/rdzrtcz_int_user_build_jcl.html > I see no mention there of a "255 character limit". Am I looking in the wrong place? > >Em 06/02/2018 17:02, Paul Gilmartin escreveu: > >> On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross wrote: >> >>> For background, this is where you can avoid the 255 character limit for >>> PARM= in JCL when specifying COBOL compiler options. ... >> In what context does PARM= have a 255 character limit. I had always >> thought it was 100. >> >> But doesn't PARMDD provide a (cumbersome) circumvention? On Tue, 6 Feb 2018 17:01:29 -0500, Steve Smith wrote: >Really? What kind of "business requirement" is behind that? In any case, >I could only vote "who cares?" > Yup. >I am sure that there are plenty of potential objections, but it seems to me >that HLASM, Binder, and compilers should just drop their individual parm DD >support, and have them all just go with PARMDD. > How many times must this wheel be reinvented? >I don't see that PARMDD is cumbersome, certainly no more than keeping up >with multiple ways to accomplish it. > Why not simply relax the 100 (255?) character limit on JCL PARM? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
Really? What kind of "business requirement" is behind that? In any case, I could only vote "who cares?" I am sure that there are plenty of potential objections, but it seems to me that HLASM, Binder, and compilers should just drop their individual parm DD support, and have them all just go with PARMDD. I don't see that PARMDD is cumbersome, certainly no more than keeping up with multiple ways to accomplish it. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
Hi Look at this https://www.ibm.com/support/knowledgecenter/en/SSR27Q_4.0.7/com.ibm.rational.rtc.rdz.doc/topics/rdzrtcz_int_user_build_jcl.html Em 06/02/2018 17:02, Paul Gilmartin escreveu: > On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross wrote: > >> For background, this is where you can avoid the 255 character limit for >> PARM= in JCL when specifying COBOL compiler options. ... > In what context does PARM= have a 255 character limit. I had always > thought it was 100. > > But doesn't PARMDD provide a (cumbersome) circumvention? > > -- gil > > -- > 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
Re: Question for COBOL users
On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross wrote: > >For background, this is where you can avoid the 255 character limit for >PARM= in JCL when specifying COBOL compiler options. ... > In what context does PARM= have a 255 character limit. I had always thought it was 100. But doesn't PARMDD provide a (cumbersome) circumvention? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
