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.