Hi Mark, and other WASD users ...

I think it's worth pointing out that this is an interraction between:

* Global buffers attached to files opened at an inner mode (such as SYSUAF
  and RIGHTSLIST); normal USER-mode opens do not appear to be a problem.
* Outstanding (pending) Direct I/Os when the program exits.

Essentially, RMS tries to wait for the DirIO to complete during image
rundown, leading the process to into RWAST.

In the long and winding road to understanding the problem, we learned that
writing an EOF mark to a MBAxxx device is treated as a DirIO.  Which,
unfortunately, is exactly what WASD does when "DclProctor" enabled. The
Proctor mechanism creates a mailbox and writes an EOF to it.  A good example
is the WuCME agent for LetsEncrypt.

Colleagues in Europe have reproduced the behaviour, using a small C program,
on pretty much all versions of OpenVMS X86.  VSI are aware of the issue and
I expect a fix will be forthcoming.

If you find your WASD server is stuck in RWAST for an extended period, a
possible fix is to

    $ TYPE MBAxxxx:

where the MBA device is one held open by WASD (use SDA SHOW PROCESS/CHAN to
find them, or use $ SHOW DEV/FULL MBA and look for those owned by
HTTP$SERVER).

The short-term workaround is to remove global buffers on SYSUAF and
RIGHTSLIST and reboot the system.

Regards,

	Jeremy Begg

>> But what does that mean exactly: "DO NOT USE global buffers on
>> SYSSUAF/RIGHTSLIST" What would you have to do to be doing this ?

>OK, fair enough.  I was perhaps further in the dark than most regarding
>global buffers.  I had not specialised in any RMS over the years.  AFACT, the
>easiest way to tell if you have global buffers enabled on a file, SYSUAF, for
>example, is

>$ DIRECTORY /FULL SYSUAF  ! if you have the logical name defined
>$ DIRECTORY /FULL SYS$COMMON:[SYSEXE]SYSUAF.DAT  ! otherwise

>Buried not too down in that output is

>| File attributes:    Allocation: 48, Extend: 10, Maximum bucket size: 3,
>  Global buffer count: 0, No version limit, Contiguous best try
>  ^^^^^^^^^^^^^^^^^^^^^^

>My X86 had this value by default.
>Anything greater than zero is currently an issue.

>Same (apparently) for RIGHTSLIST.

>$ DIRECTORY /FULL RIGHTSLIST ! if you have the logical name defined
>$ DIRECTORY /FULL SYS$COMMON:[SYSEXE]RIGHTLIST.DAT  ! otherwise

>To benchtest a reproducer during investigation I had to

>$ SET FILE SYSUAF /SHARED /GLOBAL_BUFFER=100

>and then reboot.  To reset global buffers do

>$ SET FILE SYSUAF /SHARED /GLOBAL_BUFFER=0

>and then reboot.

>If your DIRECTORY/FULL shows zero global buffers count then :-)

>(Anyone wishing to comment on this further please chip-in.)

>--------------- Original Message ---------------
>Subject: [Info-WASD] X86: DO NOT USE global buffers on SYSSUAF/RIGHTSLIST
>To: info-WASD@vsm.com.au
>From: mark.daniel@wasd.vsm.com.au
>Date: Wed, 22 Apr 2026 08:47:58 +0930

>An issue deploying WASD on X86 VMS has been under intensive investigation for
>the best part of 9 weeks now.

>Specialist comment:

>> So this is a REAL OpenVMS x86-64 V9.2-3 problem !!!

>> ADVICE: when trying to use WASD on VSI OpenVMS x86-64 V9.2-3 + patches,
>> DO NOT USE global buffers on SYSSUAF/RIGHTSLIST until VSI has diagnosed
>> and fixed this problem.