🚀 go-pugleaf

Once again, I am bringing to the attention of one and all, a Mailer problem
which I reported on several previous occasions but still has not been resolved.

During an almost three hour period yesterday (precisely 02:58:18), our Mailer
(R2.08) was spewing out "Mailer waiting for work" messages on its console.
During this period, 3,065,530 lines were written to the console, or an average
of about 286 lines per second.  Not all the lines were "Mailer waiting for
work" messages; in fact, approximately 600 mail items were also handled during
the period.  But Mailer never entered a wait state after processing an item;
it resumed looping.

On analyzing the possible cause of the loop being entered and broken out of
(which occurred spontaneously), I noted that the last entries in the log
before the loop began were two CP messages (from a remote location via RSCS)
which were logged with no intervening console lines; i.e., the second message
was already queued before processing of the first message was completed.  The
first entry in the console log after which looping did not resume was the very
next CP message received (or at least logged), also via RSCS, nearly three
hours later.

I am speculating that the bug is related to the handling of IUCV interrupts.
Incoming spool files generate I/O interrupts and are correctly handled, but
subsequently control is returned to the IUCV interrupt handler, so the loop
continues.

Am I the only one experiencing this problem?  I have not seen reports of this
phenomenon from anyone else.

- Lawrence