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-