cetron%utah-cbd@UTAH-CS.ARPA (Ed Cetron) (06/17/86)
Thanks for all of the quick responses to my previous posting about problems with 4.4 decnet....Rick Watson from the U of Texas mentioned that he had heard of an upcoming ECO for the DEQNA's. After much prodding, my local field service determined that the ECO is number EQ01418 Collision Avoidance and affects all DEQNA's on other than lightly loaded ethernets. It is due to be officially released in roughly 2 weeks. ( I ordered mine already and hopefully will have the replacements in about 3 weeks...) Apparently uVMS 4.3 treats these problems as 'receive failure, frame too long' and continues on its merry way. Unfortunately, uVMS 4.4 treats these as 'line synchronization losses' and logs that the circuit is down.... I found that even so, except for remote logins, the circuit will work right through most transfers. The temporary workaround is: $ mc ncp (i use mc [short for mcr] instead of run sys$system:) NCP>clear logging monitor event 4.7 (stop logging down to OPCOM) NCP>clear logging monitor event 4.10 (stop logging up to OPCOM) NCP>set logging console event 4.7,10 (start logging both to a file) [NOTE: no space before/after the comma....] NCP>set logging console name sys$manager:dwns.ups (pick your log file name...) NCP>set logging console state on (and turn on console logging) NCP>exit this will give you a file record of all of the down/up transitions without wasting paper on the console. If you don't care at all about logging the transitions, use only the first two lines..... I have also submitted and SPR about this problems since uVMS SHOULD be somewhat more tolerant of these kinds of problems....My 11/73 MINC (with a DEQNA) has no problems tolerating the load under RSX-11M+ V3.0..... -ed cetron Center for Engineering Design Univ. of Utah cetron%utah-cbd@utah-cs.arpa