Restart area

KDCS calls in a program unit will result in modifications to the administrative data.
openUTM collects information on all changes made within a transaction - i.e. from the first INIT call to the end of the transaction - in a process-specific storage area. On BS2000 systems this is a buffer in class 5 memory.

In a UTM-S application, openUTM uses the information in this buffer to create a restart data record at the end of the transaction. It then writes this data record to the restart area of the KDCFILE. The data record describes the modifications to the administrative data which were made as a result of the transaction. In the case of a warm start, it is used by openUTM to trace the effect of the transaction. The size of the restart area determines the interval at which modifications to the configuration data must be transferred to the administrative data area of the KDCFILE.

In a UTM-F application, restart data records are written only for transactions in which passwords were changed or in which administrative data was modified by means of dynamic configuration.

The data records in the restart area are combined by openUTM, i.e. a UTM page in this area generally contains several data records.

During KDCDEF generation, you can define the size of the buffer and the restart area using the following statement:

MAX ...,RECBUF=( number,length )

number	Size of the restart area for each process in the KDCFILE, specified in UTM pages
length	Size of the buffer for each process in the main memory, specified in bytes

Setting the length parameter

The length parameter lets you reserve for each process a buffer area that is length bytes long in main memory. openUTM uses this area to buffer changes to administrative data while a transaction is still open and can therefore still be rolled back.

For length, you must calculate the space requirements of the application’s transactions in the buffer using default values:

• In addition to the basic requirement of 40 bytes per transaction, you must also allow for the following:

  • up to 50 bytes per KDCS call, but 80 bytes per MCOM call.

  • up to 300 bytes per ADMI call.

• In the case of distributed processing, the following additional requirements must be taken into consideration:

  • 300 bytes per LU6.1 communication partner

  • 200 bytes per OSI TP partner

• In the case of asynchronous administration by means of an FPUT call, please note that all FPUT NT calls from a program unit to the same administration TAC are processed by the UTM administration program in a single transaction. The individual administration commands require the following buffer space, which must be taken into consideration in length:

  • 0 bytes for each KDCHELP and KDCINF administration command

  • for all other administration command others
    300 bytes on BS2000 systems
    360 bytes on Unix, Linux and Windows systems

  On 64-bit platforms you will need to double the memory requirement.

  If RECBUF=length is generated too small, i.e. if the buffer is not large enough for a transaction, openUTM rejects a KDCS call or rolls back the transaction or cancel the transaction abnormally.

Setting the number parameter

The number parameter lets you reserve for each process a buffer area whose size is number UTM pages in the KDCFILE. openUTM uses this area to buffer changes to the administrative data of completed transactions until the changed data is written to the KDCFILE in the next periodic write. A UTM page generally contains several data records, since these generally occupy only slightly less space than the corresponding information in the buffer.
If number is defined too low, KDCDEF automatically increases this to the minimum value.

When combined with the restart records, the administrative data in the KDCFILE always represents the last valid state of the application. When using UTM-S, openUTM automatically updates the administrative data in the KDCFILE (Periodic Write) before a restart area becomes full during runtime. All pages containing administrative data in which modifications have been made are written to the KDCFILE parallel to the transactions currently active. All data records written previously to the restart areas thus become obsolete.

If the restart area is large, the administrative data in the KDCFILE is updated less frequently during runtime. When performing a warm start following termination of the application, however, large quantities of data records from the restart areas must be incorporated in the KDCFILE, i.e. the warm start takes longer. The opposite applies if the restart area is small: since administrative data is updated frequently during runtime, the time required for warm start is reduced but impact slightly on the executing application.

number should be set such that the space available in the restart area is at least a multiple of the buffer generated using the length parameter.

In a UTM-F application, the volume of administrative data written back to the KDCFILE is much less, e.g. changed user passwords and generation data modified by means of dynamic configuration. The number parameter can therefore be set lower for UTM-F applications.