home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / internal / 1115 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  2.0 KB
  1. Path: sparky!uunet!olivea!decwrl!decwrl!simpact!mvb.saic.com!macro32
  2. From: JWILKINSON@HMCVAX.CLAREMONT.EDU (James Wilkinson)
  3. Newsgroups: vmsnet.internals
  4. Subject: I/O to terminal server ports.
  5. Message-ID: <01GMQJW2Y1OWAOKE4L@HMCVAX.CLAREMONT.EDU>
  6. Date: 24 Jul 92 08:22:00 GMT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. Lines: 30
  9. X-Gateway-Source-Info: Mailing List
  10.  
  11. I have encountered several programs lately which rely on certain terminal port
  12. behavior which is not emulated by terminal server ports.  When doing single
  13. QIOs to a server port, for instance, the request will not complete as long as a
  14. printer is not hooked up to the port (DS90L+).  With a normal terminal device,
  15. the request completes right away and the I/O packet goes to the bit bucket.
  16. Additionally, with a normal terminal device one has access to curent flow
  17. control information available in the device UCB, whereas such information is
  18. unavailable from LTDRIVER.
  19.  
  20. I have in front of me a program which was designed around the ability to
  21. determine whether a QIO would complete in a timely fashion before the QIO was
  22. actually issued.  For instance, if the printer were offline or out of paper,
  23. the device would be in an XOFFd state and no QIO issued.  If the printer were
  24. not connected, the QIO would still complete.  Naturally, this code is a shoe-in
  25. for RWAST when the printer is an LT device.
  26.  
  27. Does anyone have any idea how to obtain similar functionality for the LT
  28. device?  I'm looking for some way to query the terminal server about the port's
  29. readiness, such that if I go ahead and issue the QIO I know that it will
  30. complete soon thereafter.  The program shouldn't have been coded in such a
  31. fashion in the first place, however changing over to a multi-threaded
  32. asynchronous mechanism will require a change in the entire design.  The program
  33. drives multiple printers.
  34.  
  35. JaW
  36. jwilkinson@hmcvax.claremont.edu
  37.  
  38. ps. I suspect that LTDRIVER must keep flow control information somewhere,
  39. otherwise servers wouldn't work.  However, the scenario with the printer
  40. disconnected is the real problem.
  41.