|Click here for Technical Directions sponsor message|
Fujitsu PowerCobol: An HP 3000 Aid
By Shawn M.
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 issues ODBC/32 TestDrive for some of those screen snapshots.
Figure 2 shows that with the PowerCobol project manager, unlike VB or Delphi, you cant just double click on a control to add code you have to do it in the project manager. Whats 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.
03 SELECT-TEXT PIC X(09) VALUE STATE = .
03 SELECT-TEXT-2 PIC X(02) VALUE SPACES.
IF DB-STATE-FLAG Not EQUAL 1
INVOKE CmDB1 OpenDB RETURNING RETURNVALUE
MOVE 1 TO DB-STATE-FLAG
INVOKE CmDB1 SelectRecords RETURNING RETURNVALUE
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
* 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 didnt 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 doesnt require this to get around the problem.
There also doesnt 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 isnt 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 firstname.lastname@example.org.
Shawn M. Gordon, whose S.M. Gordon & Associates firm
HP 3000 utilities, has worked with 3000s since 1983.
Copyright 1998, The 3000 NewsWire. All rights reserved.