An asynchronous exit routine runs at a higher dispatching priority than the mainline part of the application program. Thus, if an application program uses ECB posting for a macroinstruction (OPTCD=SYN), the program can be notified of an event that causes exit routine scheduling before it recognizes that the macroinstruction has been posted complete. This can happen even though the event causing the exit routine to be scheduled occurs after the macroinstruction is posted complete. Here are a few examples of this condition:

1. SIMLOGON is issued and its ECB is posted complete with (RTNCD,FDB2)=(X'00',X'00') set in the RPL. However, before the application program recognizes this, the LOGON exit routine (CINIT received) or NSEXIT exit routine (Notify or NSPE received) starts to execute.
2. SESSIONC is issued to send SDT; the ECB is posted complete with (RTNCD,FDB2)=(X'00',X'00') set in the RPL. However, before the application program recognizes this, the DFASY exit routine receives a SIGNAL request.
3. OPNDST OPTCD=ACQUIRE is issued and its ECB is posted complete with (RTNCD,FDB2)=(X'00',X'00') in the RPL. However, before the application program recognizes this, the NSEXIT exit routine starts to run because a CLEANUP RU is received, perhaps because of a path outage in the session just established.

Either the application program must be prepared to handle situations like these or else it should be coded to avoid them. One such way to code, in the normal operating system environment, is to use an RPL exit routine instead of an ECB post; then, the RPL exit routine runs before the exit routine that notifies the application program of the second event. Another useful facility is the user correlation field available with SIMLOGON and certain other macroinstructions; this allows the application program to relate certain exit routine events (such as receipt of CINIT or Notify) with the original macroinstruction, even though the macroinstruction completion posting has not yet been recognized.