sl@van-bc.UUCP (Stuart Lynne) (06/02/90)
In the man page for lpadmin: -vdevice ..... Note that there is nothng to stop a system manager from associating the same device with more than one printer. Does this mean that there is nothing to stop you from doing this so don't do it? Or that lpsched is designed to pay attention to having multiple destinations some with the same physical device. Which is what I need to do. I have two different packages that want to install specialized lp destinations with appropriate filters. Can I install both and have lp figure out how multiplex the requests for the two destinations to the one physical printer? Or will I have to hack the two interfaces together and add options? On van-bc (SCO Xenix 2.3.2) at least it appears as though lp gets things mixed up and start's to send requests to both destinations simultanously. This is approxiametely what I did to test lp: lpadmin -pdest1 -idest1 -v/dev/ttyal lpadmin -pdest2 -idest2 -v/dev/ttyal lp -ddest1 file1 lp -ddest2 file2 What I wanted was for file1 to be printed, followed by file2. What I got was file1 intermingled with file2 being printed. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax) -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
cpcahil@virtech.uucp (Conor P. Cahill) (06/02/90)
In article <453@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >In the man page for lpadmin: > > -vdevice ..... Note that there is nothng to stop a system > manager from associating the same device with more > than one printer. > >Does this mean that there is nothing to stop you from doing this so don't do >it? No. What it means is that you can do it, but you must set things up so that they work correctly. This has been used lots of times to have a printer with several kinds of paper that can be loaded and each type of paper will get it's own queue while the device for all of the queues is the same. In this scenario, the system administrator must enable 1 and only 1 of the queues at the same time (hopefully just after he placed the appropriate paper into the printer). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
bill@twg.bc.ca (Bill Irwin) (06/02/90)
In article <453@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >Which is what I need to do. I have two different packages that want to >install specialized lp destinations with appropriate filters. Can I install >both and have lp figure out how multiplex the requests for the two >destinations to the one physical printer? > >Or will I have to hack the two interfaces together and add options? > >What I wanted was for file1 to be printed, followed by file2. What I got was >file1 intermingled with file2 being printed. I have had this same problem. I have one printer that is used for four lp destinations. When jobs are queued to two or more of the destinations at the same time, you get garbage. The solution I came up with works very well. It involves adding some lines to the models which will check to see if there is a lock file in place for this physical printer, wait if there is; make a lock file if there isn't; print the job(s); then remove the lock. I have attached excerpts from one of my models. : computer_pr # Looks for print jobs on any printer on the same port as # computer_pr, and waits until there are no jobs before # continuing. # if [ -f /tmp/computer.lock ] then while [ -f /tmp/computer.lock ] do sleep 60 done fi touch /tmp/computer.lock # # Copyright (C) The Santa Cruz Operation, 1985, 1986. # This Module contains Proprietary Information of # The Santa Cruz Operation, Microsoft Corporation # and AT&T, and should be treated as Confidential. # #! computer_pr # Options: lp -ob no banner # . [rest of the standard model here] . . # send the file(s) to the standard out $copies times while [ "$copies" -gt 0 ] do for file do echo -n " 0 6 F66" # Oki 32x codes cat "$file" 2>&1 echo "\f\c" echo -n " 0 6 F66" # Oki 32x codes done copies=`expr $copies - 1` done rm /tmp/computer.lock stty -hupcl 0<&1 exit 0 The only drawback with this approach that I have encountered is when you cancel a print job the lock is not removed. You have to remember to "rm /tmp/computer.lock" after your cancel, otherwise you next jobs will never print. I remember trying to solve this once by trapping the rm lock sequence inside the model, but it didn't work. I would be interested in finding a better solution than this which doesn't force the user to remember to remove a dead lock file. Good luck. -- Bill Irwin - TWG The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems Bill.Irwin@twg.bc.ca (604) 431-4629 (fax) | Integration
dold@mitisft.Convergent.COM (Clarence Dold) (06/04/90)
in article <453@van-bc.UUCP>, sl@van-bc.UUCP (Stuart Lynne) says: > Does this mean that there is nothing to stop you from doing this so don't do > it? > Or that lpsched is designed to pay attention to having multiple destinations > some with the same physical device. There is no 'guard' within the lp subsystem. Two print jobs could provide output to the same port simultaneously. What you might do is have the differing models attached to device /dev/null, as if they were remote printer models. In the model, rather than a cat to stdout, invoke an lp job to a printer with an unused name. We do this locally, with the default printer called "laser", a special model for UNIX - WordPerfect called "WPlaser", and both of them feeding output to a model called "RealLaser", which no one adresses directly. This results in a little overhead in extra processes, but allows for any number of oddball printer models to be introduced transparently. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (06/05/90)
In article <1492@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes: >in article <453@van-bc.UUCP>, sl@van-bc.UUCP (Stuart Lynne) says: > >> Or that lpsched is designed to pay attention to having multiple destinations >> some with the same physical device. > >There is no 'guard' within the lp subsystem. Two print jobs could provide >output to the same port simultaneously. > >What you might do is have the differing models attached to device /dev/null, >as if they were remote printer models. In the model, rather than a >cat to stdout, invoke an lp job to a printer with an unused name. >We do this locally, with the default printer called "laser", a special model >for UNIX - WordPerfect called "WPlaser", and both of them feeding output to >a model called "RealLaser", which no one adresses directly. >This results in a little overhead in extra processes, but allows for any >number of oddball printer models to be introduced transparently. This method works fairly well but if the processing being done in the interface coverts the output to something large (e.g. a fax getting converted to a bitmap) then you end up having to store the intermediate data. This can be unacceptable on smaller systems. The other commonly suggested method is to implement a lock in the interface script, so that no more than one process can proceed and output to the physical device at one time. For example the following script lplock, could be called from each interface file: lplock `basename $0` $$ This script shows how this could be done, except that there is a race condition to create the lock file. A C program would be a much better solution. # # $1 The lp destination to be locked # $2 The process ID of the calling process # # This script will check for the presence of a lock file # # /usr/spool/lp/LCK.device # # Where device is derived from: # # cat /usr/spool/lp/member/destination # # If it exists the script will wait for the process number # from the file to exit and will then create a new file # with the supplied process ID. # printer=`basename $1` id=$2 device=`cat /usr/spool/lp/member/$printer` device=`basename $device` # while [ -f /usr/spool/lp/LCK.$device ] do lock=`cat /usr/spool/lp/LCK.$device` while kill -0 $lock > /dev/null 2>&1 do sleep 10 done rm /usr/spool/lp/LCK.$device fi echo $id > /usr/spool/lp/LCK.$device -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
friedl@mtndew.UUCP (Stephen J. Friedl) (06/05/90)
Stuart Lynne writes: > The other commonly suggested method is to implement a lock in the interface > script, so that no more than one process can proceed and output to the > physical device at one time. > > [ description of script deleted ] Better than using lock files is to use file locks on the tty (stdout). This way you get guaranteed mutual exclusion, and if the process holding the lock dies, cleanup is automatic. A C program can do this easily. Steve -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "I will defend to your death my right to my opinion" - me
tanner@cdis-1.compu.com (Dr. T. Andrews) (06/05/90)
In article <453@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
) What I wanted was for file1 to be printed, followed by file2.
) What I got was file1 intermingled with file2 being printed.
A reasonable parallel port driver would probably only allow one
"open" to succeed unless the printer had two print heads.
You could probably arrange to use the failed open() to defer
the second file.
--
uflorida!ki4pv!cdis-1!tanner {uunet dsinc}!cdin-1!cdis-1!tanneritkin@mrspoc.Transact.COM (Steven M. List) (06/06/90)
bill@twg.bc.ca (Bill Irwin) writes: >In article <453@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >>Which is what I need to do. I have two different packages that want to >>install specialized lp destinations with appropriate filters. Can I install >>both and have lp figure out how multiplex the requests for the two >>destinations to the one physical printer? ... >I have had this same problem. I have one printer that is used for four >lp destinations. When jobs are queued to two or more of the destinations >at the same time, you get garbage. The solution I came up with works >very well. It involves adding some lines to the models which will check >to see if there is a lock file in place for this physical printer, wait >if there is; make a lock file if there isn't; print the job(s); then >remove the lock. I have attached excerpts from one of my models. The first two (if/then) and last (fi) lines of this loop are unnecessary, since the "while" would fall out anyway if the file's not there. >if [ -f /tmp/computer.lock ] >then > while [ -f /tmp/computer.lock ] > do > sleep 60 > done >fi >touch /tmp/computer.lock >The only drawback with this approach that I have encountered is when you >cancel a print job the lock is not removed. You have to remember to "rm >/tmp/computer.lock" after your cancel, otherwise you next jobs will never >print. >I remember trying to solve this once by trapping the rm lock sequence >inside the model, but it didn't work. I would be interested in finding a >better solution than this which doesn't force the user to remember to >remove a dead lock file. If you write the PID or the job ID of the current job in the lock file, then instead of just checking for existence of the file, you check for the process or job. If whatever you're checking for doesn't exist, then you can remove the lock file. That way when you cancel, you don't need to worry about removing the file. -- +----------------------------------------------------------------------------+ : Steven List @ Transact Software, Inc. :^>~ : : Chairman, Unify User Group of Northern California : : {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM :
stu@gtisqr.uucp (Stu Donaldson) (06/07/90)
In article <162@twg.bc.ca> bill@.UUCP (Bill Irwin) writes: ># >if [ -f /tmp/computer.lock ] >then > while [ -f /tmp/computer.lock ] > do > sleep 60 > done >fi >touch /tmp/computer.lock ... model/interface stuff deleted ... >rm /tmp/computer.lock >The only drawback with this approach that I have encountered is when you >cancel a print job the lock is not removed. You have to remember to "rm >/tmp/computer.lock" after your cancel, otherwise you next jobs will never >print. A safer solution that I have used for locks, that solvs the problem of the lock file being left around is: while [ -f /tmp/computer.lock ] do if ps -p`cat /tmp/computer.lock` >/dev/null 2>&1 then sleep 60 else rm -f /tmp/computer.lock # lock invalid, so remove. fi fi echo $$ >/tmp/computer.lock # I should lock it. # for added security, the following test can be made. sleep 2 if [ "$$" != "`cat /tmp/computer.lock`" ] then ... lock failed, go back and try again? ... fi >-- >Bill Irwin - TWG The Westrheim Group - Vancouver, BC, Canada >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems >Bill.Irwin@twg.bc.ca (604) 431-4629 (fax) | Integration -- Stu Donaldson UUCP: {smart-host}!gtisqr!stu Engineering Manager ARPA: gtisqr!stu@yang.cpac.washington.edu Global Technology Bell: (206) 742-9111 Mukilteo, Washington.
rbp@investor.pgh.pa.us (Bob Peirce #305) (06/07/90)
In article <1990Jun2.034151.27340@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <453@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >>In the man page for lpadmin: >> >> -vdevice ..... Note that there is nothng to stop a system >> manager from associating the same device with more >> than one printer. >> >>Does this mean that there is nothing to stop you from doing this so don't do >>it? > >No. What it means is that you can do it, but you must set things up so >that they work correctly. This has been used lots of times to have a >printer with several kinds of paper that can be loaded and each type >of paper will get it's own queue while the device for all of the queues >is the same. > >In this scenario, the system administrator must enable 1 and only 1 of >the queues at the same time (hopefully just after he placed the appropriate >paper into the printer). > You also need (or at least probably should) decide which queue is primary and set up your control scripts for the other devices to disable themselves when their print job completes. On our system, we tried several ideas and settled on manually disabling the primary device before starting up a secondary device and having the secondary device disable itself unless given a flag to keep itself turned on. This works because we have to change paper and we want to disable the primary device before we do that. We are also set up so anyone can disable or enable a device. -- Bob Peirce, Pittsburgh, PA 412-471-5320 ...!uunet!pitt!investor!rbp rbp@investor.pgh.pa.us