|
Java for COBOL programmers 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. Lets 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 Ill see if I can describe it.
Essentially you would create an 01 record structure, but it
wouldnt 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). 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 dont 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 dont have
space to get into a whole lot more on the topic, but I will show you
an example from Mikes 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 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 Mikes session, and she was pretty resigned to having to deal with COBOL and Java co-existing. I personally dont 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, Im glad I didnt 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 isnt a bad idea to pad the old
resume with Java, but its 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
youll hear my opinions on the next proposed COBOL standard,
which includes Object-Oriented extensions. Copyright The 3000 NewsWire. All rights reserved. |