A UTM application is created on Windows systems as a Windows console application. Different processes work together when a UTM application program is executed, whereby each process performs specific tasks. Some of these processes are started in a DOS window (prompt) by calling the program. Shortcuts can be created for these program calls so that the processes can be started using the mouse or by entering commands through the keyboard.
The various process types are described in the following paragraphs. figure 47 shows an overview of these process types.
Main process and service process
A UTM application is started by setting up the main process. The main process can run in the background or in the foreground.
The main process is started in the foreground by calling the utmmain program. utmmain is called from a CMD window. This type of application start can especially be used during the development of the application.
A UTM application can be started using the utmmains program as a service for production operation.This process is therefore called the service process. It starts the main process, which then runs in the background. All output is redirected to a file in this case. If the application is set up as a service, then it can also be started automatically after the Windows system is started.
Work processes
The main process starts as many work processes as are specified in the start parameters. The application program created by the user is loaded into all of these work processes and then started.
The work processes perform the actual work, i.e. they handle the service requests sent to the UTM application. The main process monitors these productive processes. During the application run, the main process automatically creates further work processes if a work process is terminated due to an error or if additional work processes are explicitly allocated to the application by administration.
After the application start, all the work processes of the UTM application wait for jobs in a shared process queue. If a job arrives, it is assigned to a work process waiting in the queue. This process handles the job and then rejoins the process queue.
If more jobs exist than work processes, a job queue is established. Both the job queue and process queue are application-related, i.e. each application has its own process queue and job queue. The queues for processes are implemented by semaphores, while the queues for jobs are implemented by a shared memory.
Timer process
In addition to the work processes, the main process sets up a timer process which is assigned to the application. The timer process accepts jobs from the work processes in order to time the wait states, and arranges these jobs in a job queue. After one of the times recorded in the job queue expires, this is indicated to the work processes for processing.
Network processes
With distributed processing, UTM applications are connected to the network via network processes. These processes are set up by the main process, and the task of these processes is to process connection requests and manage the data transfer on this connection.
The network connection can run via PCMX or directly through the socket interface. The number of network processes depends on the generation.
| For further information network processes and for details on generation, see the openUTM manual “Generating Applications”. You will find a description of how to control net processes using environment variables in the openUTM manual “Using UTM Applications on Unix, Linux and Windows Systems”. |
Dialog terminal processes (DTPs)
Each console window which works with the UTM application has its own dialog process, known as the dialog terminal process. This is established from the DOS shell by starting the utmdtp program, or it is started automatically when the user successfully logs on to the Windows system by making the appropriate entry in the Startup group.
The user selects the UTM application, thereby establishing a connection between the dialog terminal process and the UTM application. The dialog terminal process can then send jobs to the UTM application and receive messages from the UTM application.
A dialog terminal process can only be started on the computer on which the UTM application is running.
Shutdown process
The shutdown process utmshut is set up when the application is started. This process ensures that the UTM application is properly terminated when the system shuts down.
Local client processes
A separate local client process exists for each UTM client that is based on the UPIC carrier system and works with the UTM application. This process is started for example from the Windows command prompt.
The local client process establishes a connection to the UTM application. The local client process can then send jobs to the UTM application and receive messages from the UTM application.
Logging process
openUTM can record certain data such as accounting records or event data while the application is running. The recording of data is controlled by the logging process (utmlog).
When generated, openUTM provides accounting information during the application run. This information is recorded in "accounting records" by openUTM and forwarded to the logging process. The logging process writes these records in a file in the ACCNT subdirectory.
The UTM event monitor KDCMON functionality integrated into openUTM is available to monitor the performance of an openUTM application. After starting the KDCMON monitor, the work processes record the event data and pass it to the logging process, which then writes the data records in a file in the KDCMON subdirectory. The task of administering this data is then moved from the work processes to a single instance, the logging process.
Overview: Processes of a UTM application on Windows systems
Figure 47: Process interaction in a UTM application on Windows systems
1)The service process is optional. It exists only if the UTM application is started as service.