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

Appendix L 673
A Programmer’s Guide to VPLUS
Optimizing VPLUS Utilization
buffers. For example, suppose most forms in the forms file contain 20 2-character long
fields, while one form contains 40 6-character long fields. Whereas most of the forms would
only require the DBUF and IBUF to be 40 characters long (20 fields times 2 characters per
field), VPLUS will allocate 240 characters for both buffers (40 times 6). Changing that
40-field form to a self-repeat/append containing 4 fields brings that form’s requirements
down to buffers 24 characters long. Notice that by making that change, VPLUS’s stack
requirements have just decreased by 432 words (216 words each for the DBUF and IBUF).
In the same vein, if most of the forms have close to the same number of fields and almost
the same data buffer requirements, but one form has MANY more fields, a simple splitting
of the form into either a self-repeating of multiple forms (if dealing with REPEAT/APPEND is
not desirable) will decrease the space needed for the FST, as well as the other internal
tables needed to manipulate fields.
If stack space is a problem, and function key labels (FKLs) are enabled, their elimination
could save up to approximately 800 words. When enabled, space is reserved for two copies
of FKLs: one copy for global FKLs to be used in the forms file, and another to be used for
FKLs local to each form. For each copy, there are 16 bytes of storage reserved per key label
for the messages associated with each, as well as information used by VPLUS to tell if FKL
definitions have changed (via calls to the VSETKEYLABELS or VSETKEYLABEL routines) and if
those changed values have yet been displayed.
Another feature of VPLUS that occupies a large amount of stack space is the use of INIT,
FIELD, and FINISH phase edit specifications. FORMSPEC compiles these into object code
meaningful only to the appropriate VPLUS routines (VINITFORM, VFIELDEDITS,
VFINISHFORM) which act upon the copy of the data brought into the IBUF by VREADFIELDS.
Since each form can have up to 12000 words of code (which is treated on the stack as part
of the form definition), either eliminating or simplifying edit specifications can save
immense amounts of stack space.
All of these suggestions used in combination can save a program on the order of hundreds,
if not thousands, of words of stack space. In most cases, simply using a fast forms file in
combination with eliminating LFS will return more than enough stack space to allow
processing to commence.