HP Data Entry and Forms Management System (VPLUS) Reference Manual (32209-90024)

672 AppendixL
A Programmer’s Guide to VPLUS
Optimizing VPLUS Utilization
displayed is similar in format, it’s possible to use forms families to make minor changes in
the display without repainting the entire screen. You can also use the intrinsic
VCHANGEFIELD (released with version B.04.17 of VPLUS) to accomplish the same ends.
Combining Several Forms
If your program accesses several forms files, you should seriously consider combining them
into a single file. Not only does this save stack space (since VPLUS must maintain
separate control information-- including the DBUF and IBUF--on the program’s data stack
for each open forms file), but it helps make maintenance of the forms much simpler. If the
forms are scattered among multiple forms files, the forms files must be closed and
reopened each time they are used, and much of the time used by the program will be tied
up in this moving between forms files, rather than with the actual processing of the data.
Stack Use by VPLUS Applications
Some of what will be talked about in this section will contradict what was discussed in the
prior section. Once again, it is the computer world’s old “space/time” problem: optimizing
the data space required for a program will most likely increase the execution time of the
resulting application.
If a VPLUS application aborts with any of the typical indicators of a stack problem (STACK
OVERFLOW; a call to VOPENFORMF fails with error codes 40, 41, 61, 62, 68 or 69), the first
thing to do is to compile the forms file into a fast forms file. One part of the space reserved
on a data stack is an area which contains the directory of all records in a forms file. By all
records, we mean ALL records-- source records containing the raw, input form definitions,
code records containing the escape sequences needed to paint those forms on the screen, as
well as FORMSPEC-internal records needed to manipulate those forms.
What goes into a fast forms file is only a few control records (to designate it as a fast forms
file) and code records--but no source records. Since there are fewer records in the file, the
directory is smaller and less space is needed on the stack for it. As a result, you save a
minimum of 800 words per forms file simply by using fast forms files. (We should also note
that, in addition to the space savings, fast forms files are so named because they require
much less disc I/O. Some benchmarks have shown as much as a 50% reduction in forms file
I/Os when a fast forms file is used instead of a slow forms file.)
Other methods of space optimization may involve taking out some of the features
incorporated in the original design of the application. Local Forms Storage (LFS) is very
useful for minimizing data communications overhead involved in VPLUS, since by its use
a forms definition may be sent to a terminal once, but there is a price to be paid on the
stack. If LFS is being used, a directory of form names already downloaded to the terminal
is kept on the stack to enable VPLUS to quickly discover whether a form has already been
downloaded. Each entry in this table is 16 words long. Therefore, if LFS is enabled for a
large number of local forms (via VOPENFORMF), disabling it will save 16*n words, where n is
that number of “local” forms. (Local forms storage will be discussed in greater detail in a
later section.)
One of the ergonomic features discussed in the forms design section comes into play now.
Remember, VPLUS keeps two copies of the data buffers on your stack (the DBUF and IBUF),
in addition to any buffer space allocated by your program. Minimizing, or standardizing,
the amount of data that is transferred for each form will help control the sizes of those