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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Micro Focus COBOL/2 2.4.17 how to call C functions

Status
Not open for further replies.

Cantor3

Programmer
Dec 2, 2011
4
US
Hello.

I have a friend who was a COBOL programmer professionally
for many years but is now long retired.

He has no interest in learning any other languages,
but he enjoys dabbling with Micro Focus COBOL/2 2.4.17
to develop 16 bit DOS 6.22 programs for his own use.

He needs some help with math algorithms.

I have a strong background in math and physics,
but zero experience with COBOL,
and I would like to write some 16-bit DOS C functions
that he could call from his COBOL programs.

I'm having difficulty finding information in the form
of simple working examples on how to do this.

Figuring out the math
and writing the C functions
is not the problem.
I can churn those out effortlessly.

What I haven't been able to figure out yet,
and would like some help with,
is how to call the C code from MF COBOL/2
and have the C code return the answer(s)
to the COBOL program.

I have figured out how to use
the MF COBOL/2 X"91" function 35
to call (and pass parameters to)
a C executable (EXE),
and when the called C code is done,
it does return to the MF COBOL/2 program,
but I haven't been able to figure out
how to pass information from the C code
back to the calling COBOL program.

The only way I've found so far that works
is to have the C code write the information
to a disk file, and have the COBOL program
read that disk file.

But that's WAY too kludgey for my tastes.

Is there some way to use the stack,
or some static memory area,
or even the DOS 16-bit long
Inter_Application_Communation area (IACA)
at fixed memory address 40H:F0H ?

What I need is simple working COBOL
examples of how to receive infomation
back from the called C code.

Thanks.
 
A lot of what you're facing here is more in line with compiler issues than it is any code related thing. The usual path for COBOL is to use linked function calls, but most modern stuff can use DLLs too. The general idea of the linked program calls in COBOL is something like:

CALL 'BIGMULT' USING MAIN-COMM-AREA.

"BIGMULT" being a linked function in a OBJ file. Of course, you can use multiple variables, switch functions, and the like and return values just like the functions you are used to in C.

One problem you're going to have is whether you can find the proper function linkage in C that the COBOL will understand. Some of them will be a bit flexible, like this call to a Windows API function within a Fujitsu COBOL 3.0 program:

CALL "GetWindowLongA" WITH STDCALL LINKAGE
USING BY VALUE WS-WINHANDLE
BY VALUE GWL-STYLE
END-CALL.

(Note the DLL this function resides in is listed in a COBOL linker file)

Then you would have to present data to the COBOL program in a way that it will understand. For example, C is little-endian based, while COBOL is big-endian based, relating to the side of a number that has the most significant bit. A lot of PC COBOL compilers will have special data types laid out to fit things like you have in your C. For example S9(9) COMP-5 is a COBOL little-endian 4-byte value and COMP-1 and COMP-2 are floating data types (single/double) but all aren't necessarily supported by the COBOL compiler.

A lot of times though, text presentation format (e.g. specifically formatted strings) is more preferred for COBOL than floating-point data types and your friend may insist upon that for the math functions. You may also have to invert the bits in your binary values you receive into your C functions before use and upon return.

Finally, another issue is getting the COBOL to link to the OBJ files you generate along with whether the COBOL will understand the format of the OBJ files that your C compiler will generate. This may or may not be possible.

To solve this, a lot of us would need to be able to play with both your C compiler and the COBOL compiler in order to see if they inter-operate properly and then find a working example. I know I could probably get a verdict in about 30 mins or so if I had them both to play with. I have Delphi and know the OBJ files there don't interoperate with Fujitsu COBOL but I can call DLL functions.

I know that probably wasn't as concrete as you were looking for, but it's about all I can do without seeing the compilers and knowing what their features are.

 
Hi Glenn9999.

Thanks for replying.

DLL is not a solution because my question is about 16-bit real mode (DOS 6.22).

I am using Borland's Turbo C version 2.01 compiler and linker. You can download it for free.

My friend is using Micro Focus COBOL/2 2.4.17 to develop 16 bit real mode DOS 6.22 programs for his own use.

I have successfully written a small 16-bit real mode C subprogram which accepts command-line parameters; compiled and linked it into EXE; and called it from a COBOL program in the same way that a COBOL program would call an EXE written with COBOL.

It works. The called C subprogram can read the command line parameters passed to it by the calling COBOL program, interpret them properly, display a message on the screen, and return to the calling COBOL program.

What I haven't been able to figure out is how to pass information back to the calling COBOL program.

Can COBOL read data from an absolute (static) memory address? If so, that would solve my problem. In the called C subprogram, I can easily write data to an address in memory.

.
 
Would it not be better to spend your time rather using the current GNU COBOL compiler than the old MS DOS compiler ?
It would be very interesting to know, how to call GCC or GFortran functions/programs from GNU COBOL.
 
Hi mikrom.

Thanks for your reply.

As stated in my original post, the use of the ancient Micro Focus COBOL/2 2.4.17 DOS-based compiler is not my choice to make.

I am trying to accommodate a friend who is using it. He has his reasons, which I won't try to justify here.

...

If there are any readers out there who are familiar with Micro Focus COBOL/2 2.4.17, would you please take a few moments to carefully read my original post. Thanks.

 
>DLL is not a solution

I'm not suggesting that, necessarily. I'm suggesting whatever way the COBOL compiler can do it, which is probably the standard C way to do it too. Define C functions, import them into the COBOL compiler. Assuming the compilers interoperate. Re-read my original post carefully.

> how to pass information back to the calling COBOL program.

Standard C functions read into COBOL via OBJ or DLL file (whatever the COBOL compiler supports). Like I suggested. The first step would be to generate OBJ files out of your C compiler and see whether the COBOL compiler accepts them. Then the data considerations I noted.



 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top