home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / apollo / 3496 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!cel.cummins.com!philip
  2. From: philip@cel.cummins.com (Philip D. Pokorny)
  3. Newsgroups: comp.sys.apollo
  4. Subject: Re: rz/sz doesn't work on our machiens
  5. Message-ID: <9209082141.AA02720@cel.cummins.com>
  6. Date: 8 Sep 92 21:41:28 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 47
  11.  
  12. Chuck Tomasi asks:
  13. > 
  14. > We're running mostly DN3550/DN4500/DN5500 machines on our site (with a
  15. > few 425Ts) under Domain/OS 10.3.5.  We compiled the rz/sz sources with
  16. > SYSTYPE=sys5.3 and everything appeared to go alright.  The problem is
  17. You're doing better than me...  I didn't try very hard but
  18. didn't get very far either...
  19.  
  20. > that they don't work.  The same sources work fine from an HP-UX v8.0
  21. > machine however it seems that something is being blocked or trapped when
  22. > we invoke them from the Domain machines.
  23. > 
  24. > Let me explain.  We are working on a Mac from home with software which
  25. > supports auto-zmodem downloading.  From the HP-UX machine the zmodem
  26. > init string initiates the zmodem transfer and everything goes as
  27. > expected, however with the same command is issued from the Domain
  28. > machine you see the same portion of the init string, but you also see
  29. > things like the file name, CRC, and a few other things.  This is not
  30. > normally seen!
  31. You don't say whether the transfer commences or not...  Are the
  32. files transfered correctly?
  33.  
  34. I don't normally like to say negative things about companies,
  35. but...  We bought a product called YAM (a communications program)
  36. from a company called Omen Technologies.  This is the same
  37. company that developed and wrote the ZMODEM protocols.  (Check
  38. the headers)  In porting the YAM software to the Apollo, I was
  39. witness to some of the worst coding practices ever performed in
  40. C.  (This from a company that bills itself as the "High
  41. Reliability Software Company")  In any case, the protocols
  42. didn't work.  There is a routine called readline that reads a
  43. line of input and returns after reading a line or a timeout is
  44. exceeded.  This turned out to be the culprit.  Something about
  45. signal()'s not acting correctly and needing both BLOCK and
  46. NOBLOCK access to an sio.  I "fixed" it by writing a BUSY loop
  47. that checks time_$clock and does NON-BLOCKING reads.  It's a
  48. horrible waste of CPU cycles but if works on the 425t's of the
  49. only users of the software.  You might check the readline
  50. function (or equivalent read with timeout function) to see if
  51. that is your problem.  If you come up with a better fix than the
  52. BUSY loop I'm using, I'd appreciate hearing from you so I can
  53. "fix it right".
  54. Sincerely,
  55. Philip D. Pokorny
  56. philip@cel.cummins.com
  57. :)
  58.  
  59.