, December 16, 2006 4:32 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: COBOL compiler options JCL PARM.
To the best of my knowledge, no current or (relatively recently
past, i.e. OS/VS COBOL or later) compiler has created object
code that truncates passed parameters to called subprograms.
It *IS* true
Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Steve Comstock
Sent: 14 December 2006 13:23
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Everybody wants to be king [or queen]. But there are always
cases where the supplied defaults are not the right values
for a situation. My
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Of Chris Mason
Sent: Tuesday, December 12, 2006 10:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Charles
Reading the posts in this thread I sometimes get
Jan MOEYERSONS [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I actually look after the change management software and am trying to
snip
As an ex-change management person, I have to recommend you do not do that
and indeed that you prohibit your programmers from using the CBL
I actually look after the change management software and am trying to
Ahh well, I will make sure all the opts are abbreviated and recommend to
our programmers that they use the CBL statement in their source for any
extra options they might want to add.
As an ex-change management person, I
Jan MOEYERSONS wrote:
I actually look after the change management software and am trying to
Ahh well, I will make sure all the opts are abbreviated and recommend to
our programmers that they use the CBL statement in their source for any
extra options they might want to add.
As an
In a recent note, Chris Mason said:
Date: Thu, 14 Dec 2006 05:52:00 +0100
http://publibz.boulder.ibm.com/bookmgr/pictures/iea2a660.p1z.gif
quote
For a good example of how your primary mode programs can pass parameters,
consider the way the system uses a register to pass
On the other hand if change control changes code in any way they become
responsible for the results.
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 12/14/2006
04:31:46 AM:
As an ex-change management person, I have to recommend you do not do
that
and indeed that you prohibit
compiler options JCL PARM.
In a recent note, Chris Mason said:
Date: Thu, 14 Dec 2006 05:52:00 +0100
http://publibz.boulder.ibm.com/bookmgr/pictures/iea2a660.p1z.gif
quote
For a good example of how your primary mode programs can pass
parameters,
consider the way the system
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Ray Mullins
Sent: 12 December 2006 17:19
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Having been down this path before in a galaxy far, far away:
Because you can have multiple
: Tuesday, December 12, 2006 10:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Charles
Reading the posts in this thread I sometimes get the impression that this
100 character limit is being regarded as a convention rather than an
absolute limit. Maybe it's because the PG
Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Chris Mason
Sent: Tuesday, December 12, 2006 10:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Charles
snip
Which is a slightly complicated way of saying that, by the time the
program
In a recent note, Charles Mills said:
Date: Wed, 13 Dec 2006 06:50:24 -0800
WHY would the COBOL compiler behave this way? Perhaps to assure consistent
results whether loaded as a jobstep program or from a calling program. (I
disagree with the design decision.)
I concur with your
In a message dated 12/13/2006 9:30:37 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
And there's no concern of consistency -- there's no need to make
the behavior of the compiler when called from a program passing
PARM100 characters consistent with its behavior when loaded as
20+ years ago...)
Later,
Ray
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Nuttall, Peter [CCC-OT_IT]
Sent: Wednesday December 13 2006 00:31
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Many thanks Ray,
I may
R$ay,
I have worked in several different environments.
1 They would not allow programmers write their own procs.
2 If programmers did write their own then it was unsupported by TS
3 Programmers had to use the procs provided by TS, even vendor
supplied compile type procs had to be signed off by
-
From: Charles Mills [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Wednesday, 13 December, 2006 4:18 PM
Subject: Re: COBOL compiler options JCL PARM.
[1] In which manual is this documented these days?
It's in the Assembler Service Guide, which is where I
Hi All,
Enterprise COBOL compiler v3.4.
Am pretty sure someone else must have hit this. I have hit the 100 char (I
think ?) limit for the opts passed to the compiler via the Parm setting in the
JCL.
For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' in
the JCL and
The only way I know of to pass a parm greater than 100 chars to COBOL is to
do it through a DD statement that is coded in the Program. I do not
remember that COBOL (any version) as having the same function as PL/I or C++
with the DD Name Option. If you are trying to pass in the LE options, then
Nuttall, Peter [CCC-OT_IT] wrote:
Hi All,
Enterprise COBOL compiler v3.4.
Am pretty sure someone else must have hit this. I have hit the
100 char (I think ?) limit for the opts passed to the compiler
via the Parm setting in the JCL.
For the Enterprise PL1 compiler I solved this by
Hi Peter,
In respect of:
Enterprise COBOL compiler v3.4.
Am pretty sure someone else must have hit this. I have hit the 100 char (I
think ?) limit for the opts passed to the compiler via the Parm setting in the
JCL.
For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS'
-snip-
Hi All,
Enterprise COBOL compiler v3.4.
Am pretty sure someone else must have hit this. I have hit the 100 char (I
think ?) limit for the opts passed to the compiler via the Parm setting in the
JCL.
For the Enterprise PL1 compiler I solved
There have been previous requests for COBOL to have the same type of DD that
PL/I has had for years (and that LE has recently introduced) to avoid this.
However, there certainly is none right now.
Steve has given a couple of answers, and using a CBL (Process) card (that
you can concatenate with
]
Behalf Of Rick Fochtman
Sent: 12 December 2006 14:33
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
-snip-
Hi All,
Enterprise COBOL compiler v3.4.
Am pretty sure someone else must have hit this. I have hit the 100 char (I
In a recent note, Bill Klein said:
Date: Tue, 12 Dec 2006 09:07:51 -0600
There have been previous requests for COBOL to have the same type of DD that
PL/I has had for years (and that LE has recently introduced) to avoid this.
However, there certainly is none right now.
There was a
Paul Gilmartin wrote:
In a recent note, Bill Klein said:
Date: Tue, 12 Dec 2006 09:07:51 -0600
There have been previous requests for COBOL to have the same type of DD that
PL/I has had for years (and that LE has recently introduced) to avoid this.
However, there certainly is none
Bill Klein wrote:
If the parm string sets environment variables, you can move those into a
separate DD. Do a search on _CEE_ENVFILE.
There have been previous requests for COBOL to have the same type of DD that
PL/I has had for years (and that LE has recently introduced) to avoid this.
Now all you have to worry about is them including options that you
DON'T want in production
-Original Message-
Nuttall, Peter
SNIP
... recommend to our programmers that they use the CBL statement in
their source for any extra options they might want to add.
SNIP
December 2006 16:38
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Now all you have to worry about is them including options that you
DON'T want in production
-Original Message-
Nuttall, Peter
SNIP
... recommend to our programmers that they use the CBL statement
] On Behalf
Of Paul Gilmartin
Sent: Tuesday, December 12, 2006 7:24 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: COBOL compiler options JCL PARM.
Certainly a relaxation of the JCL limit is a better use of resources
than each product's supplying its peculiar alternative. And, to my
knowledge, none
environment variable?
At compile-time?
(LE *does* let you use a DD for setting run-time options - if you are on
z/OS 1.8)
Don Poitras [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Bill Klein wrote:
If the parm string sets environment variables, you can move those into a
In a message dated 12/12/2006 11:20:11 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
keyword, the ALWAYS member contains those you want to enforce. And SAF is
your friend preventing those pesky application programmers from creating
their own custom members.
What keeps them
On 12 Dec 2006 12:45:17 -0800, [EMAIL PROTECTED] wrote:
What keeps them from overriding the PROC?
When I compile my programs for testing, I override the proc to
/ PARM.SGPF#2=(TEST,XREF,MAP,OUTDD(SYSOUX),DYNAM,
/ SSRANGE,RENT,BUFSIZE(2)),
I recently
these days?
Chris Mason
- Original Message -
From: Charles Mills [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Tuesday, 12 December, 2006 6:46 PM
Subject: Re: COBOL compiler options JCL PARM.
YA alternative is a Rexx wrapper which can provide a PARM of up
34 matches
Mail list logo
