Actually, it also depends upon whether your 'controller' is a pc or a
traditional dumb terminal.  The solution I used a number of years ago (and
think was discussed here in the distant past) was the old 'P31' technique
using dumb terminals which were dual-port.  We had very specific label
requirements (this was producing thermal barcode labels for a poultry
processor, where every label was unique, and allowed me to control a
million+ label inventory), and had to use non-hp rugged-weather printers.
The application was written in TRANSACT, with the printer driver written
in COBOL - the code could 'program' the printer with one set of escape
sequences displayed to the 2nd port, or download specific data and request
the needed label using a different set.

In this case, though, each station had a dedicated printer hard-wired to
the terminal, and the OS had no idea that the printers even existed.  I
maintained a configuration 'file' which told the application whether a
particular port had a printer attached.

So yes, it can be done, but it is VERY hardware specific and you would
need to develop and maintain a 'configuration' matrix independent of the
OS to build into the application the ability to tailor its output for the
various hardware possibilities.

I suppose a shared printer might be managed using IPC files, with the
individual stations writing to one or more IPC files which were fed via an
independent server to the appropriate printer(s) - in which case the
server would have hot control over the printer(s).  There are probably
several other approaches available... but I know these do, or at least
did, work and work well.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *