COBOL TIPS #38
by
Shawn Gordon

Now that we are getting well entrenched into 1997, I think it’s time we talk a bit about the 97 COBOL standard that’s going to be coming out shortly. The good news is that our venerable leaders in SIG*COBOL have actually gone and sat in on the ANSI standards meetings on the new COBOL standard. This means that maybe some of the nifty things that are in HP COBOL, like $DEFINE for macros, could end up in the actual standard. Hopefully it means that HP’s new COBOL will incorporate all the new standards, including the new object oriented extensions.

The word from Jeanette Nutsford, the esteemed SIG*COBOL co-chair, is that COBOL97 is due to be finalized by the end of 97. It could go longer if there is another round of request for comments, this is why our SIG*COBOL has gotten involved with the standards committee, they want to help keep things moving. The reprecussion of this is that no one is going to be able to build a fully complient version of COBOL97 until ’98. However MicroFocus has been jumping the gun for a couple years now for the Object Oriented extensions to COBOL. Speaking of which, I am going to give their Visual Object Cobol another run through here shortly.

While on the topic of Object Oriented Cobol, Jeanette made a recomendation recently for a good book addressing the topic. I will quote her exactly;

“I have just received a copy of a new book recently published called “Standard
Object-Oriented COBOL” by Ned Chapin. It is published by Wiley Computer
Publishing.

This book is a good ‘how to’ guide for COBOL programmers and analysts on
designing applications for implementation in the new ANSII/ISO COBOL. The
author focuses the book on the design process for developing applications in
“O-O COBOL”.

There are 11 chapters:
1. The COBOL we know and love,
2. Three principles now rescinded
3. Ordinary design, first example
4. Object Design, first example
5. Object Design, second and third examples
6. Object Design, common applications
7. Building in and measuring quality
8. Watching for the pitfalls
9. Developing new COBOL software
10. Modernising existing COBOL software
11. Making the transition to O-O COBOL
Appendix: O-O COBOL Syntax summary

This book has been published before the new standard is finalized but it looks like a very good book to start to understand the new capabilities we will have access to in the ‘near’ future. ”

I appreciate the recommendation myself, and will be ordering the book shortly.

Some news from HP about COBOL: they are only on record for doing COBOL enhancements for the current list that I published last year. They are keen to make sure that the COBOL users are protected and supported into the future, which means we are looking at some interesting negotiations in the near future. This brings me to my next topic;

Fujitsu is hoping to show an MPE/iX native version of their COBOL running sometime this year. It may only be alpha, or it could be done, but this is an exciting development, because unlike MicroFocus and Acucobol, they want it to run in the MPE name space. They may not actually be able to make it happen, but I have expressed to them as vigorously as I can how important this would be.

There are also planning on showing the new version of PowerCobol which will support the inclusion of third party Active/X controls. At the time I write this, late January, they are getting ready to release their latest update to PowerCobol, including a new 32 bit version. What they told me is that they intend to give away the 16 bit version forever, so now’s your chance to get into Windows programming.

Fujitsu has also been talking with HP about possibly becoming their official COBOL. At this point in time the talks are very very tentative, but it would be nice to have a language company be responsible for the language, as long as they were seriously committed to the platform until the end of time. This brings me to my next topic, the SIG*COBOL group has compiled a list of the top 10 items people are concerned with for COBOL on the HP 3000, they aren’t in any particular order.

1. The compiler must generate efficient native code for MPE/iX.

2. An interpretive mode for testing would be a useful tool in speeding up development.

3. There must be no run time costs for applications developed with the compiler.

4. It must conform to the new COBOL 97 standard in a timely manner. This means the commitment must be to provide a fully implemented version of COBOL 97, including the Object Oriented features.

5. It must include the most used HP extensions. This especially means the CALL extension to access the HP Intrinsic library and the $DEFINE macro extension.

6. Compiled programs must be able to easily access files in the MPE and POSIX name space from the same program. This especially means IMAGE/SQL databases.

7. An easy transition must be provided to migrate existing HP COBOL II programs to any new compiler when any HP extensions, not implemented in the new compiler, have been used.

8. The same source code must be compileable under MPE/iX, HP/UX and Windows NT, at least.

9. There must be a GUI development environment integrated with the compiler.

10. The HP Response Centre should be able to take calls for the compiler to avoid HP users having to add new support contracts with another vendor.

I think all of these things are nice, but some are more necessary than others. You’ll notice the implied use of a third party for the COBOL compiler in this list as well.

To wrap up this month, I want to mention a feature of COBOL that you might have missed. There is a source level debugger available for free on the HP called XDB. To begin to make use of it you need to add the line $CONTROL SYMDEBUG=XDB
at the top of your program. To be honest, I have only ever used this with C, and would be interested in anyone contributing a ‘how to’ of the best way to use XDB with COBOL. Good luck with your taxes.

Addendum: I am writing this about 2 weeks after finishing this column, and I am doing this intentionally so you get the same flow I did. I mentioned Microfocus and their Visual Object Cobol earlier. During the middle of last year one of the guys on the VOC development team came across one of these cobol columns on the web and emailed me. He told me about all the neat Internet stuff that was being put in VOC, and how it generated true executables now and didn’t require a run time (this must be the technology they got when they bought Visual Cobol a few years back from a German company).

In any case he made me rather excited to see it, and talked me into doing a review when it was available. Now he must have forgot because he never did get me a copy. So I recently contacted MicroFocus about doing the review and received the strangest agreement contract back from them in the mail. I have done around 50 software reviews at this point and have never gotten on of these. So we did a round of voice mail and they suddenly said “we’ve changed our minds, we don’t want a review done”. I’m not going to tell you how to interpret that, but I found it rather disappointing, and I believe I am going to finally give up on MicroFocus COBOL, Fujitsu is much easier to work with.

Stay tuned, I will give you any other updates as they occur, but don’t look for a VOC review any time soon, probably anywhere.