Review of PowerCOBOL
by
Shawn M. Gordon
President SMGA

Introduction

It was with great anticipation that I waited for the software that is the subject of this month’s review. When I was at HP World in August 96 I happend by the Fujitsu booth, and was amazed to discover that Fujitsu is apparently a pretty large COBOL compilier vendor. I was even more suprised to see that they had an MS Windows based RAD (Rapid Application Development) tool like Delphi and Visual Basic, that TRULY used COBOL as it’s language, totally. For anyone that know’s me, you know how I
love COBOL, and been wishing for this kind of tool. I was practically droolling looking at it, but I did try to contain my enthusiasm until I was able to work with the product, so I requested a copy, which I received a few weeks later. I had to finish up some other reviews first, so it was a little while before I was able to really sit down and work with PowerCOBOL, but I finally did, and here is the result.

I tested the product on my 133Mhz 486 with 16 meg of RAM and 1.5 Gb of disk. I was running under Windows 3.1, but it is also supported on Windows NT and Windows 95.

Features

You will immediatly notice that PowerCOBOL has a similar interface to VB and Delphi, I wish they had actually looked at these products and done a little more copying of the interface styles. In Figure 1 you will see a sample project and most of the windows that you will use for your code. In the upper left side of the screen is the ‘toolbox’ this contains a pallette of all the objects that you can use to design your project, things like buttons, spreadsheets, labels, combo boxes, etc. The only real problem here is that the tool box is currently un-extendable, in other words, you cannot plug in any tools that didn’t come with the product. I am told support for ActiveX controls will be included early next year.

So you have an idea for a project, and now you start laying out the interface the way you want it to look. Once you have your controls layed out, you will go behind the event for each object and enter your code. A description of this process is next.

Figure 2 is going to illustrate a couple of things. First you notice that each procedure for an event will have an Environment Division, Data Division, and a Procedure Division. These divisions are also globally available at the SHEET level (PowerCOBOL calls them SHEET’s instead of FORMS like in VB and Delphi). If you want to declare local variables, you would do your standard COBOL style variable declarations in the Data Divison. If you want to do file I/O at an event level, then you can specify your file parameters in the Environment Division, and then code your OPEN, READ, and CLOSE inside the Procedure Division.

You’ll notice the code in the example, in this particular example we are working on the Menu item ‘Bitmap’, selection ‘Pattern 1’ on the ‘Click’ event. So when the user clicks on Pattern 1, this code will ‘MOVE “PTN1” TO POW-IMAGENAME OF IMAGE1’, then ‘MOVE “PATTERN 1” TO POW-TEXT OF LABEL1’. I have also added a third line to illustrate the error handeling of PowerCOBOL. If you are running in Interpreted Mode, then you won’t get an error until you try to execute the code, if you are
running in Compiled Mode, then you will get an error during the compile. The window next to the code indicates what the error is, what line the error is located on. Now this is kind of strange, but sometimes there are line numbers in the code, and sometimes there isn’t, and I couldn’t figure out how to turn it on and off. See Figure 3 for an example of the program running.

Now let’s explain what is happening. If you look at table 1, you will see a list of object attributes that can be manipulated for the IMAGE object. It just so happens that we took the default name of the object, IMAGE1. You will also notice in the project list on Figure 2, that we have PTN1.BMP, PTN2.BMP, PTM3.BMP, this allows us to easily reference the object. So in the first line of code, we are moving an object, PTN1 to the attribute POW-IMAGENAME of object IMAGE1. This should make the second line of code rather self explanatory. The only real difficulty here is learning what all the attribute names of the objects are, because unlike Delphi and VB, there is not an object attribute menu where you can set these values, as far as I can tell you have to do them all manually.

Table 1

Attribute Name  Value  Edit reference or setting
 POW-POSITION    X(8)         Position
 POW-BACKCOLOR   X(4)         Background color
 POW-VISIBLE    S9(4) COMP-5  Visible
 POW-ENABLE     S9(4) COMP-5  Enable
 POW-BORDER     S9(4) COMP-5  Border
 POW-IMAGENAME  X(128)        Image name
 POW-IMAGEMODE  S9(4) COMP-5  Image mode
 POW-IMAGESIZE  X(4)          Image size
 POW-IMAGEPOS   X(4)          Image position
 POW-PRNENABLE  S9(4) COMP-5  Printing enable

