<<< SPCVXA::DUA2:[NOTES$LIBRARY]X-INFO-FINGER.NOTE;1 >>> -< X-Info-Finger >- ================================================================================ Note 7.0 Info-Finger Postings for November, 1989 7 replies SPCVXA::BBOARD "Notes Poster Daemon" 0 lines 1-NOV-1989 22:48 -------------------------------------------------------------------------------- ================================================================================ Note 7.1 Info-Finger Postings for November, 1989 1 of 7 SPCVXA::INFOFINGER "Terry Kennedy - -------------------------------------------------------------------------------- I'll be away at the DECUS US Symposium from 4-Nov through 10-Nov. I'm telling you this for two reasons: 1) If something odd happens to the mailer here, the staff has instruc- tions to shut the list down until I get back, to prevent mail loops. Also, subscribe/unsubscribe/address changes will not be processed while I'm away. 2) If any of you are going to the Symposium and want to get together ei- ther formally (BOF) or informally (water-cooler) to discuss Finger, I'd be glad to. Either look for me in any RSTS/E session (session code RS) or post a note on the message board (under K for Kennedy, please). Terry Kennedy List owner / Finger maintainer / etc. ================================================================================ Note 7.2 Info-Finger Postings for November, 1989 2 of 7 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 56 lines 14-NOV-1989 03:00 -< Bug fix for RSTS/E (PDP-11) Finger >- -------------------------------------------------------------------------------- A bug has been found in the RSTS/E (PDP-11) version of Finger. This bug is *not* present in the VAX version. If you are using the RSTS/E version, here are the details and a fix: If the first new mail message was evenly divisible by 20, but *not* 20, the program would display the error message "?End of file on device at line 3070." after displaying the "Mail: N new messages." message. The fix is really quite simple (1 line, actually), but I've incremented the edit number by one so you can tell if you have the fixed version or not. Here is the .DIF file: FILCOM V9.5-06 RSTS V9.7-08 SPC11B.SPC.EDU File Comparison Program 14-Nov-89 02:25 AM Comparing: 1) [0,216]FINGER.B2S to 2) [0,216]FINGER.BAK ****************************** 1) [0,216]FINGER.B2S 6! EDIT : 09 7! EDIT DATE : 14-Nov-89 10 EXTEND ********** 2) [0,216]FINGER.BAK 6! EDIT : 08 7! EDIT DATE : 14-Sep-89 10 EXTEND ****************************** 1) [0,216]FINGER.B2S ! V1.1-09 14-Nov-89 Fix problem with ?EOF on device at & ! line 3070 due to boundary problem at & ! line 3060. & ********** 2) [0,216]FINGER.BAK & ****************************** 1) [0,216]FINGER.B2S \ k%=(j%-1%)/20% ! V1.0-09 - 14-Nov-89 - tmk & \ m%=(((j%-(k%*20%))-1%)*24%)+33% & \ field #9%, 512% as buff9$ & ********** 2) [0,216]FINGER.BAK \ k%=j%/20% & \ m%=(((j%-(k%*20%))-1%)*24%)+33% & \ field #9%, 512% as buff9$ & ****************************** 1) [0,216]FINGER.B2S version$="RSTS/E Finger: Version V1.1-09 of 14-Nov-1989" & \ bypass$="........."+chr$(9%)+chr$(10%)+".."+chr$(13%)+ & ********** 2) [0,216]FINGER.BAK version$="RSTS/E Finger: Version V1.1-08 of 14-Sep-1989" & \ bypass$="........."+chr$(9%)+chr$(10%)+".."+chr$(13%)+ & ?4 Differences Found. ================================================================================ Note 7.3 Info-Finger Postings for November, 1989 3 of 7 SPCVXA::INFOFINGER "Pete Kanaitis - -------------------------------------------------------------------------------- Our site will be joining the Internet in a few months, and we will be using SRI Multinet as our TCP/IP package. Does anyone know if the TCPFINGER.FOR module will work with Multinet? Will it require some modifications to get it to work? Thanks in advance, Pete Kanaitis Manager, Computational Resources Allegheny-Singer Research Institute X979PK0P@CMCCVB.Bitnet or X979PK0P@VB.CC.CMU.EDU ================================================================================ Note 7.4 Info-Finger Postings for November, 1989 4 of 7 SPCVXA::INFOFINGER "Carl Karcher, Room 535 WC, 3-58" 31 lines 14-NOV-1989 17:18 -< Finger suggestions >- -------------------------------------------------------------------------------- Here are a few things on my wish list for the FINGER utility: 1. Display of additional UAF information such as UIC (in identifier form) and Account. These two would be useful if they were shown in the detailed "FINGER USERNAME" display. Adding qualifiers for /UIC and /ACCOUNT would be helpful as fields to select in the process display as well. As I recall, an earlier version of finger did display the numeric UIC. 2. Make the FINGERSHR installed section an option and use the OWNER field from the UAF if it's not selected. Some sites have little use for anything other than the information provided by the owner field of the UAF (typically First and Last name). There is minor operational problem with the use of the shared section in Vaxclusters. After the FINGERSHR image is rebuilt on one node, other nodes using "FINGER username" may see the information returned for a user that they didn't ask for. The information is again in sync after the image is replaced on all nodes in the cluster. 3. It might be a good thing if the login device of a user were checked to make sure it's not in mount verification (or not available) before trying to open a file on it. We've had cases where a LAVC satellite is down, it's disk in mount verification, then someone fingers a user who has a login directory on that disk. At that point the user's process will hang until the disk comes back. This sequence of events may even cause the UAF to be locked (and preventing any logins or use of MAIL). I can't say for sure that finger had the UAF locked but logins were definitely prevented while finger hung waiting for the disk. I may actually get around to adding the check for the login disk. Carl Karcher Internet: KARCHER@WAISMAN.WISC.EDU Systems Manager Bitnet: KARCHER@WISCPSL UW - Waisman Center Hepnet: KARCHER::PSLC Madison, Wisconsin PSTNet: (608) 263-5896 ================================================================================ Note 7.5 Info-Finger Postings for November, 1989 5 of 7 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 17 lines 17-NOV-1989 01:19 -< RE: Finger and Multinet >- -------------------------------------------------------------------------------- Pete Kanaitis writes: > Our site will be joining the Internet in a few months, and we will be using > SRI Multinet as our TCP/IP package. Does anyone know if the TCPFINGER.FOR > module will work with Multinet? Will it require some modifications to get > it to work? I don't know for sure, but I think the TWG TCP implementation (which is what TCPFINGER.FOR uses) has a similar, if not identical, programming interface to Multinet TCP. We are also in the process of acquiring Multinet, so some future release of Finger will support Multinet. By the way, Multinet comes with a version of Finger as well, although I don't know what it's capabilities are. If you hap- pen to get to it first, I'd welcome the changes to TCPFINGER.FOR, though. Terry ================================================================================ Note 7.6 Info-Finger Postings for November, 1989 6 of 7 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 56 lines 17-NOV-1989 01:49 -< RE: Finger suggestions >- -------------------------------------------------------------------------------- Cark Karcher writes: > 1. Display of additional UAF information such as UIC (in identifier form) and > Account. These two would be useful if they were shown in the detailed "FINGER > USERNAME" display. Adding qualifiers for /UIC and /ACCOUNT would be helpful as > fields to select in the process display as well. As I recall, an earlier vers- > ion of finger did display the numeric UIC. Finger-11 (RSTS/E) displays the UIC, but that's because RSTS doesn't have any concept of account naming. It wouldn't be that hard to add. What do the rest of you think? > 2. Make the FINGERSHR installed section an option and use the OWNER field from > the UAF if it's not selected. Some sites have little use for anything other > than the information provided by the owner field of the UAF (typically First > and Last name). There is minor operational problem with the use of the shared > section in Vaxclusters. After the FINGERSHR image is rebuilt on one node, othe r > nodes using "FINGER username" may see the information returned for a user that > they didn't ask for. The information is again in sync after the image is > replaced on all nodes in the cluster. First, I'm not sure what you meant by the last 2 sentences above. If you supply a unique existant username (such as SYSTEM), you should always get the information for SYSTEM. If you don't, that's a very serious bug, and I'd like to hear more about it. On the other hand, if you FINGER JOE* and get a list of unrelated matches, that can be caused by the situation you mention. The problem with doing away with the FINGERSHR image is that many sites use it for the other miscellany (organization, "official" net names, adjacent nodes, etc.). How often do you rebuild the FINGERSHR image? Would a SYSMAN- like method to force a replace on all cluster members be acceptable? > 3. It might be a good thing if the login device of a user were checked to make > sure it's not in mount verification (or not available) before trying to open a > file on it. We've had cases where a LAVC satellite is down, it's disk in mount > verification, then someone fingers a user who has a login directory on that > disk. At that point the user's process will hang until the disk comes back. Is there an easy way to determine this from VAX Fortran? If someone has some code to do it, I'll be glad to include it, but I currently don't have a cluster here to do original development on. (This will be changing Jan 1st or so). The code should be version-independent (V5 is Ok as a requirement, though), and should use documented interfaces if at all possible. (The things that keep coming back to haunt me are all the "tricks" from earlier releases.) > This sequence of events may even cause the UAF to be locked (and preventing > any > logins or use of MAIL). I can't say for sure that finger had the UAF locked > but logins were definitely prevented while finger hung waiting for the disk. Finger shoudn't open any of its files in exclusive mode. I've put this on the list for investigation. If it is doing this, it is an error (from *way* back), and will be fixed in the next release. Terry ================================================================================ Note 7.7 Info-Finger Postings for November, 1989 7 of 7 SPCVXA::INFOFINGER "Carl Karcher, Room 535 WC, 3-58" 29 lines 17-NOV-1989 16:41 -< FINGERSHR rebuild effects and login device check >- -------------------------------------------------------------------------------- The effect of rebuilding FINGERSHR on one node but not reinstalling it on other nodes in a cluster seems to be fairly consistent. The sequence of events is this: 1. Add several new users to the cluster. 2. I Realize their names don't appear in the finger display, then rebuild the FINGERSHR DB and reinstall it on one node of the cluster. 3. User JONES does "FINGER JONES" from a node other than the one that rebuilt it. and sees the entry for username JENSEN instead and gets worried. 4. After FINGERSHR is installed on all nodes, "FINGER JONES" returns the correct entry. It seems only usernames that come alphabetically after the new users added will return incorrect entries in step 3 above. It's as if some pointer to an entry in FINGERSHR is pointing to the wrong one after the section file is updated (but not installed). The next time I add more uses I'll try to get more information. It's certainly no big deal since SYSMAN makes for an easy rebuild procedure. On checking to see if the login disk is available (and prevent finger from hanging due to mount verification if it isn't), I believe using SYS$GETDVI or (LIB$GETDVI) with the item code DVI$_HOST_AVAIL should do it. Carl Karcher Internet: KARCHER@WAISMAN.WISC.EDU Systems Manager Bitnet: KARCHER@WISCPSL UW - Waisman Center Madison, Wisconsin