From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 1-JUN-1989 17:30 To: MRGATE::"ARISIA::EVERHART" Subj: Updating from VMS 4.7 to VMS 5.1-1 Message-Id: <8906012117.AA25655@crdgw1.ge.com> Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 1 JUN 89 06:31:07 PDT Received: from CORNELLC.cit.cornell.edu by KL.SRI.COM with TCP; Thu, 1 Jun 89 06:03:01 PDT Received: from canisius.bitnet by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8513; Thu, 01 Jun 89 09:00:55 EDT Date: Thu, 1 Jun 89 08:55 EDT From: "Larry Deni @ Computer Center" Subject: Updating from VMS 4.7 to VMS 5.1-1 To: info-vax@kl.sri.COM X-Vms-To: IN%"info-vax@kl.sri.com" We upgraded from VMS 4.7 to VMS 5.1-1 last weekend and encountered some problems which may be local to our configuration, but may be common to other sites. Under VMS/DECNET 5.1, it seems that BYTLM for the NETACP process is exhausted at a somewhat alarming rate in accordance with the number of lines and circuits you have defined in the decnet database. At some number of lines bytlm becomes exhausted. We were configuring 7 lines in this way and exhausting the resource. DEC starts NETACP in sys$manager:startnet.com with bytlm at 65535. The first symptom I noticed of the problem was a slowness in starting DECNET from boot time. Then slowness while trying to work with NCP prompted me to look further. The NETACP process was moving in and out of a MUTEX state which led me to look for what resource was being exhausted, which led to bytlm. We had retained in our DECNET configuration database some line and circuit setups from our pre-Ethernet days when many of us in the Computer Center were using DDCMP to communicate via DECNET-DOS asynchronous lines. Under VMS/DECNET 4.7 it did not hurt us in any way (at least the bytlm usage was under control). Getting rid of the lines which were no longer being used meant that NETACP's bytlm usage was again reasonable. Colorado telephone support was instrumental in helping us narrow this bytlm problem down, and in fact someone there had already heard of the problem. Regarding LAT terminal servers, I don't know whether they ever would have loaded with the NETACP process being so bogged down. At the very least, they were taking a very long time to downline load. Once we reduced the number of DECNET lines and circuits, NETACP looked normal and the terminal servers loaded as usual. Once the terminal servers loaded, we saw a problem we had already seen on our terminal in the machine room which is hardwired to the vax. By default, we set up our terminals with the /MODEM characteristic. We must do this to achieve modem control for an IDX 3000 data switch. Under VMS 4.7, it didn't matter that this characteristic was also set for the hardwired terminal, the default "hardwire" connections through the IDX 3000, the LAT terminal servers and LAT terminals created for DECNET-DOS use. The symptom to note is an error message when attempting to get the VAX's attention (which also means the VAX won't give a Username prompt in order to log in): VAX/VMS host system modem is not wired properly. Contact your system manager. For the TXnn lines, you can simply set the modem qualifier when terminals are configured at boot time. LAT terminals use the LTA0 template to propagate virtual terminal characteristics. These are the default terminal characteristics as specified in SYSGEN parameters TTY_DEFCHAR and TTY_DEFCHAR2. Calculating a new value for TTY_DEFCHAR such that the MODEM bit was clear alleviated the problem for the terminal servers. One other thing to watch for regarding these SYSGEN parameters (as well as others). The upgrade to VMS 5 will create a new MODPARAMS.DAT file. It will propagate present values for some selected parameters into this new MODPARAMS file. TTY_DEFCHAR and TTY_DEFCHAR2 are both saved in the new MODPARAMS, so if you were to use SYSGEN to change the values you should also change them in MODPARAMS for the next time you AUTOGEN. Larry Deni Technical Computing Administrator Canisius College Buffalo, NY BITNET: deni@canisius