LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (June 2000)Back to main CICS-L pageJoin or leave CICS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Thu, 15 Jun 2000 17:27:06 -0400
Reply-To:   CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender:   CICS List <CICS-L@LISTSERV.UGA.EDU>
From:   Timothy Fansler <tfansler@MINDSPRING.COM>
Subject:   Re: Version/Release Concerns
Content-Type:   text/plain; charset=us-ascii

WOB wrote:

> I've got a situation that I need to put to bed. We will be > installing a Credit Card System in October that has not been tested in a TS > environment and this has me concerned. Additionally, it has NOT been tested > in COBOL/MVS environment. Just COBOL2, Release 4.0, which also has me a bit > worried.

I've never heard of COBOL2 4.0. We were running on VS COBOL II until the last half of last year, and it sure wasn't a 4.0 version. That number seems way too high. We converted to COBOL for OS390 (COBOL/MVS ?) as part of our Y2K conversion.

> > Are my concerns warranted ? What is the likelihood that 4.1.0 will > be installed instead of TS ? Has anyone had any problems migrating to TS in > regards to the application code? Any COBOL2 to COBOL/MVS migration horror > stories or incompatibilities ?

The only incompatibility we ran into was when we started using the COBOL3 translator parm on the CICS translator step. If the application has any pre-translated PROCEDURE DIVISION copybooks that contain any EXEC CICS commands, and they've been pre-translated with the COBOL2 translator parm, the programs won't compile if you use the COBOL3 parm with the translator step. This is because the translator, with the COBOL3 parm, doesn't generate the variable definitions for variables referenced in commands translated with COBOL2. That was relatively easy to fix - we just replaced the translated copybooks with the original source. We have a step prior to the translator that pulls all the copybooks into the source anyway, so there was no real need for them to be pre-translated.

We could also have simply pre-translated all the copybooks with COBOL3, but that would have meant that entire applications would have had to be mass re-compiled, and our change management people (rightfully, I think) didn't want to do that. The testing effort afterwards would have been enormous.

Other than that, the whole conversion went very smoothly without any other hitches. VS COBOL II is source-compatible with the higher compiler, so no source code changes were required, and everything worked just fine the first time. You do have to make sure that you have equivalent COBOL2 / LE370/COBOL-MVS compile/runtime options though to be safe. One that comes to mind that could change behavior if not equivalent is TRUNC=BIN/STD/OPT (or whatever the possible values are).

I hope some of this helps.

Cheers, Tim Fansler Blue Cross / Blue Shield of Georgia

Standard disclaimer: I do *not*, in any way shape or form, speak for my employer; I reserve the right to be wrong - I have to do so because I've been wrong so many times before I'm positive I will be again.

> > > I'm posting this because I'm one of the grunts that will have to fix > the bloody mess post haste if problems surface. > > All replies welcome, scathing or otherwise. > > TIA.... > > WOB


Back to: Top of message | Previous page | Main CICS-L page