home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / internal / 1299 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.3 KB
  1. Path: sparky!uunet!wupost!cs.utexas.edu!swrinde!sdd.hp.com!network.ucsd.edu!mvb.saic.com!macro32
  2. From: raxco!galaxy.dnet!gleeve@uunet.UU.NET
  3. Newsgroups: vmsnet.internals
  4. Subject: Moving DDTs etc.
  5. Message-ID: <9209091400.AA19886@relay1.UU.NET>
  6. Date: 9 Sep 92 13:22:19 GMT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. Lines: 32
  9. X-Gateway-Source-Info: Mailing List
  10.  
  11. I'm inclined to agree with Jon Pinkley's extensions to my suggestions
  12. about moving DDTs into intercept UCBs. (And yes, I meant DDTs, not
  13. DDBs...too many of these darn three letter acronyms occasionally
  14. fry my brain when posting...)
  15.    While such suggestions cannot be enforced, having a number of folks
  16. publically promise to follow them (and I will in some code I'm developing
  17. for starters) will help to create support for the standard. In the
  18. case where nothing else is using the method, no problems will ensue.
  19. If we have a case where two programs try to steal the same resources,
  20. we have currently no way to interoperate and have only the options of
  21. refusing to work at all, or of crashing a system. Proposing and living
  22. with a standard gives all developers a third and better alternative.
  23. The fact that some will not get the word, ever or at least not for a
  24. while, is not a reason not to begin. I will store the messages for
  25. the sig tapes and hope some of us can get some intercept code out
  26. there also.
  27.    As for Alpha drivers, I have too little information, but suspect
  28. something like this is desirable. In a new design I'd ask for some
  29. customer queue headers in UCBs, in the exec, and in IRPs that would
  30. be usable for add-ons and which would have some sort of identifier
  31. scheme written into a standard so they could be used by multiple,
  32. relatively uncoordinated designers. (By "relatively uncoordinated"
  33. I mean that identifiers might collide but the probability of this is
  34. low.) The user SYSGEN parameters in the current VMS are an interesting
  35. start but are too risky to use for purposes other than for one
  36. specific site...too likely they'll be clobbered by someone else's
  37. code/data. Someplace to hold kernel tables that's faster to find than
  38. a lock value block or logical would however be a win.
  39.    For altering driver flow, I'd say that the present suggestions
  40. look very good and we should spread them around.
  41. Glenn
  42. Everhart@Raxco.com
  43.