The OSI-LPAP control statement allows you to define a logical access point in the local application for a partner application with which you wish to communicate on the basis of the OSI TP protocol. This logical access point is known as an OSI-LPAP partner. For each OSI-LPAP partner, you must define a logical partner name and the following logical connection properties:
The application entity title (AET) of the partner application. This must be defined if you are working with transaction management (commit functional unit) or if a heterogeneous partner requires an AET in order to establish a connection. The AET consists of the following components, which must be specified for the partner application:
the application entity qualifier (AEQ) of the remote access point (see the description of the ACCESS-POINT statement on "ACCESS-POINT - create an OSI TP access point")
The application process title (APT) of the partner application (see the description of the UTMD statement on "UTMD - application parameters for distributed processing")
The application context used for communication with the partner application based on the OSI TP protocol. If you are not using a standard application context, you define your application context using the APPLICATION-CONTEXT statement (see "APPLICATION-CONTEXT - define the application context"). If the application context of the OSI-LPAP partner contains the CCR syntax, an AEQ and an APT must be specified for the partner application.
The number and properties of connections to the partner application
Access rights of the partner application in the local applicationThe operands KSET and ASS-KSET are provided to define the access rights. In KSET you specify the highest level of access rights of the OSI TP partner that the OSI TP partner will have when it signs on to the local application with a user ID. You can restrict these access rights with the ASS-KSET operand. The restricted access rights take effect when the OSI TP partner does not pass a user ID when signing on, i.e. the "association user" is active.
Administration authorization of the partner application in the local application
Maximum values for the message queue of the OSI-LPAP partner.
If a communication partner can be accessed in various remote systems at different times, you can assign several addresses to this partner. This involves assigning several OSI-CON statements (with the same osi_lpap_name, see "OSI-CON - define a logical connection to an OSI TP partner") to a single OSI-LPAP statement. However, only one OSI-CON statement can be active at any one time. You can switch to a replacement connection by means of administration. All OSI-CON connections belonging to an OSI-LPAP partner must have the same local access point.
|
|
1only permitted on BS2000 systems
osi_lpap_name | Name of the OSI-LPAP partner of the partner application, which is used by the program units of the local UTM application to address the partner application. osi_lpap_name can be up to eight characters in length. osi_lpap_name must be unique and must not be assigned to any other object in name class 1. See also section "Uniqueness of names and addresses". |
APPLICATION-CONTEXT=application_context_name | |
Name of the application context to be used by the partner application. This is a mandatory operand. By default, openUTM supports the following application contexts:
Further information can be found in the description of the APPLICATION-CONTEXT statement on "APPLICATION-CONTEXT - define the application context". If the generated application context does not match that used by the partner application, openUTM rejects the connection request with the following UTM messages:
| |
APPLICATION-ENTITY-QUALIFIER=application_entitiy_qualifier | |
Application entity qualifier of the partner application. This is combined with the application process title to address a partner application when using a heterogeneous link or working with transaction management (commit functional unit). application_entitiy_qualifier is a positive integer used to call the partner application in the remote system. If the application context contains the CCR syntax, this is a mandatory operand. The name pair application_entity_qualifier and object_identifier must be unique within the UTM application. The application_entity_qualifier specified here must be assigned to access point in the partner application. Minimum value: 1 | |
APPLICATION-PROCESS-TITLE=object_identifier | |
The application process title of the partner application is to be specified as the object_identifier. The application process title is combined with the application entity qualifier to address a partner application when using a heterogeneous link or working with transaction management (commit functional unit). If the partner application is a UTM cluster application then the application process title (APT) of a node application must be specified here. Here it should be noted that when a node application is started, openUTM may extend the APT generated for this application by the node index of the application. See also the description of the APPLICATION-PROCESS-TITLE operand in the UTMD statement in section "UTMD - application parameters for distributed processing". If the application context contains the CCR syntax, this is a mandatory operand. The name pair application_entity_qualifier (of the OSI-LPAP statement) and object_identifier must be unique within the UTM application. For information on defining the APT, see the UTMD statement in section "UTMD - application parameters for distributed processing". | |
ASS-KSET= | ksetname2 ASS-KSET is only allowed if the local application is generated with user IDs. You may only set ASS-KSET in conjunction with KSET. You must specify the name of the key set in ksetname2. The key set must be defined with a KSET statement. You specify the minimum access rights that the partner application can have in the local application with ASS-KSET= . The key set specified in ksetname2 takes effect when the partner application does not pass a user ID to openUTM when establishing the association. The access rights result from the set of key codes contained in the key set generated with KSET= and with ASS-KSET= (intersection of the sets). For this reason, all key codes contained in ASS-KSET=ksetname2 should also be contained in KSET=ksetname1. Default: No key set |
ASSOCIATION-NAMES=association_name | |
Name defined in the local application for logical connections to the partner application. Connection names consists of the value of association_name as a prefix, followed by a serial number between 1 and the value of the ASSOCIATIONS operand, i.e. the number of parallel connections. The entire name can be up to eight characters in length. The maximum length of association_name depends on the value specified for ASSOCIATIONS. The following applies for the number of connections: Number of decimal places in the value specified for ASSOCIATIONS +number of characters in association_name <= 8 Example If ASSOCIATIONS=10 and The connection names are ASSOC01, ASSOC02,...,ASSOC10. These are used as association names in the local UTM application. The same name must not be defined for a user ID (USER) or a session name for distributed processing based on LU6.1 (LSES). | |
ASSOCIATIONS= | number Maximum number of parallel connections to the partner application. This depends on layers 1 - 6 of the OSI reference model defined by ISO (in particular on layer 4, the transport layer). The number of parallel connections must be coordinated with the generation of the partner application. Default: 1 |
BUNDLE= | master-lpap-name Name of a master LPAP. By specifying master-lpap-name, this OSI-LPAP partner becomes a slave LPAP of the corresponding master LPAP. The master LPAP specified here must be generated with a MASTER-OSI-LPAP statement. |
CONNECT= | number Number of connections to be established automatically with the partner application when the local application is started. Automatic connection setup can be requested in either the local application or the partner application. The connection is established as soon as both partners are available. The following applies on BS2000 systems: If the partner application runs on Unix, Linux or Windows systems, a value greater than 0 should be generated only if the BS2000 system is configured in such a manner that connections to this partner can be actively established. See also section "Coordinating the UTM and BCAM generations (BS2000systems)". Default: 0 Maximum value: |
CONTWIN= | number Number of connections for which the local application is to act as the contention winner. The local application is the contention loser for all other connections (ASSOCIATIONS= entry minus CONTWIN= entry). The contention winner of a connection is responsible for managing that connection. However, jobs can be started both by the contention winner and by the contention loser. If both communication partners attempt to initiate a job simultaneously, the connection is reserved by the contention winner job. This is a mandatory operand. The number of contention winners and contention losers must be coordinated with the generation of the partner application. Minimum value: 0 |
DEAD-LETTER-Q= | specifies whether asynchronous messages to this LPAP partner that could not be sent due to a permanent error are to be saved in the dead letter queue. Monitoring of the number of messages in the dead letter queue is enabled and disabled with the MAX ...,DEAD-LETTER-Q-ALARM statement. |
YES | Asynchronous messages to this LPAP partner that could not be sent due to a permanent error are saved in the dead letter queue provided (in the case of message complexes) no negative confirmation job has been defined. |
NO | No asynchronous messages to this LPAP partner are saved in the dead letter queue. Default: NO Main jobs for message complexes (MCOM) with negative confirmation jobs are never saved in the dead letter queue as the negative confirmation jobs are activated in case of errors. If the number of messages in the dead letter queue is limited with QLEV, messages may be lost in the event of errors. If the number is not limited, the openUTM page pool generated must be sufficiently large. If there is a threat of a page pool bottleneck, the dead letter queue can be locked during application run with STATUS=OFF. |
IDLETIME= | time Number of seconds for which the idle state of a connection is monitored. If the connection is not reserved by a job within the period specified in time, openUTM shuts down the connection. IDLETIME=0 means that the idle state of the connection is not monitored. Default: 0 If you specify a value that is greater than zero and smaller than the minimum value, KDCDEF replaces the value with the minimum value. |
KSET= | keysetname1 Specifies the maximum access rights of the partner application in the local application. The name of a key set is to be specified in keysetname1. The key set must be defined with a KSET statement. If the OSI TP partner does not pass a user ID to the local application for an OSI TP dialog, then its access rights for this OSI TP dialog result from the set of key codes that are in the key set generated with KSET= as well as with ASS-KSET= (intersection). The key set keysetname1 should therefore also contain all key codes that are in the key set generated with ASS-KSET= . If the OSI TP partner does pass a user ID, then its access rights for this OSI TP dialog result from the set of key codes that are contained in the key set of the user ID as well as in the key set of the OSI-LPAP generated with KSET. Default: No key set, |
PERMIT= | Authorization level of the partner application |
ADMIN | The partner application can execute administration functions in the local application. |
SATADM | The partner application can execute SAT preselection functions in the local application, i.e. it can activate and deactivate the SAT logging of certain events (UTM SAT administration authorization). |
(ADMIN,SATADM) | |
The partner application can execute administration and SAT preselection functions in the local application. Default: | |
QLEV= | queue_level_number Maximum number of asynchronous messages that can be accommodated in the message queue of the OSI-LPAP partner. If this threshold value is exceeded, further APRO-AM calls to this LPAP partner are rejected with UTM message 40Z. Default: 32767 |
STATUS= | Specifies whether the OSI-LPAP partner is locked. This status can be modified by the administrator using the KDCLPAP administration command. |
ON | The OSI-LPAP partner is unlocked. Connections between the partner application and the local application can be established or may be already in place. Default: ON |
OFF | The OSI-LPAP partner is locked. Connections cannot be established between the partner application and the local application. |
TERMN= | termn_id Identifier up to two characters in length, which indicates the type of communication partner. termn_id is not queried by openUTM, but is used by the user when querying or grouping terminal types, for example. termn_id is entered in the KB header for services, i.e. for services started by the partner application in the local application. Default: A6 |