COBOL? That can't be COBOL code Alex posted. Or is it?
My favorite email on Alex's post had a comment which I'm sure applies to many
"...if that is COBOL, I'm in deep !#$!"
Well, I have good news and bad news. Good news is that it is COBOL.
Or was that the bad news? *grin*
Never fear. You too can read and write
Well, let's start at what I consider the basics (some may argue), data types.
All of us are familiar with the syntax of defining COBOL variables using things like PIC X(11) and PIC S9(04) COMP, etc. For instance, defining a COBOL variable containing a string of text is as simple as:
01 WS-VAR1 PIC X(11) VALUE "HELLO WORLD".
More good news... In the COBOL of today, this still works just fine. However, to facilitate working in the .Net world, a few new data types have been added to the language. I've listed them out below, along with their corresponding COBOL equivelant.
- binary-char ---> PIC S9(2) COMP-5
- binary-char unsigned ---> PIC 9(2) COMP-5
- binary-short ---> PIC S9(4) COMP-5
- binary-short unsigned ---> PIC 9(4) COMP-5
- binary-long ---> PIC S9(9) COMP-5
- binary-long unsigned ---> PIC 9(9) COMP-5
- binary-double ---> PIC S9(18) COMP-5
- binary-double unsigned ---> PIC 9(18) COMP-5
- float-short ---> USAGE COMP-1
- float-long ---> USAGE COMP-2
- object ---> USAGE OBJECT REFERENCE
01 WS-VAR1 BINARY-SHORT.
You can translate it to what you are familiar with:
01 WS-VAR1 PIC S9(4) COMP-5.
I believe these new data types were created to help you and I make sure we move the data into the right field with the proper sizing already figured out. I can recall quite a few times where I was trying to mix languages such as C and COBOL and having to manually write what I called a bridge routine to convert a C data type to fit into the appropriately defined COBOL variable. With these new data types, the guesswork is taken out of it. Working with a C# binary long field and need to call a COBOL program? Not a problem. Just use a COBOL variable defined like so:
01 WS-VAR1 BINARY-LONG.
and then call your COBOL program passing it the data from the C# routine to the COBOL program appropriately (Rick covers the how on some of his postings).
Ok, now for the twist... There have also been a handful of new data types added which just didn't exist in the COBOL of yesteryear. I've listed them below and their equivelent C# data type.
- character ---> char
- condition-value ---> bool
- decimal ---> decimal
- string ---> string
But what if you need to define a string of characters? Traditional COBOL would maybe have you put something like Character(11) or some such together. That would require you to know how many characters you wished to store in the field. So, toss that out.
01 WS-VAR1 STRING
Several of you are probably thinking "But what about an internal table" and how does it work. That is straight forward as well, probably even better than you would expect. Take a look:
01 WS-ARRAY-OF-LONGS BINARY-LONG OCCURS ANY.
This statement declares a table or array (a better description) of Binary-Longs, but notice the word ANY appearing at the end. This allows the length/size of the array to be decided at runtime.
01 WS-ARRAY-OF-STRINGS STRING OCCURS ANY.
Same thing with the statement above. Cool stuff huh?
Next up, an item I think long over due, the boolean variable type "condition-value".
To reference WS-TRUE-FALSE-FLAG in your program you just check to see if it is True or False.
By using a "decimal" data type, you are defining a 128 bit variable to represent values within the range 1E-28 to 7.9E+28. I believe the decimal data type was specifically created to deal with decimal values when dealing with money.