Re: Enterprise COBOL V6.2

2017-07-25 Thread Jon Butler
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

Re: Enterprise COBOL V6.2

2017-07-24 Thread Frank Swarbrick
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

Re: Enterprise COBOL V6.2

2017-07-24 Thread Frank Swarbrick
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

Re: Enterprise COBOL V6.2

2017-07-23 Thread Clark Morris
[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

Re: Enterprise COBOL V6.2

2017-07-23 Thread Steve Thompson
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

Re: Enterprise COBOL V6.2

2017-07-23 Thread scott Ford
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

Re: Enterprise COBOL V6.2

2017-07-23 Thread Clark Morris
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 >>

Re: Enterprise COBOL V6.2

2017-07-22 Thread Steve Thompson
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

Re: Enterprise COBOL V6.2

2017-07-21 Thread Jesse 1 Robinson
[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

Re: Enterprise COBOL V6.2

2017-07-21 Thread Frank Swarbrick
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

Re: Enterprise COBOL V6.2

2017-07-21 Thread Cameron Conacher
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

Re: Enterprise COBOL V6.2

2017-07-21 Thread Cameron Conacher
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

Re: Enterprise COBOL V6.2

2017-07-21 Thread Frank Swarbrick
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

Re: Enterprise COBOL V6.2

2017-07-21 Thread Bernd Oppolzer
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,

Re: Enterprise COBOL V6.2

2017-07-21 Thread Cameron Conacher
> 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

Re: Enterprise COBOL V6.2

2017-07-20 Thread Frank Swarbrick
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

Re: Enterprise COBOL V6.2

2017-07-20 Thread Frank Swarbrick
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.

Re: Enterprise COBOL V6.2

2017-07-20 Thread Cameron Conacher
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

RES: Enterprise COBOL V6.2

2017-07-20 Thread ITURIEL DO NASCIMENTO NETO
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

Re: Enterprise COBOL V6.2

2017-07-20 Thread Dan Little
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

Re: Enterprise COBOL V6.2

2017-07-20 Thread Tim Deller
"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

Re: Enterprise COBOL V6.2

2017-07-18 Thread Salva Carrasco
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

Enterprise COBOL V6.2

2017-07-18 Thread Frank Swarbrick
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