
{    The purpose of this procedure is to process the system flag alerting
{ this task that a PP request has been completed.  This routine is also
{ called directly by tasks that are waiting in ring 3 for a request to
{ complete.
{
{      When a PP respone has been received and Monitor has set the
{ system flag notifying the task of an RHFAM/VE PP response available, the
{ system flag handler is invoked to process the response.
{
{      Once the request type and response type are determined the
{ corresponding request response processor is called.  A separate
{ response routine is used for each logical request (i.e. send data
{ response handler, receive data response handler, etc.).  These
{ individual response handlers are in charge of processing the response
{ as it relates to the corresponding request.
{
{      Each of the request complete processors must check the response
{ to the request to determine what action is to be taken.  Normally the
{ following actions are performed (maintenance functions are possible
{ exceptions):
{
{      1)  If the request is not retriable because of a fatal hardware
{          error, the request is delinked, a fatal status is set in
{          the requestor's status variable, the corresponding
{          connection's status (if appropriate) is set to aborted, and
{          a hardware element error is flagged in the appropriate
{          configuration table entry.
{
{      2)  If the request has failed because the recovered error retry
{          limit is exceeded, the request is delinked, a fatal status
{          is set in the requestor's status variable, and the
{          corresponding connection's status (if appropriate) is
{          set to aborted.
{
{      3)  If the request failed because resources are unavailable, the
{          request is either reset to allow the PP's to attempt to
{          process the request again or the request is delinked and
{          the requestor is notified that the request should not be
{          posted again until resources are available.  The method used
{          is request dependent.
{
{      4)  If the request failed because a connection has changed states,
{          a request is posted to obtain the path status information
{          for the corresponding connection.  This information is then
{          used to determine the response given to the requestor.
{
{      5)  If the request failed and it is retryable, the request is
{          reset for the PP to retry.
{
{      6)  If the request was satisfactorily completed, the response
{          handler proceeds with one of the following events:
{
{          a)  set the requestor's status to "normal completion".
{
{          b)  post the next request when a sequence of requests is
{              required.
{
{          c)  re-issue the request when the request is a send or
{              receive data and further data transactions are required
{              to complete the request.

