COBOL TIPS #27
by
Shawn M. Gordon
President S.M.Gordon & Associates
Well I have some editorializing and some tips for this month. As I was helping a friend of mine come up with a justification for using COBOL instead of C as a business language on the HP 3000, I got to talking about portability and all those fun issues, and a very interesting thought occurred to me. I’m sure most of you have heard of the JAVA language from SUN by now. It is a dirivitive of C++ with the nasty bits taken out, like pointers and structures. The idea behind it is that you can write what they term “applets” in this language, put it up on a WWW page, and then when someone’s browser activates the applet, it will be downloaded to your local machine and run by the web browser. The beauty of this is it’s portability, you can write apps for this on pretty much any platform, and then have it distributed on any platform that your JAVA enabled browser supports.
What does all this about the WWW matter to us COBOL types? Well think about this for a minutes; the big 3 COBOL suppliers run on dozens, if not hundreds of hardware and software platforms. The basically generate p-code, like Visual Basic, and then rely on the run time module on the target system to handle the native screen and file I/O. You can literally take applications totally unchanged and move them from system to system. This means that COBOL already supports virutally every target computer that you would want to be able to run from a web browser.
Now picture this if you will, COBOL, not JAVA or VBScript, becomes THE web application language of choice around the world, due to it’s ease of coding, ease of maintainability, and HUGE base of coders. Something like this could really turn the tables on all those nasty other languages that we are forced to read about all the time.
The only problem with all this is that it requires a big company to get behind it, and do it, someone like MicroFocus for example. I have spoken with a few different people about this concept, and everyone is actually pretty excited about the possibilities. I even know one gentleman who has written a web server that run’s under MPE/iX (not POSIX) in COBOL. He is going to let me peek at it here soon.
We’re early enough in the curve of web development that something could really happen with this. If you have a mind to, contact Microfocus by phone, fax, e-mail, or their forum on CompuServe, and let them know what you think. I think this is probably easier than building an OO Cobol.
Now on to my tips for this month. I want to talk about some alternative methods to building sub-programs in COBOL. Figure one shows how you can actually embed a number of programs within one source file, and have them call each other as though they were external routines. The example is indented to indicate the heirarchy of the sub-programs. While this is kind of neat, it really isn’t my preferred method of doing things, however it does kind of simulate local variables, which i guess is it’s only advantage. The disadvantage is that you have built a routine that isn’t usable from any other program, which is usually the point of encapsulating code like that. In general you could just
make the code a paragraph in your single source file. I have only ever seen this kind of coding structure used once, so it show’s it’s not all that popular, but I’m sure some of you out there can give me better reasons other than local variables for using this methodology.
Figure 1 1PROGRAM-ID. A. 2. 3. 4 PROGRAM-ID. C COMMON. 5. 6. 7. END PROGRAM C. 8END PROGRAM A. 9 10 PROGRAM-ID. F. 11. 12. 13. CALL "A". WILL CALL A AT LINE 14 14. PROGRAM-ID. A. 15. 16. 17 END PROGRAM A. 18 19 PROGRAM-ID B. 20. 21. 22 CALL "A". WILL CALL A AT LINE 1 23 END-PROGRAM B. END PROGRAM F.
Now here’s another way of lumping sub-programs together that I actually use once in a while. It takes advantage of the “ENTRY” verb in COBOL. This allows you to lump together a set of routines (preferably small, related ones) into one source file, instead of a bunch of files, and them call them from the main program as you would any other callable routine. They all share the same variable space, but it makes it easy to build essentially functions, like C. I use this same type of logic when I build my related C sub-routines, since it makes maintainence a bit easier, at least in my opinion.
Figure 2. LINKAGE SECTION. 01 DATA1. 01 DATA2. PROCEDURE DIVISION. . . ENTRY "PROC1" USING DATA1. GOBACK. ENTRY "PROC2" USING DATA2. GOBACK. ENTRY "ALLPROC" USING DATA1, DATA2. GOBACK.
You realize when I started this column over two years ago I figured I had enough material for maybe five articles, this is the 27th one so far. Every time I say I am out of ideas, another idea comes up. I appreciate the continued support from all you readers, please keep the input coming, it helps us all.