In <68E9DFE1.9090307@pmoylan.org>, on 10/11/25
    at 03:41 PM, Peter Moylan <peter@pmoylan.org> said:

I've done the first pass through pending mail, so I have a feel for what
I need to deal with. I think I'd better start with Doug's problem,
because a comment from Steven suggested that this might not be a pure
"out of memory" problem.

I misread the stack the first time through.  Doug's problem had nothing to
do wih memory.  Here's an annotated errinfo.$$$

#RTS: unhandled exception #3: invalid location
000289FF  00000001  WEASEL.EXE  000389FF   OS2Sem_SemError+5F
000474A6  00000001  WEASEL.EXE 000574A6   TaskControl_Release+16
0001DB16 00000001  WEASEL.EXE 0002DB16HammerCheck_ClearPasswordError+B6
TaskControl_Release
00031E0C  00000001  WEASEL.EXE 00041E0C   AUTH+38C> -> HammerCheck.ClearPasswordError
00031554  00000001   WEASEL.EXE 00041554SMTPCommands_HandleCommand+1F4->call esi
0004B168  00000001  WEASEL.EXE 0005B168   HandleCommand+38 ->SMTPCommands_HandleCommand
0004BB41  00000001  WEASEL.EXE 0005BB41
000477B7  00000001  WEASEL.EXE  000577B7
0000FB4B  00000001  XDS230M.DLL  0000FB4B
00020296  00000001  XDS230M.DLL  00030296

My current analysis says that the Obtain at

HammerCheck.MOD:384
         Obtain (HammerList.access);

in ClearPassword failed because the DosRequstMutexSem in Obtain at

TaskControl.MOD:655
         status := OS2.DosRequestMutexSem (L, OS2.SEM_INDEFINITE_WAIT);

terminated with ERROR_INTERRUPT (most likely).  This caused the
DosReleaseMutexSem in Release at

TaskControl.MOD:667
         errno := OS2.DosReleaseMutexSem (L);

to fail.

FWIW, I think you need two versions of Obtain.  One that returns status so
that the caller can use the status to figure out how to proceed and a
second version that invokes SemError to report mutex errors because the
caller contains no error handling code.

If you implement this, you probably want to enhance SemError to report the
failing operation along with the status.