This chapter provides detailed information on various aspects of Remote IMS related to LU 6.2 communications. It assumes that you have a working knowledge of the basic operation of Remote IMS from the chapter How Remote IMS Works. A detailed understanding of PC or LU 6.2 communications is not required.
When running the Remote IMS test or the Remote IMS Requester (or any LU 6.2 application), an LU 6.2 session must exist between the two communications systems before starting a conversation between the two application programs.
If a suitable session is available when starting Remote IMS, the communications product routes the conversation flows over the available session, otherwise the communications product establishes a new session. Whether or not the session is suitable is determined by the communications product.
When the conversation is terminated, the Remote IMS Server returns control to IMS/ESA and the dependent region is available for other transactions. However, the LU 6.2 session may be maintained by the communication products. Whether or not the session persists is controlled largely by the communications product.
In the chapter Requester Configuration, it states that performance may be improved, in some cases, by changing the WhenStopTP value to Region. The reason for this is that if the TP instance is left active, after the conversation is terminated, subsequent conversations may be started faster. This is mainly because the communications product are likely to keep the LU 6.2 session active and it can be used if a subsequent IMS Option application makes another Remote database call. However, since the communication product controls these sessions (and may offer its own configuration to control them), we cannot say exactly if this will occur. You may need to experiment to determine your best WhenStopTP setting.
The communication products provide for operational control of APPC Transaction Programs, LUs, links or connections, sessions, and conversations. When viewing the TP programs or connections in the communication product, you may see an LU 6.2 session to your mainframe after Remote IMS terminates. You must check whether or not an active conversation exists on the session to know whether you are connected to a Remote IMS Server program. If you do not have an active conversation, then you are not connected to the Server and an IMS/ESA dependent region is not occupied.
The CPI-C calls made by the Server to APPC/MVS are always synchronous. Specifically, the Server issues a CPI-C "Receive and Wait" call to receive an LU 6.2 message. This means that APPC/MVS does not return control to the Server until a message is available. This may be a long time depending on how often the IMS Option applications makes DL/I calls to Remote databases. While waiting for a message, the Server program is in a wait state pending a return from APPC/MVS. If you need to terminate the Server program for any reason, one way is by deactivating its partner LU (as opposed to stopping the region). APPC/MVS is immediately notified of the lost session (by VTAM) and returns an error code to the Server program. The Server will backout any updates and return control to IMS/ESA - freeing the region.
Note, however, that this technique does not immediately free the region in the case of the Server program's DL/I call waiting on a locked segment. See the next section Suspended States - Requester for more details.
Your application program is suspended until it receives the results of a DL/I call from the Requester. There are two different cases where you may be waiting for a long period. The first is when connecting to the Server and the second is when the Server makes a DL/I call to IMS/ESA. The Requester monitors the length of these wait periods and, if too long, issues a popup window asking for instruction on how to proceed. Your choices are to continue waiting or to terminate the application. The amount of time which elapses before seeing this popup is configured in the Requester's rmtims.ini file. The settings are named ConnectTimeout and DLItimeout. See the chapter Requester Configuration for instructions on setting these values.
A DL/I call can take a long time to complete if the segment is locked by another user. The Server's DL/I call does not complete until the lock is released. During this time your application is waiting. When the DLItimeout period is exceeded you see the popup window.
Connecting to the Server may take a long time. To connect, the Requester must establish a new conversation with the Server and IMS/ESA must schedule the Server into a dependent region. If a dependent region is not available, IMS/ESA queues the request until one is available. Depending on your system configuration and usage, this could be a long time. When the ConnectTimeout period is exceeded you see the popup window.
If you choose to terminate your application from the DL/I timeout popup, the Requester ends all communications. This includes deallocating the conversation to the Server. However, since the Server is waiting for IMS/ESA to complete a DL/I call, it is not released immediately from the dependent region. Once the DL/I call completes (such as when the database lock is freed) the Server is notified by CPI-C of the ended conversation. The Server will then backout any pending updates and exit to IMS/ESA - freeing the dependent region. The delay in the Server being released from the dependent region in this case is not caused by using the popup to terminate it. The same thing would occur if you terminated the application by closing (or killing) the process or by using the communication product's operator services to deactivate it. The Server remaining in the region in this particular situation is just inherent in the way that CPI-C driven applications behave in IMS/ESA.
If you choose to terminate your application from the connect timeout popup, the Requester ends all communications. However, the conversation is in an incomplete state. It is beyond the scope of this document to describe the CPI-C architecture with IMS/ESA to explain why this occurs, but the problem is not unique to Remote IMS. There are two possibilities:
In addition, you may also want to perform manual cleanup if you are required to use the WhenStopTp=Never setting with the MSSNA product.
However, manual intervention might not be required, because eventually the mainframe communications are cleaned up. For example, when a dependent region becomes available the Server is scheduled into it by IMS/ESA. The Server is notified by CPI-C that its partner ended the conversation. The Server responds by exiting back to IMS/ESA and the cleanup is complete. However, if you continue trying to terminate connections you may eventually receive communication errors. For example, you may exceed the SNA mode's session limit. The "mode" you are using is defined with your CPI-C Side File or in Mainframe Manager Server configuration. See your communication definitions for the session limit for the mode you are using. The best solution to this problem is to setup your mainframe system to avoid these pending connections.
Remote IMS uses LU 6.2 "sync level zero" protocols for all of the messages. This improves performance over using sync level 1 as there are no confirmation flows issued by the LU 6.2 communications for each message sent. The Requester and Server use their own technique for message confirmation. For the most part, confirmations are inherent based on the type of application Remote IMS is (DL/I request, DL/I response), but, for all error conditions and system requests the Requester and Server provide their own confirmation messages.
This section is provided primarily for reference purposes. It may be important if you are developing other CPI-C applications which will run in the same Windows process as the Remote IMS Requester.
The Requester uses a combination of "synchronous" and "asynchronous" CPI-C calls. The actual type used by the Requester depends on the communications product and the kind of packet being sent. In general, asynchronous calls are used when a synchronous call could "block" other CPI-C applications for extended periods of time. When issuing asynchronous calls, the Requester "sleeps" between repeated calls and yields its CPU time-slices. The length of the sleep time increases the longer the request is outstanding and initially is very short to ensure rapid processing of fast requests.
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.