Segmented program design considerations

You should consider a number of factors when designing segmented programs.

  • If a called program performs a segmented converse, that is, the program contains a converse statement and has the segmented property set to YES, the following considerations apply:
    • All programs in the call chain must have the segmented property set to YES. That is, if program A (nonsegmented) calls program B (nonsegmented), and program B calls program C (segmented), programs A and B must also have the segmented property set to YES.
    • When you change a program to a segmented program, it consumes more resources, so calling a program that performs a segmented converse can have a negative effect on the performance of the run unit.
  • Segmentation ends the current system task. CICS® and IMS™ commit all recoverable resources when the task ends.
  • A record cannot be held for update (locked) across a segmented converse.
    Note:
    Holding a record for update across a converse is not a good practice on any system, because it locks resources during user think time, preventing additional users from accessing the record.

    For a better approach to holding a record for update across a converse, refer to the code in the following example.

    customerRecord Customer;
savedRecord Customer;
updateComplete char(1) = "N";

// check that data has not changed during user think time
customerRecord.CustomerID = 1;
get customerRecord;
while (updateComplete == "N")
  move customerRecord to savedRecord byName;
  move customerRecord to custDetailForm byName;
  converse custDetailForm;
  // validate input data on custDetail form
  // assuming validation passed, continue
  get customerRecord forUpdate;
  // check all fields in customerRecord to determine 
  // whether anything changed during user think time
  if (customerRecord.field1 == savedRecord.field1
  && customerRecord.field2 == savedRecord.field2
   ...
  && customerRecord.fieldn == savedRecord.fieldn )
    // if no changes, move changed data from form to customerRecord
    replace customerRecord;
    updateComplete = "Y";
  else
    // message to user that data was modified by someone else
  end
end

record Customer type ...
  field1 ...
  field2 ...
  ...
  fieldn ...
end
  • Locks created by the forUpdate keyword and current positions in files or databases are lost during a converse statement when running in segmented mode.
  • The program structure and I/O objects determine the amount of response time delay caused by the roll out/roll in process:
    • The longest delay occurs in a segmented program that has a large amount of variable field data on forms or large records and short user think time.
    • The shortest delay occurs in a menu type program that has a small amount of variable field data on forms, only a small record, and long periods of user think time.
  • In CICS®, if the UCTRAN operand has been set to YES for the PROFILE or TYPETERM entries for the terminal, CICS® folds user data from forms to upper case when the code runs in segmented mode. The folding of user data by CICS® causes the EGL upperCase property to have no effect.
  • On CICS® systems, when the user presses the Enter key or a function key, the system returns input data through CICS® to the EGL program. CICS® examines the beginning of the data, searching for Basic Mapping Support (BMS) commands. When designing segmented programs, ensure that the first physical variable field on your EGL form does not contain a valid BMS paging command. For more information on design considerations for segmented programs in CICS®, refer to the CICS® documentation.