VENARD@EDUCOM.BITNET (01/03/86)
We are a VAX site running version 4.1 of VMS. We have jnet version 1.2 RSCS emulation software to enable our link to BITNET. From time to time, users sending network messages from within the VMS Mail Utility are confronted with the following message: %MAIL-E-LOGLINK, error creating network link to node 0 -System-F-Linkexit, network partner exited After re-trying the same message 2 or 3 times the error goes away and the message is successfully sent, but this is annoying. The System Messages and Recovery Procedures Manual says this message means the log file on the remote node was not open or was write locked. Does this make sense? Does jnet really send a signal to the target node to check if the "log file" is available, before it lets the user send a message to that node? Has anyone else seen this message? Regards, Robert Venard
linscomb@NGP.UTEXAS.EDU (Thomas J. Linscomb) (01/04/86)
> > We are a VAX site running version 4.1 of VMS. We have jnet version 1.2 > RSCS emulation software to enable our link to BITNET. From time to time, > users sending network messages from within the VMS Mail Utility are confronted > with the following message: > %MAIL-E-LOGLINK, error creating network link to node 0 > -System-F-Linkexit, network partner exited > After re-trying the same message 2 or 3 times the error goes away and the > message is successfully sent, but this is annoying. > The System Messages and Recovery Procedures Manual says this message means > the log file on the remote node was not open or was write locked. Does this > make sense? Does jnet really send a signal to the target node to check if > the "log file" is available, before it lets the user send a message to that > node? Has anyone else seen this message? > > Regards, > Robert Venard > Hi Robert, Under VMS v3.x, v4.0 and v4.1 we (and other users on info-vax) also had a similiar problem with DECnet. In our case it was not with JNET but your problem sounds real familiar. Below is the explanation I received from Digital. I have rerun our failing command files and it went from a 1 in 30 failure rate to no failures in over 6000 executions under VMS v4.2. Thank you Digital. As to your specific JNET questions I can only say that JNET does in some cases open DECnet links to your own system (node 0) to startup some things. I remember sending mail to a BITNET address as one of these cases. This is how you are getting DECnet error messages while sending mail messages. Since I am not familiar with JNET I can't say much more then that. --Thomas -------------------- Answer for QAR #00460: A problem was found which caused a node receiving a [DECnet] connect request to occasionally (and incorrectly) ignore it as a duplicate. This would occur if the link ID was the same as an existing link from a different node with a higher address. The result was most visible with applications which opened large numbers of links one after the other, since whenever they got around to the same link ID, they would time out. The problem is exacerbated by a second bug which caused the sequence number field of the link ID to not be incremented. Fixed in V4.2. -------------------- PS: Please say hello to Candy and Scott for me. --Thomas Linscomb aka linscomb@ngp.UTEXAS.EDU aka cctlinscomb@agl.UTEXAS.EDU --Advanced Graphics Lab/Computation Center/The University of Texas --Austin, TX 78712 phone: 512/471-3241 --uucp: ...seismo!ut-sally!ut-ngp!linscomb linscomb@ut-ngp.UUCP --bitnet: cctj001@utadnx
SYSTEM@CRNLNS.BITNET (01/04/86)
Subject: re: "Network partner exited" message Robert: The error message is complaining about VMSmail not being able to send the message to JMAIL: node 0 is your local DECnet node. The earlier versions of jnet use DECnet to communicate between the two mailers. You need to get more detailed information about the problem: 1. Inspect your accounting log entries for the time in question. If you have PROXY logins enabled, you should see a network access by the user with the problem. If you do not have proxy logins enabled, you will see an attempted access to your default nonprivileged DECnet account. If you have a lot of people doing network operations, this may be your problem: all network accesses will be going there and interfering with one another. 2. Inspect the log file for the network operation. If PROXY logins are enabled, then look at NETSERVER.LOG in the user's directory. Otherwise, look at NETSERVER.LOG in your default DECnet account. Note that only the most recent 3 to 10 are kept if you haven't modified SYS$SYSTEM:NETSERVER.COM to keep more. In general, it is a good idea to use Proxy access. There is more work for the system manager in that you have to run AUTHORIZE and "ADD/PROXY localnode::username username" for each existing account on your local system as well as for new accounts and remote accounts if your node is frequently accessed by other networked systems. Of course you also have to remember to remove them when a person leaves. The benefits outweigh the disadvantages, however, both in security and accounting. Selden Ball Cornell University, LNS NYNEX: (607) 256-4882 Wilson Synchrotron Lab BITNET: SYSTEM@CRNLNS Judd Falls & Dryden Road ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Ithaca, NY 14853 (SYSTEM%CRNLNS.BITNET@WISCVM.ARPA) PHYSnet/HEPnet: LNS61::SYSTEM (node 43.251/44283)
info-vax@ucbvax.UUCP (01/04/86)
I have a question concerning your bitnet implementation. Where does one get this jnet software, what is it written in and what interface does it use (a dmf32 sync port?) marty
rick@NGP.UTEXAS.EDU (Rick Watson) (01/04/86)
Re: ADD/PROXY localnode::username username you can also ADD/PROXY localnode::* * Rick Watson University of Texas Computation Center arpa: rick@ngp.UTEXAS.EDU rick@ngp.ARPA uucp: ...seismo!ut-sally!ut-ngp!rick rick@ut-ngp.UUCP bitnet: ccaw001@utadnx phone: 512/471-3241