Another thing to watch out for with passed parameters is their lengths. If the
subroutine has a Linkage Section parameter that is longer than that in calling
module, you will get an LE run-time error "CEE0802C -- Heap storage control
information was damaged." This is another practice that the
List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
Steve Thompson <ste...@copper.net>
Sent: Saturday, July 22, 2017 7:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2
And what happens when the program gets called with a "zero" parm?
One would hope
inframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
Clark Morris <cfmpub...@ns.sympatico.ca>
Sent: Sunday, July 23, 2017 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2
[Default] On 23 Jul 2017 07:10:50 -0700, in bit.listserv.ibm-main
ste...@copper
[Default] On 23 Jul 2017 07:10:50 -0700, in bit.listserv.ibm-main
ste...@copper.net (Steve Thompson) wrote:
>The use of INITIALIZE on a Linkage section element was the whole
>point of my posting.
>
>I know of no way to tell, from within a COBOL program, if the
>parm info is valid. A called
The use of INITIALIZE on a Linkage section element was the whole
point of my posting.
I know of no way to tell, from within a COBOL program, if the
parm info is valid. A called program assumes that the storage it
has defined is what has been passed.
This is why IBM is telling people to
and the first filler
> item are both set to their corresponding "values". The other two are set
> to the default value for their data type; 0 in both cases because they are
> numeric fields.
> >>
> >> This doesn't appear to answer your concern, bu
quot;. The other two are set to the default value
>> for their data type; 0 in both cases because they are numeric fields.
>>
>> This doesn't appear to answer your concern, but I bring it up both because
>> it is true and because it is useful! :-)
>>
>> Frank
>>
it
is true and because it is useful! :-)
Frank
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Frank
Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 20, 2017 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Frank Swarbrick
Sent: Friday, July 21, 2017 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Enterprise COBOL V6.2
I don't have the answer to that one. I imagine it's possible! But I don't
believe there was any specific intent
ssion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
Cameron Conacher <conac...@gmail.com>
Sent: Friday, July 21, 2017 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2
Thanks Frank.
I agree this is bad code.
I was curious if the new COBOL 6.2 compiler would uncover
scussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Cameron Conacher <conac...@gmail.com>
> Sent: Friday, July 21, 2017 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
>
> Here is a snippet from someone else's observations:
> Hi
I completely agree this was at best a hidden error previously
My question was not so much how to work around it but whether there were other
similar nuggets with COBOL 6.2
Sent from my iPhone
> On Jul 21, 2017, at 11:48 AM, Bernd Oppolzer
> wrote:
>
> This has
Cameron Conacher <conac...@gmail.com>
Sent: Friday, July 21, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2
Here is a snippet from someone else's observations:
Hi
Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
Version 6.1
COBOL s
This has already been brilliantly explained by Frank Swarbrick;
the new COBOL compiler version has a new INITIALIZE statement
which is able to INITIALIZE variables of the LINKAGE SECTION,
so that the VALUEs coded there are not comments any more,
but instead the have a meaning !!
In the past,
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Cameron Conacher <conac...@gmail.com>
> Sent: Thursday, July 20, 2017 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
>
> Hello everyone.
> COBOL 6.1 int
ist <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 20, 2017 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2
I'm not clear on what you are saying here. Can you give an example of both the
code and the error
2017 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2
Hello everyone.
COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
initialization are flagged as errors.
Ever since I began using COBL in the seventies, this would be treated as a
warning.
Hello everyone.
COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
initialization are flagged as errors.
Ever since I began using COBL in the seventies, this would be treated as a
warning.
Personally, I consider it bad form, but the compiler happily marched on.
We have a number
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de
Frank Swarbrick
Enviada em: terça-feira, 18 de julho de 2017 18:35
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Enterprise COBOL V6.2
https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=897=ENUS217-323
- Compiler
Don't need a compiler for that!
On Jul 20, 2017, 8:33 AM -0400, Tim Deller , wrote:
> "Conditional complication"?
> Sounds about right...
>
> --
> For IBM-MAIN subscribe / signoff / archive access
"Conditional complication"?
Sounds about right...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Another versión?
wasn't it continuos delivery?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
unds interesting.
"The Vector Packed Decimal Facility allows the dominant COBOL data types,
packed and zoned decimal, to be handled in wide 16-byte vector registers
instead of in memory. Decimal and floating-point computationally intensive
COBOL programs, which are optimized with Enterprise C
23 matches
Mail list logo