Click here for Minisoft sponsor message

The future of COBOL II on MPE/iX

By Shawn Gordon


Welcome to Inside COBOL. In this space I’ll cover news and techniques to help you get the most productivity out of COBOL on your HP 3000s. We’ll be discussing COBOL II most of the time, but from time to time I’ll also branch out to some of the other COBOLs available on MPE/iX: MicroFocus and AcuCobol, to name a couple.

There was to have been another COBOL for HP 3000 users, but we got word otherwise from SIGCOBOL meetings at HP World. Since this spring there’s been talk about Fujitsu’s PowerCOBOL becoming the official COBOL compiler of the HP 3000. Sadly, it appears it is not to be. Here is what I found out from the horse’s mouth.

According to Chuck Townsend at Fujitsu, they needed HP’s help, but the kind of help they needed was beyond what HP was capable of providing. Fujitsu just doesn’t have the MPE expertise to make it happen. The US arm of Fujitsu has been looking for alternatives to be able to support the MPE platform, but Fujitsu Japan is holding back at this point in time. Given the recent surge in support for the 3000 that HP is showing, we might find that the two companies are able to work something out. I think it would probably have to be a matter of one or two of the HP 3000 COBOL lab folks going to work for Fujitsu to make it happen.

	HP finally realized that they had enough user input to seriously look at enhancing their COBOL product for the new standard. However, HP has said that they will only implement the bits that users are asking for

According to Kriss Rant at HP’s CSY division, Fujitsu was moving at a glacial pace, and they were hoping for a quick and easy solution that they didn’t have to worry about too much. HP finally realized that they had enough user input to seriously look at enhancing their COBOL product for the new standard.

However, HP has said that they will only implement the bits that users are asking for. This list is up in the air, but at the moment HP will be solely responsible for COBOL updates. I will give you a full feature list when I have it. This means that we will probably never see the new object-oriented extensions to the language, but we can continue to hope and ask until HP either says yes or no. A simple example of how you might code the object-oriented extensions is that you could create code that literally said “DEPOSIT AMOUNT TO ACCOUNT,” and the DEPOSIT function would know what to do with AMOUNT and ACCOUNT. The standard is still being finalized, so I will report more extensively on it as it is frozen.

We are getting two minor improvements in the Express 3 release of MPE/iX 5.5. The first is that the internal data structures of the compiler have been expanded to allow compiling significantly larger programs. There are no specific limits, but a source file in excess of 100,000 lines will be possible. This is really only going to apply to people who build really huge source files, or possibly to using the sub-program within the same source feature. I can’t imagine having to deal with a program that large, and I don’t know what the current limit is, since it depends on how many variables you are declaring and such.

The second improvement is that the compiler can now detect whether the file is in Qedit format, when Qedit has not been installed on the system. You will now get a “QEDIT FORMAT ENCOUNTERED FOR FILE” error instead of some bizarre message that doesn’t make sense. This may seem trivial, but there are a lot of Qedit shops out there, and this could save a lot of grief.

Since I was just talking about Fujitsu, I want to touch on a couple of their new products as well. The first is very exciting, and is in limited release as I write this (late October ‘97). The product is called NetCobol, and what it does is translate COBOL source into Java byte code. This means that the Java world is now opened up to COBOL developers (as long as it works 100 percent). This is actually an interesting concept. It means that you could just have Java byte code generators for languages like Visual Basic, Pascal or C++. This is really like what you have when you compile a program: it all gets translated to machine code regardless of the language used to create it, but in this case you are generating byte code that can be recognized by the Java Virtual Machine (JVM).

The advantage to us 3000 folks is that you could sit there in Windows, writing COBOL code to generate Java byte code that ran on the 3000. You could then use the Just In Time (JIT) Java compiler from HP to compile the Java code on the 3000. Then you could leverage that same byte code over to your 9000, NT or Mac system, even if you started out in COBOL.

I really like this NetCobol idea. I have spent a little time in Java, and quite frankly I am getting tired of learning new low-level languages like Java. I would love to be able to apply my COBOL skills in this fashion. I don’t have a lot of information on this yet, but I will share it when I get it.

The second product I’d like to mention from Fujitsu is the new 32-bit release of their PowerCOBOL product for Windows 95/NT. The product has been reworked to look more like Delphi or Visual Basic, and they have implemented support for OCX controls. I can’t wait to get my hands on it and see if it satisfies the “dream.” This doesn’t have any direct bearing on the 3000 market – other than it might make it possible for you to easily leverage your existing skills to write Windows-based applications, or client/server applications without having to learn Visual Basic, Delphi or C++.

Remember, this is your space too. If you’ve got a tip or COBOL trick, send them to me at smga@compuserve.com, or fax them to the NewsWire at 512.331.3807. Tips selected win a free NewsWire Always Online cap, and if that isn’t incentive then I don’t know what is.