It’s rather interesting to see object attributes described in COBOL variable terms, but it is also comforting, you feel a little closer to what is going on. It’s a good thing that the COBOL Object Manual is so well written, because you are going to need to refer to it quite a bit during the learning process.

Usability (also installation)

The software is distributed on a CD-ROM, and uses a standard Windows installation procedure. There are a couple of steps involved, first you install the PowerCOBOL software, then the Common Ground document viewer. Common Ground is similar to Acrobat, and is pretty straight forward to use.

The software is about as easy to use as any other RAD tool. There is a moderate learning curve to get use to their idea of how things should work, but PowerCOBOL is similar to VB 3.0 in a basic way, so you shouldn’t spend more than an hour or two getting the feel of it.

Reliability

The PowerCOBOL environment works very well, there were no aborts, or GPF’s, all the options work without error. The code generated also works very well, I didn’t really try to do anything like cause cascading events, so I’m not sure how it would handle that, but the standard error checking is pretty
good.

Performance

What’s really nice about PowerCOBOL, unlike either VB or Delphi, is that it can run in interpreted mode, or generate a TRUE executable, not P-Code, which will then run under the environment. So when you are developing you will probably want to run interpreted for convenience. When you do compile you will notice that it’s pretty darn quick, I don’t think it’s quite as quick as Delphi, but I think it’s better than VB.

Supportability (including Doc)

My biggest problem with the documentation is that it is all in electronic format, I like having a book I can leaf through and leave open, but I like the search abilities in electronic documents as well. The Quick Start guide is pathetic, I spoke with Fujitsu about this, and they agreed, and are putting together something better. The e-doc is very good for the most part, but there is so much of it you really have no idea where to begin, I finally had to call and ask. Once I knew where to start, it was fine, hopefully they will be including a little map for the documentation in the future.

As far as support, well I kept getting calls from people checking to see how I was doing, and I would call them back and leave voice mail about my problems with the doc, and then no one would call me back about my problem. I finally called the product manager directly, and he was very gracious and did a walk through with me on the phone, you aren’t going to get that from Borland or Microsoft, that’s for sure. So I started off very upset about the support, but ended up being very impressed
with how things were handled.

Summary

So what do we have here? We have a RAD environment whose language is totally in COBOL, very cool. We have a COBOL environment that generates true executables and has no run time license associated with it, also very cool. We also have it priced very competitivly, best of all. I am very excited about the potential of PowerCOBOL, but the functionality isn’t quite there yet for the projects that I would like to use it on, I think it will be there by 1st or 2nd quarter of 97, but it’s not quite there yet.

I think PowerCOBOL is on the right track, but they are a bit behind the curve. They have to support ActiveX (OCX) controls as soon as possible to really make the environment a serious development tool. The smartest thing they did in VB was add the VBX concept at the last minute, without that the product would never have done as well as it did. The interface needs to rip off what is going on in Delphi as well, it still looks very young right now. I spoke with them on all of this, and these are all things that they are working on, and hopefully will only be a few months off by the time you read this.

Anyone doing COBOL, who hasn’t gotten on the VB bandwagon yet (or even if you have), should check this out. Pushing for VB at your site is usually good for resume building, but if you want leverage a huge base of existing programmers (COBOL), you might find that PowerCOBOL is good enough for you now, and is only going to get better with time.

At-a-Glance box

PowerCOBOL version 2.0 L 11
Fujitsu Inc.
3055 Orchard Dr.
San Jose, CA 95134-2022
408-432-1300
FAX 408-428-0600
Email: cobol@adtools.com
Web: www.adtools.com

Call, write, FAX, e-mail or visit their web site to order, or for more information. List price is $500 for PowerCOBOL, $750 for COBOL 85, and the Professional editions is $1,250. Support subscription $250 for PowerCOBOL, $250 COBOL 85, $500 for Professional edition. Discounting is available for everything. Documentation is all electronic and is at least a few thousand pages.