When the application is started, the application program is initiated in a certain number of processes defined by the user.
Since a UTM application is generally accessed simultaneously by a number of clients, each client does not have its own exclusive process. Instead, the large number of simultaneous requests is distributed by openUTM across a small number of processes. As a result, the system overhead and thus the response times do not increase proportionally with the number of users.
If the number of jobs to be processed exceeds the number of free processes, openUTM places the jobs in a queue. Similarly, if the number of free processes exceeds the number of outstanding jobs, the free processes are placed in a process queue.
In addition to the number of processes defined by you, further processes are also started for UTM applications. These are known as UTM system processes, see section "UTM system processes" below.
This openUTM concept of several homogeneous peer processes has a number of further advantages:
Several jobs can be processed simultaneously.
If several jobs request the same service, the service can be provided simultaneously in different processes.
A UTM application can react quickly to load fluctuations, since processes can be added or removed during operation by administration.
Throughput bottlenecks in particular services can be eliminated, since the processes are of equal ranking (homogeneous) and can be used for any job.
The worst possible outcome of a fatal error in an application program is a process crash. The effect of the error thus remains local, i.e. only the job that was being processed by the process at the time of the crash is affected. The application as a whole and other applications running in the same system under the control of openUTM are not affected. openUTM will automatically replace the aborted process by a new one.
UTM system processes
The purpose of the system processes is to ensure that applications continue to be responsive even under high loads. UTM system processes only process selected jobs which are characterized first and foremost by short runtimes. Selected jobs may be, for example, the establishment or cleardown of connections, timeout displays, end-of-transaction requests in UTM-D and responses for programs waiting for a PGWT call.
Selected jobs may also include program unit runs for an administrator. On generation, it is also possible to specify a so-called privileged LTERM partner. The following applies to the connection associated with this LTERM partner:
If a sign-on service is started for this connection then this sign-on service is also processed by the UTM system processes.
If an administrator signs on via this connection then program unit runs for this connection are also handled by the UTM system processes.
If a normal user signs on via this connection then this connection is handled exclusively using "normal" processes until the user signs off.
UTM starts the UTM system processes implicitly when an application is started. The number of UTM system processes that are started depends on the values specified in the start parameter TASKS and in the generation parameter MAX SYSTEM-TASKS.
The following table shows the number of UTM system processes in case of MAX SYSTEM-TASKS=*STD has been specified in the UTM generation.
Start parameter TASKS= | Number of additionally started | Total started processes |
1 | 0 | 1 |
2 | 1 | 3 |
3 | 2 | 5 |
4 | 2 | 6 |
5 | 3 | 8 |
n > 5 | 3 | n + 3 |
Optimum process utilization through pseudo-conversations
Service routines can be programmed such that a user does not occupy a process during wait times, e.g. while he/she is thinking about what to do. The process then is released immediately, and is available for other jobs. When the terminal user has finished inputting information, another process may continue the dialog without the user noticing any difference. openUTM thus guarantees the optimum utilization of processes, which has a positive effect on performance.
This dialog concept, also known as pseudo-conversational, can be applied not only for dialogs with terminal users but also for program-to-program communication.
| Further information on the subject of pseudo-conversations can be found in the openUTM manual “Programming Applications with KDCS for COBOL, C and C++”. Some of the operating-system-specific aspects of the process concept are dealt with in chapters "openUTM on BS2000 systems", "openUTM on Unix and Linux systems" and "openUTM on Windows systems". |
