Inside COBOL #65 (Tricks of Perception)
by
Shawn Gordon
President
The Kompany

We have two good reader tips this month. The first is from Paul Christensen and is something that can be applied to any language. Paul brings up a point that I spent a lot of time on many years ago, and it
became so standard in my coding style that I just don’t even think to mention it anymore. Essentially we are talking about the perception of performance.

Here is Paul’s example of how just changing the start up sequence of a program reduced the complaints by the end users.

> 95000-INITIALIZATION.
>      CALL "DBOPEN" for customer database.
>      CALL "DBOPEN" for inventory database
>      CALL "DBOPEN" for validation database
>      CALL "DBGET"  for control records
>      CALL "VOPENFORMF"
>      CALL "VOPENTERM"
>      CALL "VGETNEXTFORM"
>      CALL "VINITFORM"
>      CALL "VSHOWFORM"
>      CALL "VREADFIELDS"
>
> New code
>
> 95000-INITIALIZATION.
>      CALL "VOPENFORMF"
>      CALL "VOPENTERM"
>      CALL "VGETNEXTFORM"
>      CALL "VINITFORM"
>      CALL "VSHOWFORM"
>      CALL "DBOPEN"
>      CALL "DBOPEN"
>      CALL "DBOPEN"
>      CALL "DBGET"
>      CALL "VREADFIELDS".

What he has done here is display the screen first so the user see’s something, then he goes and does the non-visable work. A technique I used was for a character mode screen driver I wrote many years ago. On a loaded system you could painfully see each field paint at times, so to reduce frustration we simply turned the display off with an escape sequence while the screen painted, then the user just saw it pop up
instantly.

Another technique is to use a “splash” screen, which is very popular with MS Windows applications. It’s a good idea too, because at least the user knows the application has launched and is starting to load.

Another tip is from my good friend Bill Seitz of Retriever Interactive (Bill sends me more tips than any other person). He stumbled across an interesting aspect of copy libraries recently. The concept of a copy library is pretty universal to COBOL, the fact that they are in a KSAM file on the HP 3000, doesn’t necessarily mean that all copy libraries are in keyed files.

Apparently if you create a file that is like a copy library file, 80 bytes wide with the name of the member in columns 73 thru 80, then you can direct COPY statements from your COBOL code, just as if it was a regular copy library. This actually mixes the COPY and the $INCLUDE directives a bit, in an interesting way. You can still use COPY and COPY..REPLACING, but you can also say $INCLUDE COPYLIB and every definition within the file will be pulled into your program. In
practice, this may not be to swift, but it’s interesting that even for people who have been doing this forever, you do run into the habit of not questioning how or why certain things are they way they are.

On a slightly related note, the $INCLUDE directive is faster at pulling in code than the COPY directive, but has less options. The difference is probably small enough now that it’s not even worth bothering about, but it’s interesting trivia all the same.

On a final note I want to mention something about the new HP date intrinsics. These were the core of a lot of Y2K remediation that I did, but for one client they had an online program that with the way the code was implemented, the calls to HPDATECONVERT would happen a couple of hundred thousand times while data entry was happening. The client suspected the date intrinsics so I wrote a sample program to simply loop through the intrinsic to see where time was being spent. It wasn’t until one million iterations that I saw an impact of 4 seconds. Ten million calls took 38 seconds. As I mentioned their program called it about 170,000 times, but was taking up to 10 minutes. This just didn’t make any sense. I went ahead and reworked the code and removed a number of the calls by converting data as it was loaded and restructuring how some other things worked. This got the performance back down to a few seconds.

We are going to be putting a call into HP to see if they can help ascertain what the problem is since our sample program showed perfectly acceptable performance. If I get any details I will share them with
you.

Hope to see you all at HP World this year. Keep those tips coming.