SW Consulting Sponsor Message
			Back to News Page

I want to revisit a topic we went over about six months ago, namely how to use the new IMAGE b-trees from COBOL. I have been making extensive use of the feature since before I covered it last time, and I have since uncovered some potential pitfalls you can avoid while using the new feature in your COBOL programming.

First. let’s recap the DBFIND modes that are now available using b trees:

Mode = 1. Do a standard DBFIND, unless BTREEMODE1 is on for the database, and there is a wildcard in the argument — then do a b-tree lookup.

Mode = 4. Do a b-tree find with accurate chain counts using the complex form of the argument parameter.

Mode = 10. Do a non b-tree DBFIND, mode 1 equivalent.

Mode = 21. Same as mode 1, but is high speed and doesn’t return accurate chain counts.

Mode = 24. Same as mode 4, but is high speed and doesn’t return accurate chain counts.

For example, say you are reading down a chain of orders from a customer master on the customer number. Now for each order you must read the ship-to information from a detail set that is also hung off of the customer master. Under normal circumstances, IMAGE will keep track of the chain pointers for you if you use different status arrays. Worst case, you can save the record number in the first chained read, do a DBGET mode 4 with the relative record number, then start doing DBGET mode 5 reads to pick up where you left off.

Now picture this under a b-tree scenario. Say your key into order detail is comprised of customer number + order number. You do a b-tree read with just customer number and an @ sign in the order number. Now for the sake of argument, say that your shipping information set has the same key structure going to the same auto master as the order detail. What happens?

Well the pointer into the “super-chain” is kept in the run time control block of the master, so if you start another read using the same master, this area will be reset. Because it’s a super-chain, and not a conventional chain, you cannot use the DBGET mode 4 trick. More importantly, saving the status array will do no good either; the pointers have been lost.

How do you work around this? There are really a couple of options that don’t require redesigning the database. The first option is to read out all of your key information from the first set into an array or a file, and then read against the second set with the information from the file.

The second option is to open the database another time for each time you are going to read down the same chain in your program. Each open will maintain a separate run time control block, so your pointers will always be maintained. While this may not be as elegant as you might like, it’s worth it to take advantage of the b-trees.

Just remember that using b-trees takes thinking a little differently about how to retrieve data than you might be used to. Who ever thought we would be doing DBFIND on manual master sets?

I’d like to add a final note on the long term viability of COBOL itself (picture me standing on a soapbox). There was recently a barrage of messages on the 3000 list about languages and COBOL. Apparently yet another magazine was touting the demise of COBOL as a language. Last I checked, COBOL was still the number one development language (followed very closely by Visual Basic), and there are now something like 4 billion lines of code out there in use. The college near my house has dropped C++ and is now teaching COBOL again.

So what does this mean for the long-term viability of the language? Well the new Object Oriented COBOL should hit the streets in the next couple years. The major COBOL vendors like MicroFocus, Acucobol, Liant, and Fujitsu have been making dramatic improvements to their products for Windows development and Web CGI processing. Synkronix is distributing their COBOL to Java IDE/translator, which I will be covering soon. All this Y2K work has gotten people back into COBOL. It’s doubtful that companies will have spent all that money getting their COBOL applications Y2K compliant only to throw it out as soon as the new century is here.

I think COBOL will remain a major player in the business development environment for many, many years to come. So be proud — wear your pocket protector with honor and proudly proclaim your undying love of COBOL to those around you.

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