Converting COBOL to C

[OldGeek]

I have lots of COBOL to convert to C, not C++, but standard C.

I think I know how to do this, but I would like some advice.

The first of no-doubt many questions is how to emulate the COBOL 88 level variables in the C language. In COBOL there are whats know as 88 level variables, subordinate to an actual variable of any type. The 88 level variable is kind of a Boolean look at the actual variable. I need to do the same in C, suggestions of another method are very welcome.


/* In COBOL:

 01 NOOP-SW                                   PIC X     VALUE "0".
    88 NOOP                                             VALUE "1".

So that in the procedure code I would write:

 MOVE "0" TO NOOP-SW.
* Maybe during other processing "1" would be moved into NOOP-SW.
  Then I would test this condition in COBOL as follows:
  
 If NOOP
  GO TO OP-EXIT.

NOW (Im a C newbie),
In C, would I predefined the following:

 #DEFINE NOOP (strcmp(NOOP-SW,"1")==0)

Then in the function I would also have the following char:
char NOOP-SW];
Same scenario, to test if we have a "1" or "0" in NOOP-SW, in C:

  if NOOP 
   return(0);

I really need to convert the COBOL with minimal changes in design, because it amounts to many thousands of lines of COBOL code. The COBOL code actually runs on Windows, and Linux, but it's not very portable, and that's why I need to re-write it in C.

Thanks,
OldGeek.

[itCbitC]

What I am able to glean from your post is that 88 level variables are akin to enums in C.
Google "enums" and that should put you on the right track hopefully, otherwise post again.

[Salem]

> The COBOL code actually runs on Windows, and Linux, but it's not very portable,
What does this mean?

If it already runs on both architectures, then what benefit are you going to get from converting it to C?

[Adak]

It's not portable, it's heavy! It will be much so much lighter, if it's transferred over to C. :P

[OldGeek]

I looked at enums -- it is almost a match, however enums are limited to integers, and 88 levels are used with any data type.

Here is another snip of COBOL that I need to convert:

 01  MY-FIELD-TYPE                            PIC X(4) Value Spaces.
     88 Valid-Type
      Values are "CHAR" "DIG " "DMY " "MDY " "YMD " "IMP0" "IMP1"
                 "IMP2" "IMP3" "IMP4" "IMP5" "IMP6" "IMP7" "IMP8"
                 "IMP9" "NUM " "NUM0" "NUM1" "NUM2" "NUM3" "NUM4"
                 "NUM5" "NUM6" "NUM7" "NUM8" "NUM9".

So, then test as follows

if Valid-Type then
  display "Field type is valid"
else
 display "Invalid field type found"
end-if

I appreciate your suggestion, enum will work for many cases, like:

 01  TXT-SW                                   PIC 9     VALUE 0.
     88                                     TXT-CLOSED  VALUE 0.
     88                                     TXT-OPEN    VALUE 1.
     88                                     TXT-EOF     VALUE 4.
     88                                     TXT-ERROR   VALUE 9.

 If TXT-CLOSED Then
  Open Output Text-File.

The above statement would be true if TXT-SW was equal to 0.

I also need advice for the best most portable method to handle fixed length and variable length strings in C.
I know C handles variable length strings great, as long as they are null terminated, however the COBOL code that I am converting is used to build a dll and/or .so and the calling applications may pass strings into this library that are not null terminated, but fixed length, something that must be allowed.

[OldGeek]

Runs on Linux and Windows, is not very portable, does sound odd, sorry. What I mean by portable, is at the language level. This COBOL code that I am converting actually gets compiled into a .dll on Windows and a .so on Linux, as well as a .sl on HPUX. However, it can only be called by Cobol Applications, and it get worst, it is only callable from the same flavor of Cobol. If I compile it using Cobol-IT, then it can't called from Fujitsu Cobol.Net or AcoCobol and so on. Nor can it be called by Fortran or Java, or anything else but the flavor of Cobol that the library was compiled with. Then there is the issue of each language needing its own run-time library to be present, the C run-time is always there or quickly available, and therefore more portable! If I compile in C, then I'll also by able to use swig, and add this (once COBOL) library to C#, Go, Java, Perl, PHP, Python, Ruby, Tcl. C is a must for building subroutine/function libraries in today's multi-lingual development environment!

[Salem]

> It's not portable, it's heavy! It will be much so much lighter, if it's transferred over to C. :P
...
> NOW (Im a C newbie),
Don't forget, so much more buggy as well.

Unless this is a student homework/just for fun project, I can see this being a waste of time and money.

If for example, you imagine a huge performance boost, then this would only come about if you were an experienced C programmer.
> #DEFINE NOOP (strcmp(NOOP-SW,"1")==0)
If you did this, you would only make it worse, not better.

Spend 6 to 12 months really learning C, then you'll be able to answer most of your own questions intelligently.

But for you to drip-feed us bits of COBOL (out of context) looking for ways to implement them in C (out of context), then all you're going to end up with is some horrible Chimera that no one would ever want to look at (even you).

Edit:
Just read your next reply.
Have you considered a COBOL to C translator? http://www.mpsinc.com/cobol.html

Or considered just adding "glue" 'C' code around the COBOL libraries.
The glue layer doesn't have to do anything clever in terms of processing, but it would provide you with a consistent API interface callable from anywhere.

[OldGeek]

Well Salem, I agree with all the points you've made. And I certainly don't want a monstrous fire-breathing female creature on my hands. When I say C newbie I mean I've written the occasional small C function as glue between other languages and the OS in the mini mainframe environment, as well as the x86 world, for many years, only small brain-dead functions, but I do understand scope and pointers and passing by value or reference. The real business application programming that I've done is in Cobol & Fortran, and other application langs, very little C. One thing that is in my favor is that I wrote every line of code in this COBOL library that I want to convert to C, so their is not a single character in the source that I don't understand. I just need some trivial info like enums, that was a damm-good suggestion! What other ways are their to do string evaluations, and string manipulation in C? I don't care if it takes 6 to 12 months for me learn how to write the same COBOL functions in C, the software needs it just as much as I need it, and I am somewhat autodidactic, I just need someone to point me in the right direction.

[Salem]

Ah, I see.

> What other ways are their to do string evaluations, and string manipulation in C?
Well as you already know, variable length strings ending with a \0 are manipulated using strcpy, strcat, strlen.

Fixed length strings you can manipulate with strncpy and strncat. Note that for strncat(), the length refers to the source, not the destination.
To use these well, you need to store the actual valid length of the string somewhere else.

If you're going to be doing a lot of work with fixed length strings, then perhaps create a little string library of your own based on say

struct myString {
    size_t usedSpace;       // starts off at 0
    size_t availableSpace;  // initialise with the desired max length
    char   *string;         // malloc availableSpace chars for this
};

[CommonTater]

I don't care if it takes 6 to 12 months for me learn how to write the same COBOL functions in C, the software needs it just as much as I need it, and I am somewhat autodidactic, I just need someone to point me in the right direction.

You seem like a smart guy with a pretty good start on your problem. From what you're saying, there's no hard time liimit so perhaps it would be a good idea for you to step back from the actual coding for a day or two and pour through a couple of tutorials on C, as a refresher before you do end up with that chimera Salem warns you about.

I moved from Pascal to C some years back. There were certain key programs in my list that I wanted to rewrite in C so as to keep them up to date. I took in a couple of texts (Teach Yourself C in 21 days, isn't bad) wrote some cold-code to test bits I felt I wasn't grasping and then started off on the rewrites... The one thing I did not do was to try and write direct function by function translations. I wrote equivalent behaviors in C, making improvements along the way, in some cases completely restructuring the code as I went. The result was programs that look alike, behave the same... but (happily) run better than before.

Of course being a few years into C now, I look at those same programs and see other improvements I could have made... so if you've thought "I could have done this better" about your Cobol code... here's your chance.

I don't know if a similar approach will help you... but I thought I'd suggest it just in case...

(From a fellow autodidact)

[AndrewHunter]

...I just need someone to point me in the right direction.

Since you don't mind doing the work of learning C, then may I suggest you take a look at some free tutorials that can be found rather easily around the net:

• CProgramming C Tutorials
• CBoard FAQS
• Teach Yourself C in 21 Days
• Summit C Tutorial

These should get you going in the right direction and give you the ability to convert most of this software over to C.

[OldGeek]

I just looked at "Teach Yourself C in 21 Days", just what I needed, thank you guys, I appreciated it very much. I will also look at the others....

I intend to compile with ANSI compatibility set on, and therefore, always focus on portability. However, whats the general consensus about the portability of C++. Because I am converting from another language, a higher level language, should I use C++ instead of standard C?

Visualizing in your mind, exactly how your going to layout your memory, is crucial in determining how well written your logic will be. It is interesting to think about using a struct to store strings with their length included right along side, something the old Fortran compiler secretly did for you. Is this common in C, does anyone have more in-depth examples of this? I've got other string needs as-well. For example: copying ASCII digits into their binary equivalent, like " $34,564.02". For computational reasons (to avoid floating-point math) I would end up converting this into two separate integers, num1 = 3456402 (extracting only ASCII digits). and numdec = 2, (2 decimal places found based on where the "." was). Then when needed I can convert to float or separate the fraction from the whole number by using a int or float, newnum = num2 / 10 ** numdec.

Cobol can do much of this with a single MOVE statement, for example, copying a PACKED decimal (double) to a ASCII string, char[], in COBOL:

01 ASCIINUM      PIC ---,---,--9.99 VALUE ZERO.    *> 14 byte ASCII data.
01 DECINUM       PIC S9(14)V(4) COMP VALUE 0. *> 64 bit binary data.


       MOVE DECINUM TO ASCIINUM.
       MOVE ASCIINUM TO DECINUM .

The compiler knows how to convert these variables, and yes numeric truncation will likely occur, another case where the compiler must trust the programmer.

That is it! the magic is in the definition of the variables. ASCIINUM is self explanatory. DECINUM defines a signed (S), numeric (9), binary (COMP), with 14 whole numbers, and 4 decimal places, the V is the implied decimal location.

In C I'll probably need to write my own MOVE function. With portability in mind, and open to portable C++, What do using think the most portable C method is, to do the same as MOVE?

Should I look into the string class from C++?

[manasij7479]

Because I am converting from another language, a higher level language, should I use C++ instead of standard C?

I've got other string needs as-well.

Should I look into the string class from C++?

If your code deals with strings too much, I think you'd benefit much from C++'s std::string...(and its stream classes when it comes to manipulating them or for input/output.)

Regarding your MOVE, if I'm not mistaken in understanding its purpose; you could do it with stringstreams in C++.

[CommonTater]

I just looked at "Teach Yourself C in 21 Days", just what I needed, thank you guys, I appreciated it very much. I will also look at the others....

I intend to compile with ANSI compatibility set on, and therefore, always focus on portability. However, whats the general consensus about the portability of C++. Because I am converting from another language, a higher level language, should I use C++ instead of standard C?

(My opinion only...) C++ is a monster, that I found to be heavily cluttered with stuff I won't likely use and a programming paradigm that simply does not in any way resemble how my mind works. Of course you may find a home in it... It's really up to you.

Visualizing in your mind, exactly how your going to layout your memory, is crucial in determining how well written your logic will be.

So long as you don't get lost in the minutae... Most runtimes incorporate their own heap manager and as long as you remember to free() what you malloc() they do a good enough job. What C doesn't do that you may be used to is "Garbage Collection"... in C that's done by hand.

It is interesting to think about using a struct to store strings with their length included right along side, something the old Fortran compiler secretly did for you. Is this common in C, does anyone have more in-depth examples of this?

Not really common at all. It is an option in cases where you have to work with binary data from other compilers and some application software, but where you have the freedom to use C-Strings (char arrays, really) you should take advantage of the wealth of library functions that are well tested and available to you.

I've got other string needs as-well. For example: copying ASCII digits into their binary equivalent, like " $34,564.02". For computational reasons (to avoid floating-point math) I would end up converting this into two separate integers, num1 = 3456402 (extracting only ASCII digits). and numdec = 2, (2 decimal places found based on where the "." was). Then when needed I can convert to float or separate the fraction from the whole number by using a int or float, newnum = num2 / 10 ** numdec.

Wow... hard way! Just work in pennies, using either 32 or 64 bit integers (long int and long long int)... if you scan in a float like 123.67 multiply by 100 and stuff it into an integer as 12367 *pennies*. All your math just got a whole lot simpler and displaying it is easy as pie...

long x = 12367; // pennies

printf("%d.%d", x/100, x%100);

In C I'll probably need to write my own MOVE function. With portability in mind, and open to portable C++, What do using think the most portable C method is, to do the same as MOVE?

It would, I think, be a serious error in judgement to try to make the new thing work just like the old thing... most often when doing that the new thing ends up getting broken... (Hense my earlier suggestion of a rewrite, not a mere translation).

[Subsonics]

(My opinion only...) C++ is a monster, that I found to be heavily cluttered with stuff I won't likely use and a programming paradigm that simply does not in any way resemble how my mind works. Of course you may find a home in it... It's really up to you.

It does however include far easier to use, and safer string handling functions. And you could potentially choose just a small subset of C++ and ignore the rest (even the OOP stuff).