home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / hp / 14111 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!ut-emx!tivoli!TIVOLI.COM!stuart
  2. From: stuart@TIVOLI.COM (Stuart Jarriel)
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: Problem with hp laser II
  5. Message-ID: <6954@tivoli.UUCP>
  6. Date: 16 Dec 92 00:51:37 GMT
  7. References: <9233810.2944@mulga.cs.mu.OZ.AU> <6854@tivoli.UUCP> <17491@umd5.umd.edu>
  8. Sender: news@tivoli.UUCP
  9. Organization: Tivoli Systems, Inc
  10. Lines: 31
  11.  
  12. In article <17491@umd5.umd.edu>, mark@roissy.umd.edu (Mark Sienkiewicz) writes:
  13.  
  14. |> 
  15. |> I've seen this is lots of SYSV based machines-- they all seem to have
  16. |> this problem, but this solution looks like a quick hack that covers over
  17. |> some other problem.  
  18. |> 
  19. |> It looks to me like the real problem is that the XXclose routine for the
  20. |> terminal is changing the baud rate BEFORE the output is drained.  If the
  21. |> close() system call would block until the output queue drained, and THEN
  22. |> set the baud rate back to the default, everything would work correctly,
  23. |> right?
  24. |> 
  25.  
  26.  
  27. Well, that would be true if a single process was sending data to the printer.
  28. But SYSV print spooling is a conglomeration of shell scripts, with a cat
  29. somewhere in the middle.  If a program were responsible to get the file,
  30. set up the printer and send the data, the close() would work.  But if
  31. you have a script that:
  32.  
  33. echo "some control char's to setup the printer"
  34. cat file
  35. echo "some more control char's"
  36.  
  37. It's hard not to get the 300baud spikes.
  38.  
  39. The cat in the middle does wait for a drain on close, but the shell scripts
  40. arent really written to maintain constant baud.  I suppose they could be...
  41.  
  42. stuart
  43.