HP 3000 Manuals HP 3000 Manuals
Program Segmentation
The Transact/V compiler produces compact p-code. This p-code is placed
on the process stack at execution time and therefore affects the size of
the stack. Even though the Transact p-code is compact, large programs
may produce so much executable p-code that the process stack becomes too
large for the operating environment. Some programs produce a p-code file
so large that the process stack cannot contain the p-code.
You can solve this problem by segmenting your program. Transact allows
you to divide your program into as many as 126 separate segments.
If you choose to segment your program, these segments can be overlaid in
the processor stack in memory. In addition to the root segment (segment
0), which is always in memory, only the currently executing segment needs
to be on the memory stack. When control transfers to another segment,
the new segment can overlay the segment currently in memory. This
technique allows the processor to execute within a smaller stack size
than the size needed by an entire program.
You divide a program into segments by including the !SEGMENT compiler
command in your source code wherever you want a new segment to start.
You can place this command between any two Transact statements. However,
you should exercise judgement about where you segment your program. For
example, you should not segment within a loop construct. And, for
example, when a FIND or OUTPUT statement requires a PERFORM block, the
statement and the PERFORM block should be within the same segment.
Program control cannot automatically cross segment boundaries, unless you
specifically define entry points or use command structures.
One way to force Transact to cross segment boundaries is to use a GO TO
or PERFORM statement to transfer control to a program control label in a
different segment and to define that label as an entry point. Entry
point labels are necessary for transfers into any segment other than your
main program segment (segment 0, the "root" segment).
You define a label as an entry point with a DEFINE(ENTRY) statement.
Labels so defined are global to your program. That is, they can be
referenced from outside the segment in which they appear. Labels defined
within a segment are local to that segment.
Another way to control the use of segments is with command labels. When
a user enters a command, control transfers to the associated command
label. As far as the user is concerned, it does not matter in which
segment a command label is coded. When the user specifies a particular
command label identifying a particular sequence, the Transact processor
makes sure the segment containing that sequence is loaded into memory, if
it is not there already.
The following information describes exactly how segmentation affects data
items and command or program labels.
* All command and subcommand labels are global to the program in
which they are declared. That is, you can reference them from any
segment. They must be unique within the entire program.
* All program control labels and data items declared before the
first !SEGMENT command are global to the program and can be
referenced from any point.
* Any program control label or data item declared after a !SEGMENT
command is local to that segment. A data item of the same name
can be declared in another segment and its separate definition is
maintained.
* If an item is defined in a data dictionary, but not in a
DEFINE(ITEM) statement, it must be referenced in the root segment
in order to be used in any segment. If the program references a
child item that is defined in the data dictionary, then the parent
must be referenced either in the root segment or in the same
segment as that in which the child is referenced.
If you use the compile option DEFN in a segmented program, the compiler
produces a list of the effective ITEM definitions at the end of each
segment.
When using local items in a segmented program, you need to explicitly
clear the list, match, and update registers at the end of the segment.
Transact normally checks them when it loads a new segment and issues a
warning message if it finds items. It does not clear them. Furthermore,
if you compile your program with the compile option OPTS, Transact does
not check the registers for local items. If items local to one segment
remain in these registers when another segment is executed, they may
cause your program to malfunction or even abort.
In addition to the specific considerations discussed above, you should
always consider the following general rules when segmenting your
programs:
* Stay in one segment for as long as possible. And, when you leave
a segment, stay out for as long as possible.
* Try to define segments of uniform size since stack space is
allocated for the largest segment.
* Put any routines that are used by many segments in the main (root)
segment since it always resides in memory along with whatever
other segments happen to be loaded. However, try to minimize the
size of this segment as well.