On Wed, 14 Feb 2018 00:00:10 +0000, 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

Reply via email to