Interface between ISPF and APL2

The interface between ISPF and APL2® is like a telephone call. If one side of the communication is broken, any attempt to use the interface causes error messages to be generated. The link between the two products can be broken by:
  • The APL2 user hanging up. For example, if a new workspace is loaded and there are still ISPF service requests that have not completed (for example, options in the selection panel process), the ISPF Auxiliary Processor (ISPAPAUX) issues an error message, informs ISPF and waits for the process to begin again (by hanging up until another ISPF request is made). ISPF issues a severe error message telling the user that the link has been damaged.

    If the user is in ISPF TEST mode, then, on user request, ISPF attempts to reshow all panels traversed in an effort to unnest all service requests. When all requests have been unnested, ISPF will again wait for the ISPF Auxiliary Processor to make a request. During the unnesting process, any attempts to invoke APL2 functions are rejected, severe error messages are issued, and any requests for APL2 variables are logged.

  • The APL2 user cutting the line. For example, if the user terminates APL2 while there are still outstanding APL2 function requests from ISPF (for example, options in the selection panel process), the ISPF Auxiliary Processor (ISPAPAUX) issues an error message, informs ISPF, and terminates. ISPF issues a severe error message telling the user that the link has been damaged, and if in TEST mode, proceeds to unnest as previously described. When all requests have been unnested, APL2 will be terminated. During the unnesting process, any attempts to invoke APL2 functions are rejected, severe error messages are issued, and any requests for APL2 variables are logged.
  • An APL2 failure. This is handled as if the line were cut, assuming APL2 performs recovery and returns to ISPF.
  • An ISPF failure. In this case, ISPF or the logical screen can fail, causing APL2 termination.