ORBiT Sponsor Message

Here is Paul’s example of how simply 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 sees something, then he goes and does the non-visible 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 too 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 occurring. The client suspected the date intrinsics, so I wrote a sample program to simply loop through the intrinsics to see where time was being spent. It wasn’t until one million iterations that I saw an impact of four 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.

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