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 *