Responding to an FMH-5

An application program participates in a conversation initiated by another transaction program by issuing APPCCMD CONTROL=RCVFMH5 to receive the FMH-5 that was sent.

Application programs must always issue APPCCMD CONTROL=RCVFMH5 when notified of the arrival of an FMH-5. They cannot reject a conversation request by refusing to receive the FMH-5.

If an application program cannot support a conversation when notified of the arrival of the FMH-5, it can wait to issue APPCCMD CONTROL=RCVFMH5 until it can do so, or it can issue the macroinstruction and then use one of the abnormal conversation termination macroinstructions to immediately end the conversation. (See Checking the received FMH-5 for more details on ending the conversation.)

The RCVFMH5 macroinstruction specifies the following items:
  • A buffer in the application program's storage where VTAM® can store the FMH-5
  • The length of the buffer area
  • The continuation modes for receiving normal and expedited information

(For details on the syntax and operands for the macroinstruction, refer to the z/OS Communications Server: SNA Programmer's LU 6.2 Reference.)

If several FMH-5s are waiting to be received, and those FMH-5s can be received, they are processed in a first-in, first-out manner. When persistent sessions are used, the application program might be unable, temporarily, to receive FMH-5s.

Application programs are made aware of an FMH-5 to be processed from the following sources:
  • Feedback from the APPCCMD macroinstruction, which returns two parameters (FMH5RCV and FMH5LEN) that indicate there is an FMH-5 waiting to be received. FMH5LEN indicates the length of the FMH-5. The RPL fields are set as long as an FMH-5 is waiting to be received. See Keywords and returned parameters for a complete list of the macroinstructions on which these parameters are returned.
  • The ATTN exit, which is driven when an FMH-5 is received. The ATTN exit normally is driven only once for each FMH-5. With persistent LU-LU sessions, it might be driven once for each FMH-5 for each application instance.
If the ATTN exit is present, both methods are available to the application program.

As an alternative to these types of notification, the application can bypass ATTN exit processing by issuing an RCVFMH5 request that is queued by VTAM before the FMH-5 is received. See Queuing the RCVFMH5 macroinstruction for more information. Application programs can also maintain an internal timer and periodically issues APPCCMD CONTROL=RCVFMH5, QUALIFY=NULL. In this case, the application program must deal with nonzero return codes when no FMH-5s are available to receive.