Implementing a hierarchical structure for segmenting programs using a transfer to program statement

There is a set of EGL programs that should perform well running in segmented mode in the CICS® environment.

An additional benefit is that these programs are easier to maintain, test, and enhance than a single EGL program that contains all the same functions.

The diagram below shows the relationship between four EGL programs that perform three tasks. The only purpose of the menu program is to access the other three programs. When the user selects the desired task, the menu program transfers control to the corresponding program by using a transfer to program statement. The menu program passes a small working storage record to further define the request. The transferred-to program prompts the user for required data, performs the task as often as needed and uses the transfer to program statement to return to the menu program.

Figure 1. Hierarchical structure using a transfer to program statementHierarchical structure using a transfer to program statement
Using a transfer to program statement solves the following segmented mode restrictions:
In the IMS/VS environment, a transfer to program statement does not release the storage for the original program. In the example, the menu program is the original program. If you are developing programs that run in both IMS™ and CICS environments, you can use either a transfer to program or a transfer to transaction statement. If you are developing programs that run in IMS only, use a transfer to transaction statement for the following reasons: Use a transfer to program statement in the IMS environment if you do not want a commit point to occur or if you need both programs to use the same DB2 plan and PSB.

Dynamically changing between segmented and nonsegmented mode

Note: This technique is only supported in VisualAge® Generator compatibility mode. It should not be used for new programs.
When you specify the segmented property for a program, you set the default mode for how a converse statement is handled at runtime. The segmented property initializes the value of the converseVar.segmentedMode system variable in the following way:
0
indicates that the program is nonsegmented
1
indicates that the program is segmented
You can change the converseVar.segmentedMode system variable to dynamically control segmentation at runtime. By setting converseVar.segmentedMode to 0 or 1, you can override the default value for the next converse statement. Before each converse statement, EGL checks the value of converseVar.segmentedMode and processes the converse statement in the following way:
  • If converseVar.segmentedMode is set to 1, EGL treats the converse statement as a segmented converse.
  • If converseVar.segmentedMode is set to 0, EGL treats the converse statement as a nonsegmented converse.

When the converse statement completes successfully, EGL resets converseVar.segmentedMode to the default value based on the segmented property for the program.

The converseVar.segmentedMode system variable enables you to switch in and out of segmented mode for reasons of performance, function, and target system differences. To control segmentation, use either of the following statements prior to a converse statement:
converseVar.segmentedMode = 1;  // force the next converse to be segmented
converseVar.segmentedMode = 0;  // force the next converse to be nonsegmented

Remember that converseVar.segmentedMode is reset to its generated default after every converse. Therefore, you should only set converseVar.segmentedMode if you want to alter the behavior of a specific converse from the default processing.

Note: EGL ignores the use of converseVar.segmentedMode system variable in the IMS/VS environment. All programs containing converse statements must run in segmented mode in the IMS/VS environment.


Feedback