Yes, Mainframe Is Not a COBOL-only platform.

I’m currently working in the largest Brazilian private bank, and this gave me the oportunity to learn a lot about Mainframes, play a lot on them, and even teach some colleagues some C programming.

Everybody knows Mainframes are famous for its massive use of COBOL language, and legacy software. Mainframe workers frequently have to deal with programs which were created more than 20 years ago.

What most people don’t know is that mainframes are not limited to old languages like COBOL or PL/I. In fact, almost all IBM servers come with a C compiler. And there is even some initiative on using Java and .NET on mainframes.

So you may ask: “then what?”

Well… Then you got a brand new language to do what you can’t (or it’s too hard to) do in Cobol.

And what kind of things does C language offer us?

  • Mathematical Functions
  • String manipulation
  • Pointer/memory manipulation
  • A Less Verbose Language (more compact, and a billion times more elegant)
  • Much more…

And for the best, you may integrate C with your legacy Cobol, so you can modernize your software in baby-steps, preserving your investment, and with a gracious migration.
You can even integrate C with your transaction system (CICS/IMS) for online operations. (Of course it’s also useful for batch processes).

You won’t find in web much documentation on how to interact C with Cobol.
As a start, I suggest you the following link: [http://publibz.boulder.ibm.com/epubs/pdf/ceea4120.pdf](“http://publibz.boulder.ibm.com/epubs/pdf/ceea4120.pdf")
(Language Environment - Writing Interlanguage Communication Applications)

The technical difficulties:
After you try to pass parameters from COBOL to C, you will realize that it’s not easy. The problem is that C compiler uses memory alignment, so it’s hard to represent a cobol copybook into a c struct, since the struct will have some blank bytes between the fields that won’t exist in cobol copybook.

In the few references you can google about Cobol/C integration some people might suggest using the __nomemalign or the _Packed directives. My experience with our C/370 compiler on my company’s mainframes: those directives DON’T work.

Now the trick: don’t try to make a c struct for your copybook, use pointers (direct memory access) instead. By using pointers you know exactly where the cobol fields are located in memory, and you can then cast that memory address to your correct type, and do the job. To determine the offset (location) of each parameter, you must simply know the size of each parameter (you can learn that reading the “Supported Data Types” in the url mentionated above) and make a memory map using simple byte-size addition.

So, let’s go for the samples.

Simple example:
if the cobol copybook contains:

01 MYBOOK  
03 PIC S9(4) BINARY  
03 COMP-2  
03 COMP-1  

then your C function (called with a CALL CMODULE USING MYBOOK) will receive a pointer to this area:

Offset Size Type
0 4 int
4 8 double
12 4 float

And you can manipulate those values directly by using type-casting with pointers. (I don’t have the code right now. Maybe in the next post, if someone shows up interested.)
(if people ask I can give more examples).

Another nice point, is that Cobol DOES provide data types for float-point operations. Most Cobol programmers know only COMP, COMP3 and Zoned formats. There are two types for floating-point types: COMP-1 and COMP-2, with 4 and 8 bytes respectively.

There in my job, we had some need for using advanced mathematical formulas in Cobol, and you can’t really do much with cobol. So my solution was integrating Cobol to C, using dynamic calls.

Important to say that C does not have the concept of “subprograms”, since any module can be a program or a subprogram (can receive parameters or not), and that depends on the entrypoint. So it’s not a “C subprogram”, but just a “Cobol module calling a C module”.

Hope you enjoy.

comments powered by Disqus