Click here for Technical Directions sponsor message

Fujitsu PowerCobol: An HP 3000 Aid

By Shawn M. Gordon

This month we are going to go down a slightly different road and look at the Windows-based product PowerCobol, from Fujitsu Software. You may recall that I reported Fujitsu had been in serious talks with HP to let its PowerCobol become the main HP 3000 COBOL compiler. Talks were quite serious and extensive; however Fujitsu lacked the 3000 expertise, and HP was unable to lend it out to make the project a reality.

Despite the blind alley, The PowerCobol environment is still very useful for HP 3000 COBOL development. I decided to do some hard core proof-of-concept work on this with the recently released version 4. Since I already had the ODBC/32 driver from Minisoft, it seemed like a perfect opportunity to see if I could drag the rest of I.S. into client-server – without using Visual Basic, and dealing with that learning curve.

Take a look at Figure 1, an example of the forms designer where you can place your fields and buttons and such. The funky circle in the upper left corner is a data access control. This is where it gets to be fun; we just select ODBC as the data source, and pick a configured database. I chose one of my HP 3000-based IMAGE databases, and I was then given a pick list of data sets. From there you can pick the items, and put selection criteria on each one. Take a look at this issue’s ODBC/32 TestDrive for some of those screen snapshots.

Figure 2 shows that with the PowerCobol project manager, unlike VB or Delphi, you can’t just double click on a control to add code – you have to do it in the project manager. What’s interesting is that each control on the form, and the form itself, is essentially an entire COBOL program. You can code each of the divisions, declare variables as global or local, put in record structures, file I/O – whatever.

In my example program I want to let the screen either do a serial read on the database, or use the key value if it is entered. So the logic that is in the RETRIEVE button is shown in Figure 3, below.

Figure 3

ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 SELECT-STRING.
03 SELECT-TEXT PIC X(09) VALUE “STATE = “.
03 SELECT-TEXT-2 PIC X(02) VALUE SPACES.
PROCEDURE DIVISION.
IF DB-STATE-FLAG Not EQUAL 1
INVOKE CmDB1 “OpenDB” RETURNING RETURNVALUE
MOVE 1 TO DB-STATE-FLAG
INVOKE CmDB1 “SelectRecords” RETURNING RETURNVALUE
END-IF
IF “Text” of STATE Not Equal SELECT-TEXT-2
MOVE “Text” OF STATE TO SELECT-TEXT-2
MOVE SELECT-STRING TO “Condition” OF CmDB1
INVOKE CmDB1 “SelectRecords” RETURNING RETURNVALUE
END-IF
* read the next record and move its contents to the form
INVOKE CmDB1 “ReadNextRecord” RETURNING RETURNVALUE
MOVE “STATE” OF CmDB1 TO “Text” of STATE
MOVE “STATE_NAME” OF CmDB1 TO “Text” OF NAME
MOVE “STATE_FLAGS” OF CmDB1 TO “Text” OF FLAGS
MOVE “STATE” OF CmDB1 TO SELECT-TEXT-2

The name of our data access control is “CmDB1” and each of the data items is a property of the control. I have a global variable that I use to keep track of whether the database is open or not. This controls if we open the database when we go to read.

PowerCobol will allow you to code SQL statements directly if you want, but by using the methods of the data access control, you get an environment that is easy to equate to IMAGE. We have “OpenDB” just like DBOPEN, the “SelectRecords” is like DBFIND, and “ReadNextRecord” is like DBGET.

There are a few things that I found strange about PowerCobol, but I didn’t make an exhaustive review of it. First, the Combo Box control can only be loaded from a file, so if you wanted to dynamically get a list out of a database and load the control, you would first have to write it to a file. You can use a third-party OCX control if you want, which doesn’t require this to get around the problem.

There also doesn’t appear to be a way to bind a field from a data access control to a field on the screen, so you are always stuck with “MOVE ‘ITEM’ OF BASE TO ‘TEXT’ OF FIELD”. The upside to this is that it is displayed on the screen at the same time, so there is only one command to set and display the information.

My final complaint has to do with the actual COBOL syntax. COBOL 85 supported the use of things like ‘<>, >=, <=’ in IF statements, but PowerCobol forces you to say “NOT EQUAL” instead of “<>”.

I spoke extensively with Fujitsu during their first release of 16-bit PowerCobol two years ago, and told them then that they should just copy the Delphi interface, since that was what Visual Basic was starting to do. The software looks pretty much like a cross between Visual Basic 3 and Visual C++. This isn’t necessarily bad, but it still leaves them behind the more mature tools. In this fourth release of the product, I would have hoped that they would have tried to leapfrog the competition.

Even with all that said, Fujitsu can hardly keep any of the product in stock, the demand is so high. The learning curve is pretty light, and by using something like ODBC/32 from Minisoft you are able to quickly and easily build client-server applications in a language you are familiar with. I am very excited by this combination, and am currently planning on using it to replace all of the QUICK screens on a re-engineering project I am working on. If you want to find out more, or order a demo from Fujitsu, you can check out their Web site.

Well, that wraps it up for this month. Next month I am really going to get around to COBOL macros, or you I owe you all a round of drinks. Keep those cards and letters coming, and earn yourself a free 3000 Always Online hat for tips you submit – either to the NewsWire or to me at smga@compuserve.com.

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