COBOL TIPS #26
by
Shawn M. Gordon
President S.M.Gordon & Associates

The COBOL excitment never seems to end. I was recently contacted by SIGCOBOL, about the status of COBOL, this column, and if I would be on the panel at their next meeting at Interex. Luckily for me I live in Anaheim, and that’s where the next show is, so I will probably do the panel. I was excited to hear about some changes that HP has committed to making to COBOL sometime in ’96, prior to the official ’97 release of COBOL. First why don’t I give you a run down of what SIGCOBOL is out to do, and some of the information that they have compiled recently;

Our Mission Statement: To work with Hewlett-Packard to continue to provide COBOL as the language of choice for business solutions into the 21st century.

Our Objectives:
(1) To provide an advocacy role to HP on MPE & HP-UX COBOL issues.
(2) To work with HP on the next ANSI/ISO COBOL standard. (COBOL/9x)
(3) To champion the continuation of a software development environment on the HP 3000.
(4) To provide a forum for the exchange of ideas and information on the use of COBOL.

We have a listserver for COBOL (SIGCOBOL-L@INTEREX.ORG). I am going to put this same information on the 3000-L as there is some discussion there on COBOL and development on the HP3000 at the moment.

We sent a survey out (HP and Interex) to about 5000 companies with HP COBOL II support contracts in Jan 95. We received over 500 back (10%+) which surprised HP and delighted us.
53% said they wanted to see new ANSI features in HPCOBOL II.
83% were actively using COBOL on the HP3000 (developing or maintaining).
86% said they intend to remain with COBOL on MPE/iX for at least the next 3 years.
52% said they were very interested in Object Oriented COBOL on MPE/iX.

We also asked respondents to spend $100 on an enhancement list that had been generated from members of the SIG during the last 2 years. HP have decided to implement 6 of the top 11 requests. Most of the requests not implemented are actually requests for the new standard which have to wait until the standard is released.

The enhancements they are expecting to release in fall ’96 are:
(1) Multiple Entry Points in Main Program. This will allow an entry point to be specified in the MPE/iX RUN command.
(2) QEDIT Recognition. Give a more friendly diagnostic if an attempt is made to compile a source file in QEDIT format when QEDIT has not been completely installed on the system.
(3) Display Index-Name. Permit an index-name to be used in a DISPLAY statement.
(4) Compile Larger programs. Enlarge compiler’s internal tables, enabling it to compile larger source programs, to cater for some machine-generated COBOL programs and downsizing from mainframes.
(5) Bit Manipulation. Provide a library of COBOL-callable routines for common bit operations. Also provide better documentation and examples of how to use the BITMAPCNV intrinsic.
(6) Call by Plabel. Allow the identifier in a CALL statement to be numeric denoting a plabel.

The other 5 enhancement requests were – Dynamic variables and Pointer type as per future standard, Bit Manipulation as per future standard, Floating-point as per future standard, STAT74 option for COBRUNTIME variable, Recursion as per future standard.

We feel HP has responded very positively to the input from this SIG so we need to keep the pressure on them to ensure we get the new standard implemented in HP COBOL II on a timely basis.

The System Improvement Ballot this year included the question “Enhance HP COBOL II to the next ANSI/ISO standard”. This came 15th overall, 5th in companies with annual budget $250,000 – $1M, 11th in companies with annual budget $100,000 – $250,000, 19th if annual budget was < $100,000. We have started discussing the possibility of HP providing a "Softbench" like development environment on the HP3000. We have defined our requirements as needing to compile, test, debug and access Image/KSAM files all on MPE/iX but via a GUI interface and in an integrated environment. We have asked for the editors, compilers, etc to be 'plug and play' to enable different people to use different products in the same environment. They have pulled a group of people together to look into the technical issues and will report back to us at IPROF'96. We feel this is a significant step forward and want all HP3000 developers to add their voice to this request. We are finding a number of vendors are actually developing C programs on the HP3000 for porting to HP-UX because the HP3000 is the more stable environment. We are also keen to see the combining of HP resources into one COBOL with the best of HP COBOL II and the best of Microfocus COBOL. I think that is a LONG way away!! Strangely, I don't find most of these all that usefulL. I like the idea of having entry points, but it is rather non-standard, I think SPL was the only language that allowed entry points. QEDIT recognition, I don't care about, displaying an index would be very handy, I have wanted to do this many times. As far as big programs, never been a problem for me on the XL. Now for doc on the BITMAPCNV intrinsic, readers of this column should know how to use this little jewel, it's not that hard, there aren't that many options to it. Call by Plabel, I've never had occasion to need. Here are a few of the features that I would like to see in COBOL in the near future; Everyone complains about COBOL's inability to have local variables. Well, I've used local variables, and it just isn't that big of a thrill. The major use is to save stack space, and be able to quickly see what variables are used in a function. So I don't really care about local variables (and yes, I know there is funky sort of way to kind of do it). My biggest concerns have to do with string handeling. While the STRING, UNSTRING, and INSPECT verbs are very powerful, and flexible, there are some major problems. First, they are amazingly slow and have a huge amount of overhead. Try doing a bunch of UNSTRING commands in a program running on an old HP3000 series 37, or similar. Second problem is you can't replace strings of differing lengths with the INSPECT verb. This one feature would save me an incredible amount of time. I know that you can run into problems like overflowing the variable, but allow for a trap, C is much sloppier in this regard. How about a function to trim leading spaces? There are a few odd-ball way's to do it, some of which we have discussed here, but I really like some of the string functions in Visual Basic (even though I am not to keen on the language). Recurssion would be nice, I have run into a couple of situations where straight forward recurssion would have been really handy. And while operator overloading is one of the funkier things in C++, it would definitly be cool to be able to do it in COBOL. You could define your own functions so that if you added two strings together, they would concatenate, or if you added a number to a date, it would return the correct date offset (you would probably need a date type then). Imagine all the really neat possibilities. The new OO COBOL may allow you to overcome these limits by coding your own classes to handle it, or they could be provided as classes. I don't know what HP's commitment is to the new OO COBOL, but they have been really lax when it comes to supporting languages that they don't use a bunch in their own labs, like C and PASCAL. I do have to give HP credit once again for implementing the macro facility. As I look at other COBOL compiliers, I am continually dissappointed at this lack. From what I understand, there are some HP 3000 people who have tried to port to MicroFocus COBOL, but can't easily do it because of this problem. Having something like SoftBench on the HP would be wonderful. As a matter of fact, an MPE/iX workstation would be awesome for us small developer types. It is hard to spend 20k on a computer for yourself. So, no tips this month, but some really good news for the state of COBOL for all of us. Hang in there, eventually people will remember why all those billions of lines of COBOL are out there.