z/OS Communications Server: SNA Programmer's LU 6.2 Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Choice of response

z/OS Communications Server: SNA Programmer's LU 6.2 Guide
SC27-3669-00

Whether an application program reports an error or performs a more drastic action, such as deallocating a conversation or ending the session, depends on the severity of the error and the ability of the logic within the application program to recover from the error. A few rules govern which step the application program should take. However, the most drastic step (ending the conversation and terminating the session) should be used only if the error seems to be caused by a violation of the architecture's protocols.

For most errors, if the application program cannot recover from the error on the conversation, only the conversation should be ended. Sometimes APPCCMD CONTROL=DEALLOC|DEALLOCQ cannot be issued (possibly because another APPCCMD macroinstruction is outstanding), and in these cases the application program must use the APPCCMD CONTROL=REJECT, QUALIFY=CONV macroinstruction. (For more information on ending a conversation, see Deallocating a conversation.)

When an application program reports an error on a half-duplex conversation with APPCCMD CONTROL=SEND, QUALIFY=ERROR, it is placed in SEND state, regardless of the state of the conversation up to that point. It can send additional data regarding the error or do anything else that the application program can do in SEND state. VTAM® creates an FMH-7 as a result of this macroinstruction and stores it in the SEND buffer. The application program can use a macroinstruction with the FLUSH capability to force VTAM to send the error notification to the partner. For full-duplex conversations, the FMH-7 is not buffered, but sent immediately to the conversation partner.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014