Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

COBOL C compatibility under linux

Status
Not open for further replies.

amarg

Programmer
Nov 19, 2002
106
IN
Hi All,

Currently we are migrating from HP-UX to Red Hat. Most of the code is in Cobol and C.
Cobol and C functions calls each other and working perfect under HPUX.

Before migrating to Linux, I need to do the POC (Proof of Concept). For that I need to design the test cases.
I am looking for the discussion on what kind of test cases I should include in my POC.

Like passing different of structure (different combination of datatypes) from cobol to c or otherway.

Any tip will be very helpful.
Also is there any website having same discussion?

Thanks,
 
main thing you need to look at is if you are moving from a 32 bit environment to a 64 bit environment in terms of how you compile your C and COBOL source. Mainly C can be affected if you are at the moment working as 32 bit and you move to 64 bit. COBOL programs most of the times dont have that issue, but it can still arise.

Second... are you using static linked programs, .int, .gnt or shared objects on HP? and will you be doing the same on RedHat? This may also have an impact on how you do things on the new environment.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Yes, we are using static linking, and it's going to be the same on RedHat. I didn't understand properly you do you mean by .int, *.gnt or shared object on HP.

Please explore your comment. Looks like a very good tip.

Thanks for your comments.
 
search the net and your cobol vendor documentation for "static vs shared object". there are pros and cons on each one, and this is not the place to discuss this.

This is a decision that needs to be made by your technical architects, and does require a good knowledge of both your COBOL version on both hp and redhat, and also knowledge of how objects (programs) work and interact on redhat.

.int, .gnt are microfocus cobol specific formats for programs which is the most common COBOL vendor used on hp (apart from Liant's RM/COBOL).

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Just to add, it's microfocus cobol on HP-UX and going to be the same on RedHat. But may be because of OS change run time output will be quite different.

Yes you are right it's not a place to discuss, but I am looking for the place and documentation on net to get some sort of help.
 
Do watch out for the Endian-nes of HP-UX, at least, it's different if you come from PA-RISC(2) and go to Intel, and swapping bytes between binary datatypes of Cobol (comp-3 etc.) and your datastore... Your data may not be forward-compatible :-|
 
There may be a lot to it. it all depends on what you do with your C programs and up to a certain point with your COBOL programs.

Also bear in mind that it is not only those that you have to worry about, but also the unix scripts and commands you may be using.
Things like sort commands, printers, etc, all of them can behave differently on Linux.

My first advice is to compile everything on Linux (both C and COBOL programs) and see if they even compile. I'm in the middle of a migration from HP to AIX, and a few COBOL programs will not compile at all, and fail with a COBOL internal error.

Whatever emulator you use will also need to be tested, as the way terminal emulators work with HP settings may not work with the ones on Linux.

Also some type of file opening that worked fine on HP may not work on newer versions of COBOL. specially case I remember from previous upgrades on other clients, was the fact that on HP COBOL 2.2 you could define 2 line sequential files with diff size, and open them within the same run unit without any problem, and on 5.5 it failed.

So basic test is compile, fix compile errors, then run everything to identify other errors. then worry with the full test

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top