Extensions are available for the following R/2 Releases:

• Release 5.0D
• Release 5.0E
• Release 5.0F
• Release 5.0G

These extensions are described in the following topics.

If you are using UTM Version 3.3, your system assumes that you are also using UTM-D V2.0. In this case, the driver operates synchronously without the additional protocol.

If you do not want to use the synchronous procedure due to the changes involved, you can keep the asynchronous procedure by stating communication type A in the XCOM table.

On system startup, any activity indicators still existing in the queues are reset. Queues are deleted if all of their LUWs have been transferred. New driver processes are started for queues that were started automatically and still contain LUWs to be transferred. These actions are performed before the APLZ restart.

Normally, a driver process stops as soon as the all queue elements have been transferred. However, queue elements are often inserted at the end of the queue while queue elements at the beginning are read out by the driver and sent to the recipient at the same time.

If the transfer is not continuous, it often happens that there are no more queue elements in the queue and the driver process stops. Fractions of a second later, new elements are placed in the queue. A new driver process has to started. This requires considerable time and resources (setting up a connection, creating a mode, performing user authorization checks, providing ABAP runtime environment, etc.).

It may be me more efficient to not letting the driver stop as a queue gets empty but to inform the partner program about the state of the queue. The partner program can go into a waiting state and then try to receive more queue elements. In this processing mode, waiting only occurs with the partner program.

To change the driver to this procedure, you must set the NONSTOP variable to 1.

You can use the non-stop procedure only if you start the driver remotely. Message SU031 reports that the queue is empty.

If a connection or a driver process abnormally ends, the queue activity indicator is automatically reset. No manual intervention with Transaction TMQM is required. The partner application can thus continue reading out elements from the queue at a later point of time.

Asynchronous communication can be set up from an SAP report to an UTM partner, and messages can be sent. Here, the report only makes an ALLOCATE call and any SEND calls required. RECEIVE calls, of course, are not permitted.

You can use the communications type in table XCOM to control whether the UTM transaction is to be exited by SAP when communication is started (PEND RE is the standard) or to be kept open (PEND KP). The communications type K controls PEND KP. Keeping the transaction open has advantages with regard to error handling.

If you are using UTM-D V2.0, synchronous communication can be started even when the SAP transaction already has the long-running status. To do this, you simply have to assign transaction code Y2SA to transaction class 10. If the DOUT driver is also working synchronously, you must also assign Y1SA to class 10.

To disentangle asynchronous driver communication from general asynchronous communication (which can considerably hinder driver processes), an additional transaction code (Y3SA) and a new class (14) were defined for general asynchronous communication.