| Front Page | News Headlines | Technical Headlines | Planning Features | Advanced Search |
HP Sponsor Message

     

Java for COBOL programmers

By Shawn M. Gordon

Well, HP World was a lot of fun. It was good getting to chat with everyone and meet 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 was that he needed about eight hours instead of one 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. 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 suspiciously 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 one sub-program to be like another without actually coding it. You can also think of an object as a template declaration. There is no equivalent 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 Mike’s talk thinking two things: Java is still a heck of a lot like C++ from what I remember while using C++, and Java is just as bad for business application development as C++. SIG-COBOL chair Jeanette Nutsford and I talked about it after Mike’s session, 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 most of us will ever have to deal with.

I remember 10 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 heard 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 six 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 simply ran into 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 wanted 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 the old resume with Java, but it’s just not a 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.

Okay, next month you’ll hear my opinions on the next proposed COBOL standard, which includes Object-Oriented extensions.

Shawn Gordon, whose S.M. Gordon & Associates firm develops HP 3000 utilities, has worked with 3000s since 1983.


Copyright The 3000 NewsWire. All rights reserved.