HP OpenVMS Systems

ask the wizard
Content starts here

Spooled Devices, Print Queues, and Allocation?

» close window

The Question is:

How do I set up a print queue so that I can restart it even when 'device is
 allocated to another user'
(Note:  I do a SHOW SYS and it shows  V7.1    not V7.1-2  so it may be 'other')
Perhaps this cannot be done?
I have read other related questions, answer being 'find the other user(s), stop
 them, then start
the queue.'  Not what our customer wants:  the alpha is driving a PABX, about
 20 processes
involved.  Switching to the standby alpha, stopping the alpha now on standby,
 (re)starting the
print queue, restarting the application etc. takes about 5 minutes.  They don't
 like it.
Way things are set up now:
     . . .
(it does not check the returned status)
it also does a
        STATUS = SYS$CREPRC( . . . )
to launch each of  the other processes, with a CLI image to execute:
(There is a seperate command procedure for each OTHER_PROCESS_N)
These other processes, if they have a message to be output, essentially
 generate a message string
which is mailed to MAIN.  MAIN receives the  message and writes to $PRINTER by a
SYS$QIO( . . . )   No contention there.  If one of these other processes
 crashes (we hope not!)
there will be a stack traceback to help us figure out what happened.  MAIN will
 re-start the
Of course the customer can also
I have noticed that when I do   $ STOP/QUEUE/RESET PRTQUE
and the queue is really stopped,  we still get output from MAIN via the
 SYS$QIO( . . . )
I tried:
and indeed one could    $PRINT/QUEUE=PRTQUE_GENERIC  FILENAME.xxx
but the other usual printout when starting up the system, didn't appear
A print queue is not the same thing as a device?
Perhaps there is NOT some /OPTION so that the SYMBIONT  won't care that the
 device is
already allocated to another user  -  (this is reminiscent of the   'SYMBIONT
 starts multiple
queues on same LPA device'   question and the workaround)
then maybe we and the customer should quit being so cheap and just get a
 seperate printer
for the print queue

The Answer is :

  If the device is allocated to another user, you must first determine
  who and why, and get the device deallocated -- OR DO NOT LET THE DEVICE
  BECOME ALLOCATED.  There is no automated means useful for this purpose,
  short of deleting the process that is blocking the starting queue.
  If you must have a queue that competes for access with another user,
  you will have problems maintaining the queue and the access, and will
  need to provide manual or automated means to detect and to resolve
  access conflicts.
  You could and should seriously consider moving the printer out onto
  an external JetDirect or a terminal server (or a printer-integrated
  JetDirect or NIC), and configure the server to share access into the
  printer.  (This avoids the direct host-based connection, of course,
  using LAT or telnet or lpr/lpd to access the printer remotely.  This
  also permits multiple queues to target the device, so long as each
  accessor is configured to correctly share the printers.  Typical
  OpenVMS print queue configurations allow the network printer to be
  released between jobs, and thus allow other systems to share the
  network printer.  This is possible both with LAT and IP-based (telnet
  and lpr/lpd) queues.)
  This particular site is also using spooled access to the printer,
  which is quite different from printing via a print queue -- spooled
  device access is intended for applications that are not particularly
  willing or able to share the specified device, but that wish to gain
  some of the benefits of a print queue.  (It might be possible, for
  instance, to implement $sndjbc or similar calls into the application
  itself -- this would allow the application to access and to share
  the queue.)
  And yes, a second printer device can likely resolve this, and may
  well be the most expedient and most economical approach.  If you
  do choose this approach, the OpenVMS Wizard strongly encourages
  that only printers with NICs be considered.
  There have been corrections made in the area of spooled device
  handling, please see and please apply the available ECO kits.  And
  yes, please seriously consider an upgrade from V7.1 or V7.1-2 to
  V7.2-2 or V7.3-1 or (as available) later 00 neither V7.1 nor
  V7.1-2 are currently supported by HP.

answer written or last revised on ( 11-JUN-2003 )

» close window