|
HP OpenVMS Systemsask the wizard |
|
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:
$ DEFINE/SYSTEM/NOLOG $PRINTER TTA1:
$ SET TERMINAL/DEVICE_TYPE=LA120/PERMANENT TTA1
$ NODE=F$GETSYI("NODENAME")
$ DEVICE=F$TRNLNM("$PRINTER","LNM$SYSTEM_TABLE")
$ INITIALIZE/QUEUE/START/ON='NODE'::'DEVICE' PRTQUE
. . .
$ RUN MAIN.EXE/DETACHED/ERROR=$PRINTER/OUTPUT=$PRINTER
MAIN not only does: STATUS = SYS$ASSIGN('$PRINTER',MYCHANNEL,,)
(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:
$ DEFINE SYS$OUTPUT 'F$TRNLNM("$PRINTER")'
$ RUN OTHER_PROCESS_N.EXE
(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
process.
Of course the customer can also
$ PRINT/QUEUE=PRTQUE FILENAME.xxx
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:
$ DEFINE/SYSTEM/NOLOG $PRINTER_TTA1 TTA1:
$ SET TERMINAL/DEVICE_TYPE=LA120/PERMANENT TTA1
$ NODE=F$GETSYI("NODENAME")
$ DEVICE=F$TRNLNM("$PRINTER_TTA1","LNM$SYSTEM_TABLE")
$ INITIALIZE/QUEUE/START/ON='NODE'::'DEVICE' PRTQUE
$ INITIALIZE/QUEUE/START/GENERIC=PRTQUE PRTQUE_GENERIC
$ DEFINE/SYSTEM/NOLOG $PRINTER PRTQUE_GENERIC
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.
|