Cobol for MVS migration
Cliff Tinson
My company is migrating from IBM Cobol 2 to IBM Cobol for MVS. We are led to
believe that this requires no code changes or re-compiles. Can anybody
confirm this from their own experiences.
Thanks
Cliff
Arnold Trembley
We are in the process of converting to LE/MVS and COBOL for MVS and VM.
We currently run a mix of OS/VS COBOL and COBOL II. I did some limited
testing of batch COBOL programs with LE/MVS.
I have not had any trouble executing batch COBOL II programs with the
LE/MVS runtime library SYS1.SCEERUN. Since LE/MVS is not our default
runtime environment, I have to JOBLIB or STEPLIB to it.
I found one batch program that was undergoing Y2K remediation and was
being converted from OS/VS COBOL to COBOL II, so I was able to run a
parallel test with both programs pointed to the LE/MVS runtime
environment. It checked out fine.
I recompiled a 7,000 line COBOL II program under the COBOL/MVS
compiler. No source changes of any kind were made. A parallel test
gave identical results. The COBOL II version also runs fine with the
LE/MVS runtime library.
I currently work with a large CICS application that uses three CICS
regions connected via MRO. This application is currently CICS 3.3 and
COBOL II. We recently brought up our test regions on CICS 4.1 with
LE/MVS runtime libraries (lots of security problems, but we got past
them). The CICS COBOL II programs appear to run perfectly well in CICS
4.1 with LE/MVS. We haven't done any work yet compiling CICS programs
with the COBOL/MVS compiler.
I hope that helps!
Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
St. Louis, Missouri
BarbaraKE
>> My company is migrating from IBM Cobol 2 to IBM Cobol for MVS. We are led
>to
>> believe that this requires no code changes or re-compiles. Can anybody
>> confirm this from their own experiences.
>I have not had any trouble executing batch COBOL II programs with the
>LE/MVS runtime library SYS1.SCEERUN. Since LE/MVS is not our default
>runtime environment, I have to JOBLIB or STEPLIB to it.
I agree with this. The biggest problem we had was getting the programmers to
remember to add this joblib/steplib to their personal programs. Make sure to
publicize this _repeatedly_.
We also haven't had any problems compiling our Cobol II stuff under MVS.
C-Lane
BarbaraKE wrote in message
<19971128190...@ladder02.news.aol.com>...
Do yourself a favor and recompile one of the programs and run it without the
required
SYS1.SCEERUN. Make note and publish the profile of the of the dump. Many
hours of time have been wasted during our cutover trying to find the
'problem'.
And as stated above repeatedly publicize!!!!
Joel C. Ewing
Cliff Tinson wrote:
> My company is migrating from IBM Cobol 2 to IBM Cobol for MVS. We are led to
> believe that this requires no code changes or re-compiles. Can anybody
> confirm this from their own experiences.
>
If you convert to LE run-time first and get SCEERUN in the LINKLST, then
you don't have to worry so much about folks using incompatible runtime
with COBOL for MVS object code. We switched over to COBOL for MVS from
COBOL II with minimal fanfare after adding SCEERUN to LINKLST and LE to
all CICS regions, and so far have received no reports of source-level
incompatibilies (many batch and CICS compiles per day for about 6 months
now). The only "unusual" problem we encountered (and I don't recall
seeing any warning about it), was that COBOL CICS programs with static
CALLs to COBOL-II-compiled COBOL subroutines had problems unless the
subroutines were recompiled with the new compiler first. Perhaps a
relink of the subroutines with LE replacements for some of the COBOL II
CSECTS might have been sufficient, but in our case it was simpler just
to recompile.
--
Joel C. Ewing, Fort Smith, AR jce...@acm.org
S Comstock
Here we go again.
I know everyone is pressed for time and resources, but I recommend doing a
little training along the way.
What I'm finding is many shops who went to COBOL II just made the minimum
source changes to get their OS/VS COBOL programs to compile and run. Few shops
actually explored the new capabilities of COBOL II. Now comes the new compiler
(COBOL/370 then COBOL for MVS & VM, then COBOL for OS/390 & VM) and the same
thing.
The jump to COBOL II was enormous in terms of new capabilities, but few
programmers are aware of the new features and so they write code that could be
vastly improved. Similarly, the jump from COBOL II to COBOL for MVS & VM (and
later) is also enormous in terms of new capabilities. But no one is learning
them.
The result is new and revised programs being written in the style and spirit of
COBOL 74, or even COBOL '68. While COBOL has added tons of features and
capabilities, everyone's looking at C, C++, and Java, totally missing the
amazing things you can do in COBOL.
A few samples (of varying degrees of usefulness)
- Upper, lower, and mixed case text
- un-named filler
- scope terminators (end-if, end-read, etc.)
- inline perform
- perform with test before / after
- increased table sizes
- addresses, pointers
- intrinsic functions
- evaluate verb
- local-storage
- nested programs
- object oriented COBOL
lots more.
ADVERTISEMENT: I jut happen to offer a two-day course that does a thorough
survey of the changes in COBOL from COBOL II (a recap) through the various
releases of the new COBOL compilers. This course includes a brief introduction
to LE services, including a discussion and lab using the new date and time
services to work with Y2K issues.
Outline and additional information available on request.
Cheers,
Steve Comstock
Telephone: 303-393-8716
email: SCom...@aol.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
The Goobers
S Comstock wrote:
>
> Here we go again.
>
> I know everyone is pressed for time and resources, but I recommend doing a
> little training along the way.
Heresy! It is a Well-Known Fact that if you give someone training they
will immediately jump ship to a higher-paying company because said
company is foolish enough to think that a person, trained, is more
valuable than a person, untrained... don't they know that Gratitude Is
Enough?
>
> [snippage]
> The result is new and revised programs being written in the style and spirit of
> COBOL 74, or even COBOL '68.
Now, repeat after me: 'The responsibility for the allocation,
co-ordination and motivation of personnel and resources towards the
accomplishment of a stated Executive goal is that of Management.'
Repeat again.
Let's look at it another way... assume that an organisation has invested
a great deal of money in the upgrading of the physical plant. If
sufficient investment has been made then it is likely that serious
consideration will be given to upgrading the security system (new locks,
etc.) to prevent these improvement from 'walking off'. Also consider
the common term of 'golden handcuffs', a recognised metaphor for
increasing salary/benefits to prevent human capital from *physically*
walking away. Now, consider the investment of money in humans to
upgrade skills in order to make them more valuable to the company.
Consider how many times you have seen a corporate policy stating that an
increase in salary/benefits accompanies the successful completion of
such an upgrade (courses).
Years ago the Wall Street Journal did a story on one of the major NY
houses... I think it was Morgan Stanley or Morgan Guaranty or the like.
They hired *only* the 'unhireable'... kids with BAs in Library Science,
Art History, etc... they put these kids through two years of hell, 60 -
70 hr weeks, and turned them into *crackerjack* programmers... and then
saw said kids being hired away by the competition at double or triple
the salary. When asked why a raise did not accompany the completion of
the course the HR representative replied 'Oh, we cannot do that... all
the money has been taken up by training.' (compare this with 'Oh, we
cannot upgrade the door-locks... all the money went into oil-paintings
to hang on the walls.')
After a few years of seeing themselves serve as Wall Street's unofficial
programming school the company finally 'wised up'... and cancelled the
program entirely.
DD
RWidmer
From a code point of view no changes are required if you are at VS COBOL II R4
with NOCMPR2.
Unfortunately, LE/370 has a number of "fun" features, along with about 60
parameters that must be set at install time.
The bare minimum effort that should be done is to "qualify" the run time
environment. A paper describing this process is called "HLL Predictability
Testing" and has been presented multiple times at GUIDE and SHARE.
Experience has shown that one particular test case - called CASE14 produces
undesirable results at 95% of shops where it is executed.
Mixed language cases also require signficant review due to side effects that
occur with LE.
Available tools (yes blatant commercial) - "LE/370 Survival School" and "Edge
Portfolio Aanlyzer", both of which should be deployed before installation of LE
into production.
Rex Widmer
Builder of software archeology tools and other strange programs to help survive
in a legacy based world.
Harry Carter
"Cliff Tinson" <cliff...@zetnet.co.uk> wrote:
>My company is migrating from IBM Cobol 2 to IBM Cobol for MVS. We are led to
>believe that this requires no code changes or re-compiles. Can anybody
>confirm this from their own experiences.
There are some cases where the Cobol II environment let you do things
you shouldn't have been able to do and LE/MVS won't.
The problem comes in if you recompile one program that makes several
static calls. In some cases the recompiled/linked program won't work,
although it would if all the programs in the load module had been
recompiled.
Harry Carter
hca...@cluster.mcs.net - finger for PGP key
Home Page: http://www.mcs.net/~hcarter
"Make no little plans; they have no magic to stir men's blood."
Daniel Burnham