This is a note of warning for those who are running LISTSERV under VM/HPO5:
 
There is a strange error running around in spool file processing (actually
just one of many for HPO5 but we will forget for now the spool APAR for HPO5
which to date at 18 PEs written against it) that can cause spool files to be
left on the spool file chain for a user with the in-use, EOF, and error bits
set.  This as a result causes the RDR command to fail when class * or the
class of "phantom" spool file is used.  The result (purely through the logic
of LISTSERV in processing the return code from RDR) is that files in DISK DUMP
or NETDATA formats are not understood by LISTSERV.  RDR will give a return
code of 36 when these "phantom" files are on the chain.  The RECEIVE and PEEK
commands will also fail in this same situation.
 
Another customer and I have been able to (finally) reproduce the symptom and
have forwarded the information to IBM Level II (sorry I do not have an APAR
number at this point).  As a workaround to this problem I created a temporary
version of the RDR command for my LISTSERV which has a modification at the
section of code which tests the SFBLOK for user hold or system hold and skips
such files to also test for inuse subsequently causing these files to also be
skipped in RDR command processing.  I found a CKPT start will also close the
spool files but that was not a very acceptable workaround.
 
As far as I can tell from the discussions with IBM, this problem should affect
HPO5 sites only (VM/SP5 I do not think is affected).  I will post additional
information on this problem as it becomes available.  This problem is know to
affect at least six or so customers that have contacted the IBM Support
Center.