SYSRUTH@UTORPHYS.BITNET (10/29/86)
I also asked for information about LATs (reliability, protocols, etc.). However I think there must be something flaky about the gateway because I only got about two answers and never saw the similar question from NASA Ames. Fortunately I did see her answer (sorry, I deleted the message and have forgotten your name). Anyway ... Regarding terminal names, it was recently noted that VTAxxx names can be too long for some programs. In fact there is the same problem with LAT terminal names (LTAxxx). Each time someone logs into the system on a LAT, the terminal number is incremented. After about 5 days of uptime on our system, the number gets up to 1000. After that, a lot of things stop working. For one thing, getjpi's returned answer loses a character (usually the colon, so it's not too serious) off the terminal name, so any program that uses this service starts having difficulties. One of these programs is "show users", where you start getting 2 terminal names for each interactive LAT user since the strings are different. I confess ... we're still running 4.3; this may have been fixed in 4.4. In addition, KERMIT for VMS has the terminal name length defined as 7. The result: anything over LTA999 bombs out due to losing a NUMBER off the end (-> non-existent terminal). This would be easy to fix in BLISS. Unfortunately, like Marty Sasaki, we also do not have a BLISS compiler. The code we run is BLISS-generated MACRO, meaning that all the offsets are hard-coded into the programs, which makes it (for all practical purposes, anyway) impossible to modify the name length. Fortunately, there is a tacky way to get around this: SET HOST 0 and your terminal name goes back to 5 or 6, including all the bits and pieces. KERMIT will then work again. In Version 3.7 of VMS (and possibly earlier versions), the LAT devices were LTA/B/C/D1-7. Whenever someone logged on, a free name was given to them. This did have problems. I once saw two processes with the same LTA (one of them was stuck in <loginout>). When I tried to do a stop/id on one of them, the system crashed. Obviously not desirable. But surely there must be a better way than the one being used now. 28 terminals is not much, but something like 256 or 512 should be plenty for anyone (has anybody ever seen 500 people logged onto a single VAX simultaneously, all on Ethernet lines?). I have a question arising from all of this: does anybody know of a way to reset the counter to 1 (other than rebooting the system)? That way, when people start getting up around 800, I could reset it. Thanks for listening. Ruth Milner VAX Systems Manager Physics/Astronomy VAX Group University of Toronto SYSRUTH@UTORPHYS (BITNET)
garry@TCGOULD.TN.CORNELL.EDU (Garry Wiegand) (10/31/86)
In a recent article Ruth Milner said: >Regarding terminal names, it was recently noted that VTAxxx names can be >too long for some programs. In fact there is the same problem with LAT >terminal names (LTAxxx). Each time someone logs into the system on a LAT, >the terminal number is incremented. After about 5 days of uptime on our >system, the number gets up to 1000. After that, a lot of things stop >working. For one thing, getjpi's returned answer loses a character >... This is buggy in the operating system, not just in a number of programs. Specifically, the process-control-block field "PCB$T_TERMINAL" is a counted-Ascii string of total size 8 (and net size 7). So "VTA999:" fits, "VTA1000:" does not. I've been eagerly awaiting the day when we fall over 1000 (we're at 883 right this minute -- go go go!) and everything breaks. I've especially been wondering whether the logical "TT" will come out wrong - I use it a lot. Seriously, the posted patch to CLONE_UCB should fix the entire problem. It should also make your next system upgrade fail with a "checksum error" :-) You should restore a virginal Sys.Exe before upgrading, and re-apply the patch afterwards (if Dec hasn't already.) garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)