Inside COBOL #66 (Java for COBOL programmers)
by
Shawn Gordon
President
The Kompany
Well HP World was a lot of fun, it was good getting to chat with everyone and meeting some new people. COBOL was not well represented at the conference, but Mike Yawn from HP (the guy who ported Java to the 3000) gave a very good talk on explaining Java to COBOL programmers. I would say that the biggest problem with the talk is that he probably needed 8 hours instead of 1 hour. Mike did an excellent job of explaining some basics and getting across the general paradigm differences in the short time he had. Actually for a hard core lab rat Mike does an excellent job as a speaker.
In any case I am going to regurgitate just a bit of what Mike went over in his talk to give you an even slimmer idea of what Java might mean to you. I will wrap up with some comments and observations.
Let’s go over the concept of an Object first. An object can initially be thought of as an 01 level record declaration in COBOL. However it can also contain code as well as the record definition. This code can contain different methods, essentially mini programs inside the class. It sounds suspeciously like a good old sub-program, and the methods would be entry points into the sub program. In a sub-program you have local variables and you are hiding the data that is being worked on.
The biggest difference is that you cannot inherit from a sub-program, and you cannot declare another sub-program to be like another one without actually coding it. You can also think of an Object as a template declaration. There is no equivalant concept in COBOL, but I’ll see if I can describe it. Essentially you would create an 01 record structure, but it wouldn’t actually exist until you declared another one to be of the same type, so something like:
01 CUST-MAST-FORMAT 03 CMF-CUST-ID PIC X(06). 03 CMF-CUST-NAME PIC X(30). 01 CUST-MAST AS CUST-MAST-FORMAT. 01 HOLD-CUST-MAST AS CUST-MAST-FORMAT.
Then in the PROCEDURE DIVISION you would have to reference the variables like this:
MOVE CUST-MAST.CMF-CUST-ID TO HOLD-CUST-MAST.CMF-CUST-ID.
Of course the ‘AS’ and the ‘.’ Formats are my personal invention and don’t exist in COBOL, and never will as I described them here (next month we are looking at the new Object Oriented COBOL standard). Hopefully this will illustrate the concept of template declarations.
I actually don’t have space to get into a whole lot more on the topic, but I will show you an example from Mike’s talk showing a COBOL record structure and one way to declare it in Java (I fixed the COBOL example a bit).
01 EMPLOYEE-RECORD.
03 EMPLOYEE-NUMBER PIC X(08).
03 FIRST-NAME PIC X(20).
03 LAST-NAME PIC X(20).
03 PAY-METHOD PIC X.
03 SALARY-INFO.
05 ANNUAL-SALARY PIC S9(6)V99 COMP.
05 PIC X(12).
03 HOURLY-INFO REDEFINES SALARY-INFO.
05 HOURLY-RATE PIC S9(4)V99 COMP.
05 HOURS-REGULAR PIC S9(4)V99 COMP.
05 HOURS-OVERTIME PIC S9(4)V99 COMP.
05 OVERTIME-RATE PIC S9(4)V99 COMP.
03 COMMISION-INFO REDEFINES SALARY-INFO.
05 COMMISSIONED-SALES PIC S9(7)V99 COMP.
05 COMMISSION-RATE PIC S9(2)V99 COMP.
05 PIC X(10).
Public class Employee {
Private string employeeNumber;
Private string firstName;
Private string lastName;
}
Public class SalariedEmployee extends Employee {
Private float annualSalary;
}
Public class HourlyEmployee extends Employee {
Private float hourlyRate;
Private float hoursRegular;
Private float hoursOvertime;
Private float overtimeRate;
}
Public class CommissionedEmployee extends Employee {
Private float commissionedSales;
Private float commissionRate;
}
I walked away from Mikes talk thinking two things. Java is still a heck of a lot like C++ from what I remember, and Java is just as bad for business application development as C++. Jeanette Nutsford and I talked about it after the talk and she was pretty resigned to having to deal with COBOL and Java co-existing. I personally don’t know that this is even an issue that most of us will ever need or have to deal with.
I remember ten years ago I was looking at C and Pascal trying to decide which way to go and I decided on C (boy I’m glad I didn’t pick Pascal). While reading through C books I head about this new thing called C++ which I also read up on. Now I was hot and heavy into this whole C and C++ thing and was ready to rewrite all my COBOL. I got the CCS C compiler for MPE V and started to write some apps with all the fervor of a person who just quit smoking.
After 6 months of this I noticed that all of my stuff in C was longer, harder to read and ran slower than my COBOL programs. It was at this point I started thinking about what was the best tool for a job. A couple years later VB 1.0 came out and I immediately bought it and eventually started to develop commercial applications in VB 2.0 and on. Again I ran in to the best tool for the job syndrome. Every time I started to write a DOS or Windows app I longed for COBOL and/or Image, nothing else was giving me what I truly needed.
What does this have to do with anything? Well I want to illustrate that I have some background with this stuff. Java is basically C++ without some of the confusing bits like pointers, and has added more primitive variable types for declarations. It sure isn’t a bad idea to pad ou the old resume with Java, but it’s just not a real good business language. I usually work in several languages, the ones that I build my products in that I know are the best for the job, and the ones that people pay me to develop in. PERCobol appears to be an interesting compromise in that you code in COBOL and it deploys in Java. I should be reviewing it by the end of the year.
Ok, next month is going to be my opinions on the next proposed COBOL standard which includes Object Oriented extensions.