r 6.3.
> Yeah, it should work, but I would not do it.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: Wednesday, January 15, 2020 8:56 AM
> To: IBM-MAIN@
o it.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Wednesday, January 15, 2020 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
You are misunderstanding. My concer
Swarbrick
Sent: Tuesday, January 14, 2020 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
I disagree with that. A new version may simply be new features, none affecting
any features the old version supported.
From: IBM Mainframe
, January 15, 2020 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Seems to me your problem is recompiling after testing. If you want to
avoid problems that re-compiling could introduce, then don't.
sas
On Wed, Jan 15, 2020 at 11:59 AM Frank Swarbrick <
frank.swa
, January 15, 2020 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
Here's another gotcha to worry about regardless of compiler version. It was a
real
On Behalf Of
Frank Swarbrick
Sent: Wednesday, January 15, 2020 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Migrating to new compiler release
Yeah. We do have regressions tests, but it's not built in to change control
itself. Perhaps something we should look in to enhancing. Thanks
;
Sent: Wednesday, January 15, 2020 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
We migrate source *and* executable into a controlled stage environment where
the app folks are supposed to do one last round of tests. From there, its
straight copy to al
:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
You’ve got me there! I would think that chance is relatively small and
wouldn’t worry about
___
> From: IBM Mainframe Discussion List on behalf
> of Michael Babcock
> Sent: Wednesday, January 15, 2020 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Migrating to new compiler release
>
> Any difference should be documented in the migration guides I would think.
>
Intentional differences, yes. Bug; probably not!
From: IBM Mainframe Discussion List on behalf of
Michael Babcock
Sent: Wednesday, January 15, 2020 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Any difference should
ed by one compiler would be different, for the same statement, for
> another.
>
>
> From: IBM Mainframe Discussion List on behalf
> of Charles Mills
> Sent: Monday, January 13, 2020 4:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Migrating
10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Seems to me your problem is recompiling after testing. If you want to
avoid problems that re-compiling could introduce, then don't.
sas
On Wed, Jan 15, 2020 at 11:59 AM Frank Swarbrick <
frank.swa
_
> From: IBM Mainframe Discussion List on behalf
> of Clark Morris
> Sent: Tuesday, January 14, 2020 4:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Migrating to new compiler release
>
> [Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main
> frank.sw
.
From: IBM Mainframe Discussion List on behalf of
Clark Morris
Sent: Tuesday, January 14, 2020 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
[Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main
frank.swarbr
a short window where
that would happen, so probably not worth fretting about.
From: IBM Mainframe Discussion List on behalf of
Charles Mills
Sent: Tuesday, January 14, 2020 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
I think
List on behalf of
>Charles Mills
>Sent: Tuesday, January 14, 2020 2:09 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Migrating to new compiler release
>
>> My question has to do with the (probably slight) possibility that the code
>generated by one compiler wou
Thanks a lot, Charles! That's going to occupy a lot of the team's time next
week trying to answer that question! So far, I know of at least one that is
having a very hard time.
--
For IBM-MAIN subscribe / signoff / archive
On
Behalf Of Frank Swarbrick
Sent: Tuesday, January 14, 2020 1:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
I disagree with that. A new version may simply be new features, none
affecting any features the old version supported.
: Re: Migrating to new compiler release
> My question has to do with the (probably slight) possibility that the code
generated by one compiler would be different, for the same statement, for
another.
It certainly would. If the code generated for every statement was the same
for both compil
On Tue, 14 Jan 2020 13:09:29 -0800, Charles Mills wrote:
>> My question has to do with the (probably slight) possibility that the code
>generated by one compiler would be different, for the same statement, for
>another.
>
>It certainly would. If the code generated for every statement was the same
een the two.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Tuesday, January 14, 2020 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
I understand that the runt
, January 14, 2020 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Hi Frank
There are a few relatively minor differences in code generated but these tend
to be mostly focused on taking advantage of z15. I assume you're not compiling
for z15 (yet)? Other than z15
Hi Frank
There are a few relatively minor differences in code generated but these tend
to be mostly focused on taking advantage of z15. I assume you're not compiling
for z15 (yet)? Other than z15 exploitation, this is like a really big
continuous delivery PTF. There is always the
for this
new version.
Frank
From: IBM Mainframe Discussion List on behalf of
Farley, Peter x23353
Sent: Monday, January 13, 2020 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Is it V6.3 that introduces the capability
Mills
Sent: Monday, January 13, 2020 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Caution and backups and fallback strategies are always good, but I don't
think there is much relationship between *running* a COBOL version X program
and having the *compiler
would usually insist on it.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Monday, January 13, 2020 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release
Caution and backups and fallback strategies are always goo
, January 13, 2020 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Migrating to new compiler release
I was wondering what "methodologies" shops have for migrating to a new
"release" within the same "version" of a compiler. Specifically, we
currently have Enterprise CO
I would certainly have 6.2 and 6.3 available for a few months of
testing, for sure. Probably a 3 way compare with 5.2 so you can be
certain of a useable program if you limit to 5.2 / 6.3.
On Mon, Jan 13, 2020 at 5:33 PM Frank Swarbrick
wrote:
>
> I was wondering what "methodologies" shops have
I was wondering what "methodologies" shops have for migrating to a new
"release" within the same "version" of a compiler. Specifically, we currently
have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available. Our systems group
asked if we just wanted to "replace" 6.2 with 6.3. I'm a bit wary
29 matches
Mail list logo
