II09979: IEAVESAR REPORTS INVALID PSANSS PSAMODEW

APAR status

• INTRAN

Error description

• IEAVESAR logrec records can be cut for an invalid PSAMODEW even
  after OW19539 has been installed.  If the record(s) show only
  PSANSS (the x'0080' bit of the first bytes in PSAMODEW) was
  invalidly ON, these records can safely be ignored.  They do NOT
  indicate an overlay of the PSA, but rather normal recovery for
  a timing situation that can occur when processing a CALLRTM
  TYPE=ABTERM for another task.  The timing window is as follows:
   - A CALLRTM TYPE=ABTERM is issued against some target task
     while it is running on another processor.
   - RTM in turn calls STATUS to set the target task
     nondispatchable.
   - STATUS in turn causes an external interrupt to be generated
     against the CPU that is running the target task.
   - At the point where that external interrupt is recognized,
     the target task is in the process of deleting an EUT-type
     FRR from the stack.  Specifically, the FRR has been deleted
     but the PSANSS bit (indicating there is an EUT-type FRR on
     the stack) has not yet been reset.
   - The external interrupt handler returns to the dispatcher
     to save status.  Because PSANSS is set, the dispatcher also
     saves the normal FRR stack.
   - RTM then alters the RBOPSW of the target task so it points
     to an SVC 13 instruction instead of into SETFRR DELETE
     processing.  In fact, SETFRR DELETE will NOT complete
     because of the abterm.
   - The target task is made dispatchable again.  When it is
     dispatched, the dispatcher restores status (including the
     modified PSW) and also restores the normal FRR stack,
     INCLUDING the PSANSS bit in PSAMODEW.
   - RTM now starts running under the target task (due to the
     SVC 13) to complete the abterm process.  When IEAVELCR is
     invoked, it finds the normal stack contains no EUT-type
     FRRs (it was deleted before the external interrupt that
     forced this task out of the CPU), but PSANSS is still on.
     It therefore corrects PSAMODEW to turn PSANSS off and
     records the fact to logrec.
  Turning PSANSS back of is, in fact, the correct action to take
  in this case as SETFRR DELETE processing will never be
  completed.  The key here is that PSANSS will be the ONLY error
  noted in the logrec record, and OW19539 must already have been
  installed!
  

Local fix

• If OW19539 has been installed, and PSANSS is the only error
  reported, these logrec records can safely be ignored.
  

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels