HRYBYK@BITNIC.BITNET (02/06/90)
In trying to help a NAD last month, I inadvertently introduced an error. I am asking all of you to please edit your routing tables appropriately to fix the problem. I was approached over the phone by the NAD at CWU to change the mail addresses in his node entry from CWUVAXEN to CWU. I wrote down the facts, but somehow managed to interpret this as changing the node *NAME* to CWUVAXEN. I duly did so, and node CWU is now CWUVAXEN in BITEARN NODES. However, this is *NOT* the case. The name should not have been changed. Please change CWUVAXEN in your routing tables to CWU. This will mean editing the NETINIT file received from NETSERV *before* you install it. I will make sure that the correct change is placed in BITEARN NODES for 9003. Please note that this problem was not caused by SPIRES, UPDATE, or any particular automated NIC procedure. In fact, it was my attempt to skirt the procedures to help a member that actually contributed to the problem. Thank you for your assistance in this matter. Mike Hrybyk BITNIC
U001213@HNYKUN11.BITNET (Hans-Ulrich Giese) (02/06/90)
On Tue, 6 Feb 90 09:01:57 EST <HRYBYK@BITNIC> said: ... >Please note that this problem was not caused by SPIRES, UPDATE, or >any particular automated NIC procedure. In fact, it was my attempt to >skirt the procedures to help a member that actually contributed to >the problem. just my stuiver (that's 5 dutch cents) : mike contacted me about this, but i had distributed the updates already. -ulrich- p.s.: i'm still waiting for the arrival of my updates in the US,in order to update BITEARN NODES (etc.). unfortunately there seems to be a large backlog somewhere on the way to BITNIC.
GETTES@PUCC.BITNET (Michael R. Gettes) (02/07/90)
On Tue, 6 Feb 90 09:01:57 EST <HRYBYK@BITNIC.BITNET> said: >However, this is *NOT* the case. The name should not have been changed. >Please change CWUVAXEN in your routing tables to CWU. >This will mean editing the NETINIT file received from NETSERV *before* >you install it. I will make sure that the correct change is placed >in BITEARN NODES for 9003. Given that the VERSyymm has been changed to be VERSyynn such that updates no longer need to correspond to a month, maybe, if Ulrich is willing to deal with the annoyance, we should just put out 9003 one week from today with all corrections applied. This CWU problem is not the only error applied this month, not that the other errors are critical, just annoying. It would be nice to have a correct BITEARN NODES. Granted, it's off-cycle, but I think it should be considered. /mrg
POSTMAST@TECMTYVM.BITNET (Juan M. Courcoul) (02/07/90)
Uh, oh, time to get the table update jitters once again... ;-) JMC
RAF@NIHCU.BITNET (Roger Fajman) (02/07/90)
In my opinion, a problem such as the CWU one justifies putting out an extra update. I don't think that asking people to edit their routing tables is very effective.
POSTMAST@TECMTYVM.BITNET (Juan M. Courcoul) (02/07/90)
Mulling over the problem regarding CWUVAXEN and asking ALL the nodes to hand-edit their routing tables, I'd like to propose the following: Given that: a) BITNIC's NETSERV still hasn't received the VERS9002 update. b) A routing table generation request cancels any previous one that hasn't been carried out. And assuming that: c) The distribution path of the VERS9002 update in BITNET/CREN starts at BITNIC and works on down the rest of the NETSERVs. d) The node management procedures regarding the routing tables generated and distributed via NETSERV in EARN have been long since ironed out and there is a better control there, given that there are fewer nodes. It would seem logical to send the corrected VERS9003 update ASAP so that both this and VERS9002 would arrive to the servers within a few hours of each other and be applied before midnight of the same day, when the table generation process is triggered. If my line of reasoning is correct, there should only occur one table generation, with the last (VERS9003) version of BITEARN NODES in place. Granted that it may be difficult to ensure that this sequencing occurs, given the state of the link queues, perhaps all of us NETSERV controllers can help by putting our servers offline until both updates arrive, sort them in the requisite order AND THEN reactivate the servers. (This may mean LOGGING OFF a NETSERV for a day or two). It seems much more feasible to control the operation of the 15 to 20 NETSERV servers in BITNET/EARN over a period of a couple of days, than have the more than 3,100 nodes carry out the hand-modification of their tables. Hopefully, this suggestion will arrive BEFORE the update... ;-) Juan M. Courcoul Mexico NETSERV Controller
SYSBJAV@VM.TCS.TULANE.EDU (John Voigt - Academic Systems Programmer) (02/08/90)
On Tue, 6 Feb 90 19:26:50 EDT Juan M. Courcoul said: >Mulling over the problem regarding CWUVAXEN and asking ALL the nodes to >hand-edit their routing tables, I'd like to propose the following: > >..... I think it is unreasonable to expect anyone to hand edit routing tables. When someone in the table delivery process screws up, a fix should be sent out, not a request to hand edit tables. Wasn't this the point of changing the linkyymm designation to linkyynn? I'd be really suprised if you got 30 percent compliance with a request to hand edit. John/
HARRY@MARIST.BITNET (A. Harry Williams) (02/08/90)
On Wed, 7 Feb 90 10:44:33 CST John Voigt - Academic Systems Programmer said: >changing the linkyymm designation to linkyynn? I'd be really suprised >if you got 30 percent compliance with a request to hand edit. I generally don't. Its too easy for me to mess it up also. Not to pick on Mike(I'm glad he told us, and why), but witness why the problem exists. > >John/ /ahw