Like Tree1Likes

Converting COBOL to C

This is a discussion on Converting COBOL to C within the C Programming forums, part of the General Programming Boards category; I have lots of COBOL to convert to C, not C++, but standard C. I think I know how to ...

  1. #1
    Registered User
    Join Date
    Sep 2011
    Posts
    10

    Question Converting COBOL to C

    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:
    Code:
     01 NOOP-SW                                   PIC X     VALUE "0".
        88 NOOP                                             VALUE "1".
    So that in the procedure code I would write:
    Code:
     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:
    Code:
     #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:
    Code:
      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.

  2. #2
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,049
    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.

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,761
    > 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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    It's not portable, it's heavy! It will be much so much lighter, if it's transferred over to C. :P

  5. #5
    Registered User
    Join Date
    Sep 2011
    Posts
    10
    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:

    Code:
     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

    Code:
    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:

    Code:
     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.

  6. #6
    Registered User
    Join Date
    Sep 2011
    Posts
    10
    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!

  7. #7
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,761
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  8. #8
    Registered User
    Join Date
    Sep 2011
    Posts
    10
    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.

  9. #9
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,761
    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
    Code:
    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
    };
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  10. #10
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by OldGeek View Post
    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)
    Last edited by CommonTater; 09-04-2011 at 09:11 AM. Reason: typo, typo, everywhere a typo!!

  11. #11
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Quote Originally Posted by OldGeek View Post
    ...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:


    These should get you going in the right direction and give you the ability to convert most of this software over to C.
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  12. #12
    Registered User
    Join Date
    Sep 2011
    Posts
    10
    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:

    Code:
    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++?

  13. #13
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,505
    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++.
    Last edited by manasij7479; 09-04-2011 at 03:01 PM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  14. #14
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by OldGeek View Post
    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...

    Code:
    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).
    Last edited by CommonTater; 09-04-2011 at 04:22 PM.

  15. #15
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by CommonTater View Post
    (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).
    manasij7479 likes this.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Cobol?!
    By cyberCLoWn in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 12-23-2003, 06:23 PM
  2. Cobol!? Why!?
    By carrja99 in forum A Brief History of Cprogramming.com
    Replies: 12
    Last Post: 04-08-2003, 03:44 PM
  3. Cobol
    By ammar in forum A Brief History of Cprogramming.com
    Replies: 19
    Last Post: 02-20-2003, 12:23 PM
  4. cobol
    By Unregistered in forum A Brief History of Cprogramming.com
    Replies: 10
    Last Post: 05-03-2002, 01:02 AM
  5. Cobol
    By Troll_King in forum A Brief History of Cprogramming.com
    Replies: 13
    Last Post: 10-19-2001, 11:50 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21