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

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"

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

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=

Re: Question for COBOL users

: 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= // SET COBLIB=IGY.V5R2M0 // JC

Re: Question for COBOL users

=SYSOPTF in their JCL and not need to specify OPTFILE at all. From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tom Ross <tmr...@stlvm20.vnet.ibm.com> Sent: Tuesday, February 13, 2018 4:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject:

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

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

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

Re: Question for COBOL users

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

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

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

Re: Question for COBOL users

ter -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 w

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).

Re: Question for COBOL users

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

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

Re: Question for COBOL users

> 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 &g

Re: Question for COBOL users

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:

Re: Question for COBOL users

U] 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 f

Re: Question for COBOL users

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

Re: Question for COBOL users

, 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. T

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. >

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

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

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

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

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

Re: Question for COBOL users

- 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

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

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

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

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