Local and central connection of printers
Printers can be connected in two different ways:
“centrally” as a network printer
“locally” to a terminal
Network printers must be generated explicitly in UTM and BCAM. In the case of locally connected printers, only the terminal need be taken into account in the generation. The connection type has no effect on the program interface.
Regardless of the connection type, openUTM supports the following operating modes:
hardcopy mode
spool mode
If a printer is connected locally, spool mode is referred to as bypass mode. In bypass mode, the terminal can manage a dialog independently of the print output. Bypass mode can only be implemented for particular terminal types (e.g. 9763 terminals).
Using RSO printers
UTM applications on BS2000 systems can also use RSO printers. The OLTP interface made available by RSO (Remote Spool Output) gives openUTM access to all printers supported by RSO, i.e. even to printers connected via LAN or to PCs. openUTM does not establish a transport connection to these printers; instead, it accesses them via the OLTP interface, i.e. openUTM reserves the printer in the RSO and then passes the print job to the RSO.
At the program interfaces, RSO printers are handled in exactly the same way as printers that are connected in a different manner. Print options can also be passed to the printer in the form of a parameter list.
| There is a separate series of manuals for the RSO software product provided by BS2000 systems. Further information specific to UTM generation can be found in the openUTM manual “Generating Applications” under the heading “RSO”. |
Sharing printers
You can use a generation parameter (PLEV parameter of the KDCDEF statement LTERM) to allow a printer to be used by a number of UTM applications. This is achieved by maintaining the connection between a UTM application and the printer for short periods only, thereby giving other UTM applications the option of setting up a connection. If this parameter is used, openUTM only sets up a connection to a printer when the number of messages waiting to be printed exceeds the threshold value generated for a specific printer. The connection is shut down again when no more messages are waiting to be printed.
Run priorities
During generation you can assign each transaction code an individual run priority withon BS2000 systems. This run priority is assigned to the UTM process in which the program unit is running. As a result, you can use BS2000 system’s scheduling mechanisms to control the execution of UTM program units.
Specific security functions
SAT logging
You can log security-related UTM events with the BS2000 function SAT (security audit trail). This log provides the verification required in accordance with the F2/Q3 criteria of the ITS catalog.
Additional system access control through connection passwords
Each UTM application in a BS2000 system can be protected against unauthorized use by a connection password that can be defined when the application is started. Each terminal user who wants to work with this UTM application must specify this password.
Support for Kerberos and system access control using Kerberos
On BS2000 systems, when establishing a connection from terminals, a Kerberos dialog can be executed, the results of which can be read in the program unit. This functionality can be generated using the LTERM and TPOOL statements.
System access control using the Kerberos distributed authorization service can be generated using the USER statement.
Database keys
For UTM applications on BS2000 systems, a database key can be assigned to a transaction code in the generation if they use the IUTMDB interface, see "System integration". This means that certain access rights to the database can be assigned to the TAC. openUTM transfers the key to the database system, where it is analyzed by certain database systems in order to check the access rights to database records.
Encryption for terminal connection
Encryption can also be used for terminal emulations in UTM applications on BS2000 systems. The encryption is executed on the host side by the BS2000 product VTSU-B. In this fashion, every emulation can be operated with encryption as long as it supports the corresponding functions.
| Further details on the BS2000-specific security functions outlined above can be found in the openUTM manual “Generating Applications”. |
Internationalization / XHCS support
openUTM supports internationalization:
A UTM application can be generated such that communication partners using different languages can be served in their particular language. Even regional differences within a language can be taken into account. Dates, times, units of measurement, and currency symbols can be displayed in accordance with local conventions.
On BS2000 systems you can assign a particular language environment – also known as the “locale” – to the individual user IDs, access points (LTERM partners), or the entire application when configuring a UTM application. This locale is specified as follows:
LOCALE=(language-code, territorial-code, character-set-name)
The program units of the UTM application can access the locale information and interpret the input of the communication partner or create messages to the communication partner as appropriate.
In addition, on BS2000 systems you can generate a number of message modules for a UTM application and thereby also have multilingual UTM messages.
openUTM on BS2000 systems thus provides a full range of internationalization options. A similar function is available on Unix and Linux systems by using NLS (native language support).
To display the fonts and special characters of the individual languages on terminals or printers, various character sets (8-bit codes or unicode character sets such as UTFE) may be required. A number of character sets can be used simultaneously in a BS2000 system with the aid of the BS2000 software product XHCS (eXtended Host Code Support).
openUTM supports the functions of XHCS. This means that a specific extended character set, which is then used for formatting messages, can be assigned to individual user IDs, individual access points (LTERM partners), and the entire application. In particular, Unicode data can be processed in the application program, and FHS formats with Unicode data can be read in and output.
| Further information on XHCS can be found in the User Guide “XHCS V2.0 - 8-Bit Code and Unicode Support on BS2000/OSD”. The UTM-specific aspects of internationalization are described in the openUTM manual “Generating Applications”. |
Using the OMNIS session manager
The services of the BS2000 software product OMNIS can be used for UTM applications on BS2000 systems. OMNIS is a session manager that enables a terminal user to call the services of various UTM applications directly, even if the UTM applications are distributed throughout the network. In this case, the terminal user does not have to know the computer or UTM application in which the service is running: OMNIS automatically establishes a connection to the “correct” UTM application and regulates the assignment of messages (message distribution).
If you are using OMNIS, you can also use the multiplex function provided by openUTM on BS2000 systems: a large number of terminals can link up with a UTM application via a small number of transport connections.
The add-on product OMNIS-MENU is available if you want to use OMNIS via menus.
Figure 42: Message distribution and multiplexing with OMNIS
| Separate manuals are available on the OMNIS session manager and OMNIS menu control: “OMNIS/OMNIS-MENU Functions and Commands” and “OMNIS/OMNIS-MENU Administration and Programming”. For information on defining multiplex connections when generating UTM (see the openUTM manual “Generating Applications”). |
Calling UTM services with CALLUTM
The program CALLUTM is supplied with openUTM on BS2000 systems. CALLUTM allows UTM services to be called from within any BS2000 batch task or dialog task. The program has an SDF interface and can itself be called from within procedures. One of the uses to which the program can be put is to call UTM administration commands, e.g. to terminate all UTM applications with KDCSHUT subject to procedure control. In this way, you can administer one or more UTM applications irrespective of the computer or operating system on which they are running.
CALLUTM is a UPIC client in the BS2000 system and communicates with the UTM applications via the CPI-C interface with UPIC as carrier system. CALLUTM can therefore utilize the UTM user concept, i.e. it can sign on using a UTM user ID that can also be a Password-protected.
| For more information on CALLUTM, see the openUTM manual “Administering Applications”. |
SDF interface for UTM tools
UTM tools such as KDCDEF can be started using separate SDF commands. The commands are located in the SDF UTM application area.
| For a description of these SDF commands, see openUTM manual “Using UTM Applications on BS2000 Systems”. |
