Jeff Kell ([log in to unmask]) wrote: [...] : It started out OK (irrelevant lines snipped): : ESPUL ready...type '?' or any command followed by '?' for help : > su @.hpoffice : JOB# JOB OWNER DFID NAME PR CO F LINES STA : #J980 SUPRVISR MGR.HPOFFICE #O12342 UALMAIL 1 1 82 RDY : Then it turned nasty: : > pu @.hpoffice : JOB# JOB OWNER DFID NAME PR CO F LINES STA : ERROR OPENING SPOOLFILE (50) : VOLUME SET NOT MOUNTED - MOUNT PROBLEM (FSERR 113) : #J980 SUPRVISR MGR.HPOFFICE #O12342 UALMAIL 1 1 82 ERR : Hmmm... strange file indeed. Trying more stuff: : > t 12342 : NO SPOOLFILE(S) MATCHED YOUR SELECTION CRITERIA (448) : OK, let's try MPE: : :print o12342.out.hpspool : ^ : VOLUME SET NOT MOUNTED - MOUNT PROBLEM (FSERR 113) : The PRINT command failed. (CIERR 9080) : OK, more tricks: : listf @.out.hpspool,2 : ACCOUNT= HPSPOOL GROUP= OUT : FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE---- : SIZE TYP EOF LIMIT R/B SECTORS #X MX : Bad UFID for the file /HPSPOOL/OUT/O12342 (CIWARN 9165) : END OF FILE (FSERR 0) : File system error 0 encountered on list file. (CIERR 425) [...] : One final note (if the above sounds ominous), both MPE and the OpenDesk : in question in this particular case have those pesky 'X.nn.nn' revision : numbers :-) HPRC is bringing in the Desk folks to the call, but it : looks more like an MPE/Spooler thing. We will see... Sounds like a different problem than the one we discussed last summer. That one produced BAD VARIABLE BLOCK STRUCTURE (FSERR 105) in certain $STDLISTs where the Posix bytestream type manager had to start a new spool file block. The solution then was to rm() the spool file from within the Posix shell. This problem appears to be some form of UFID corruption, since you should *never* get VOLUME SET NOT MOUNTED messages on any files in OUT.HPSPOOL. Linked spool files only reside in MPE_SYSTEM_VOLUME_SET, which you cannot dismount, so I suspect that message is bogus and follows from the trashed UFID. Based on the series of steps you showed, I think I would first try to eliminate or confirm ESPUL's role in this, since the problem first appeared after the > pu @.hpoffice. Try doing the same first two steps with SPIFF: > s @.hpoffice then > p @.hpoffice If you get similar results, then ESPUL is an innocent bystander and we have to look further into MPE. If the problem only occurs when ESPUL is used, it should narrow down the search considerably. In any case, it looks like a quick test. BTW, I don't intend the above as a knock on ESPUL. It's a popular package and lots of people use it. But any software (even the MPE spooler :-)) can do strange things at times. Hope that helps. -Larry "MPE/iX Spoolers 'R' Us" Byler-