UTMD - application parameters for distributed processing

The UTMD control statement allows you to define values for distributed processing throughout the application. A UTMD statement is only required for applications that use either the LU6.1 or the OSI TP protocol for communication.

The UTMD statement may only by entered once.

If you use the OSI TP protocol in your application, you can specify the Application Process Title (APT) of the application in the UTMD statement. This is required by some heterogeneous partners that support another variant of the OSI TP protocol in order to establish a connection. These applications expect the specification of the Application Process Title on establishment of the connection.

The application process title is combined with any application entity qualifier (AEQ) assigned to an access point of your application to form an application entity title (AET), which is unique throughout the OSI network. This is used by the partner application to identify the access point of the local application via which communication is to take place.

UTMD	[ APPLICATION-PROCESS-TITLE=object_identifier ]  [ ,CONCTIME={ time1 | ( time1,time2 ) } ]  [ ,MAXJR=%_maxjr ]  [ ,PTCTIME=time3 ]  [ ,RSET={ GLOBAL | LOCAL } ]

APPLICATION-PROCESS-TITLE=object_identifier
	(only relevant if the OSI TP protocol is used in the application) Address component of the application entity title (AET). The AET is required if you are working with transaction management (commit functional unit), or if a heterogeneous partner requires an AET to establish a connection. object_identifier is the application process title (APT) of your application. Even if this is not defined by a standardization body, the relevant conventions for component1 and component2 must be observed when assigning an APT. Further information can be found in section "Application entity title (AET)" (OSI terms). In practice, the specified object_identifier must be unique within the network. If the application context (definition of the communication partner in the OSI-LPAP statement, "OSI-LPAP - define an OSI-LPAP partner for distributed processing based on OSI TP") agreed with a partner application contains the CCR syntax, you must enter an application process title here. An application process title consists of at least 2 and at most 10 components. It is specified in the following format: (component1,component2,...,component10) The components are specified in the form of positive integers. Symbolic names are assigned to some numbers of individual components, and can be used instead of the numbers. In the application process title, both the number of components and their positions within the parentheses are relevant, e.g. (1,2,3), (1,2,3,0,0) and (0,1,2,3,0) identify different application process titles. openUTM and the OSI standard only permit the following values or symbolic names for component1: 0 or CCITT 1 or ISO 2 or JOINT-ISO-CCITT The values permitted for component2 depend on the value of component1. If component1 = 0 or 1, values between 0 and 39 are permitted for component2 (0 <= component2 <= 39). If component1 = 2, values between 0 and 67108863 (226-1) are permitted for component2 (0 <= component2 <= 67108863). Values between 0 and 67108863 (226-1) are permitted for all other components. openUTM does not check whether the specified application process title is registered with a standardization body. Note for UTM cluster applications on Unix, Linux and Windows systems In the case of UTM cluster applications, the APT of the individual node applications is modified at node-specific level in order to ensure that the AET is unique. If the APT consists of fewer than 10 elements then the APT is extended by the index of the associated node when the node application is started. The index of a node is determined by the sequence of CLUSTER-NODE statements during generation. Example: If (1,2,3) is generated as the APT and if the UTM cluster application has two node applications, then the APT at runtime is as follows: (1,2,3,1) for node 1 (= first CLUSTER-NODE statement) and (1,2,3,2) for node 2 (= second CLUSTER-NODE statement) and If the generated APT already contains 10 elements then the APT remains unchanged for all node applications. In this case, links with OSI-TP implementations from other vendors may result in problems because the AET is not unique.
CONCTIME=	(connection control time)
time1	Maximum number of seconds for which openUTM monitors the opening of a session (LU6.1) or association (OSI TP). If the session or association is not opened within the specified time, openUTM shuts down the transport connection. This prevents the transport connection from being blocked if an attempt to open a session or association fails. This can occur if a message required to open the session/association is lost. CONCTIME=0 for LU6.1 means opening is not monitored. CONCTIME=0 for OSI TP means monitoring is set internally to 60 seconds. Default: 0 Minimum value: 0 Maximum value: 32767
time2	Maximum number of seconds for which openUTM is to wait for confirmation from the partner application when sending an asynchronous message. Once the specified time has elapsed, openUTM shuts down the transport connection. The job is not lost however. Monitoring prevents the connection from being blocked because a confirmation has been lost, or because the loss of connection was not reported to openUTM by the transport system. The value 0 means that monitoring is not performed. Default: 0 Minimum value: 0 Maximum value: 32767
MAXJR=	%_maxjr (maximal number of job receivers) Specifies the maximum number of job-receiving services that can be addressed in the local application at any one time. This corresponds to the number of APRO calls that can be active simultaneously. The percentage value refers to the number of generated sessions and associations (maximum number of LSES statements for the LU6.1 protocol + total number of parallel connections specified in OSI-LPAP statements; ASSOCIATIONS operand). It must be within the range 0 to 200. If you enter a value > 100, APRO calls issued before the session is reserved can be entered in a table. Default: 100, i.e. the maximum number of job-receiving services active at a particular time is equal to the number of sessions and associations. Minimum value: 0 Maximum value: 200
PTCTIME=	time3 (prepare to commit) This is significant only for distributed processing via LU6.1 connections. PTCTIME defines the maximum number of seconds for which a job receiving service waits in PTC state (transaction status P) for confirmation from the job submitter. Once this time has elapsed, the connection to the job submitter is shut down, the transaction in the job-receiving service is rolled back, and the service is terminated. This can lead to inconsistent data if the transaction is committed in the partner application (mismatch). The value 0 means that the job-receiving service waits indefinitely for confirmation. If a value > 0 is specified in time3 then this value is ignored by openUTM if a KDCSHUT WARN or GRACE has been issued. In this case, openUTM chooses the wait time in such a way that the transaction is rolled back before the application is terminated in order, if possible, to prevent the application from being terminated abnormally with ENDPET. Default: Value specified in MAX ...,TERMWAIT=time for the waiting time after PEND KP Minimum value: 0 Maximum value: 32767
RSET=	In the case of Distributed Transaction Processing, this operand defines how rolling back a local transaction affects the distributed transaction. A local transaction can be rolled back: by a RSET call issued in a program unit, or by rolling back a database transaction involved in the local transaction.
GLOBAL	After the local transaction is rolled back, the program unit must be terminated such that openUTM rolls back the distributed transaction. Default: GLOBAL
LOCAL	Rolling back the local transaction has no effect on the distributed transaction. Inconsistencies may occur in the distributed databases if some of the local transactions involved in a distributed transaction are rolled back while others are concluded. If RSET=LOCAL is specified, it is no longer possible to guarantee global data integrity in the relevant system components. This is now the responsibility of the application program units. You must decide when it makes sense to terminate the distributed transaction and when to roll back the transaction.