Choosing between segmented and nonsegmented programs

When you are deciding whether to design your program as segmented or nonsegmented, you should be aware of two issues.

The first issue is the effect of the transaction on contention resources, such as storage and processor use. The second issue is the effect on exclusive-use resources, such as records and recoverable data sets, recoverable transient data queues, and enqueue items.

Nonsegmented programs have a high impact on storage because they run longer than the sum of the transactions that are in an equivalent segmented program. However, processor overhead is lower because only one program is started instead of one for every transaction.

A nonsegmented program retains exclusive use of resources for a longer period of time, unlike the equivalent segmented program. For this reason, segmented programs are quicker to respond, but for recovery and integrity considerations, you might prefer a nonsegmented program.

If you have forms in called programs or need to lock the database during a converse, you should design your program to run in nonsegmented mode.

The following list contains considerations for segmented and nonsegmented programs:

When running a program on a system where storage contention is not a problem, a good compromise between running in segmented or nonsegmented mode is to run in nonsegmented mode with the converseVar.commitOnConverse variable set to 1. This approach forces a commit at every converse from the main program, and it has the good performance characteristics of nonsegmented mode, but it does not hold file or database resources during user think time.


Feedback