Search This Blog

Friday, October 30, 2009

Understanding COBOL for .Net Data Types

How many feel like maybe you must of drank those 99 bottles of beer?  Head spinning like a top?

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 latin errr COBOL for .Net.  How you ask?

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  
So, when you see a line of code in a COBOL for .Net program which looks like this:


You can translate it to what you are familiar with:

01  WS-VAR1  PIC S9(4) COMP-5.

Simple enough huh?  *smile*
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:


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

These "new" data types have some pretty interesting features which you will want to look at.  And believe it or not, I think you might find them handy.  First we will take a look at the COBOL data type of "character".  Character is for defining and storing a single character of data.  That's it.  Nothing more to it. 

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.

In the COBOL for .Net world, you would use the data type "string" for storing text, that is, a number of characters. Just like in C#, a COBOL string is immutable (say that fast 5 times), which means that a string is never changed after it has been created. When using routines which change a string, the actual string is not changed - a new string is returned instead.


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:


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.


Same thing with the statement above.  Cool stuff huh?

Next up, an item I think long over due,  the boolean variable type "condition-value".

01  WS-TRUE-FALSE-FLAG                 PIC X(01).
      88  WS-TRUE                                    VALUE "T".
      88  WS-FALSE                                  VALUE "F".

With the "condition-value" this same statement could be done a bit differently.


To reference WS-TRUE-FALSE-FLAG in your program you just check to see if it is True or False.

The "decimal" data type is interesting to me due to it's versatility.  How often have you needed to define a field in Working-Storage to hold a number, but did not know how large the value might be?  Some would probably claim "poor design" but what if the size could not be predicted?

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.

There are of course several restrictions on the usage of these new data types that you'll need to read up on.  You can find out the real nitty gritty in this online documentation.

So, if you revisit the code sample that Alex provided, you'll see a couple of things which may make a bit more sense now.  At least in the variable declarations portions anyway.

We'll get more into the other items another day once this soaks in.  ;)

Any questions?

Wednesday, October 21, 2009

Doing The Waltz

What a great post on dancing COBOL. Here is some more COBOL dancing to build on the idea. Recursion, local scope, classes and beer all in the same program!

Thanks for the mention of the 99 bottle code Robert. I saw your post and thought I should raise the bar. I few comments on my post on 99 bottles (here) suggested that local variable scope, recursion and other cool stuff is missing from COBOL. Totally untrue! Here is a COBOL program which shows off the new 'quoteless' type syntax which we are working on and at the same time shows off a few of the OO features in the standard Micro Focus COBOL for .net product which is already out there:

$set sourceformat(free)

class-id. "Singer".

method-id. "main" public static.
procedure division.
invoke type Singer::SayLine(by value 100)
end method "main".

method-id. "SayLine" public static.

01 bottle-word string.
01 count-word string.

procedure division using by value bottles as binary-long.
if bottles equals 0 then
display "Go to the store and buy some more, 99 bottles of beer on the wall."
add -1 to bottles
evaluate bottles
when 0
move "No" to count-word
move "bottles" to bottle-word
when 1
move bottles to count-word
move "bottle" to bottle-word
when 2 thru 99
move bottles to count-word
move "bottles" to bottle-word

if bottles not equals 99 then
display "Take one down and pass it around, " count-word::"ToLower"()
" more " bottle-word " of beer on the wall."

display count-word " " bottle-word
" of beer on the wall, " count-word::"ToLower"()
" " bottle-word " of beer."

invoke type Singer::SayLine(bottles)
end method "SayLine".

end class "Singer".

As you can see, this is a pure recursive implementation demonstrating the local scope of the method variables.

Tuesday, October 20, 2009

Making COBOL Dance!

Hey folks!

When was the last time you learned something new about COBOL?

Yesterday?  Last week?  A year?  Ten years ago?

A fair question that I believe every single developer should seriously consider.  I'm betting that the average COBOL developer hasn't spent much time learning "new" things about the language they have made their living supporting or writing.  However, you ask someone who is writing C#, Java or VB.Net applications and they will probably point to the three or four books on their desk which they refer to on a fairly regular basis.

Why is this?

Any professional in IT will tell you that the one thing that stays the same is the fact that technology continues to change.  And that to stay current or marketable in their role, they have to constantly expand their knowledgebase.

So, why is it that the typical COBOL developer seems to stick with the version of COBOL they learned in college?

I would like to issue a challenge to you.

I challenge you to learn COBOL, specifically object oriented COBOL and or COBOL.Net.

I can count on both hands the number of people I personally know who are proficient with this single most significant exstension to the language.   Ever since Grace found her first bug people have been making COBOL dance.  My question to you...

Learned any new steps lately?

You've seen the code sample Alex posted showing how to solve the 99 Bottles of Beer programming puzzle.  Pretty slick stuff huh?  Even remotely curious?  Could it be time to revisit COBOL and expand your knowledge?

Here is a very straight forward online tutorial on the subject to get you started.

Additionally, Rick Malek has been an avid poster of articles for years out on C# Corner which are intended for the C# developer to understand COBOL.Net.  Take a look at his examples for an introduction into some of the things you can do with COBOL and .Net above and beyond what you probably know today.

 "Ah, but Robert, there are only a handful of books on the subject...".  Yep.  I noticed that as well. 

Hmmm... I wonder how those other books got written?  Think they just copied what someone else wrote?  Nah, they dug into the subject material, made themselves experts, and then decided to put their knowledge down on paper.  Seems to me with the sheer number of COBOL developers out there, there could be a decent market for a new book or two.  Any aspiring authors out there?

Ok.  The challenge has been issued.  *grin*

Any questions?