<<< SPCVXA::DUA2:[NOTES$LIBRARY]X-INFO-FINGER.NOTE;1 >>> -< X-Info-Finger >- ================================================================================ Note 5.0 Info-Finger Postings for September, 1989 16 replies SPCVXA::BBOARD "Notes Poster Moderator" 0 lines 15-SEP-1989 01:50 -------------------------------------------------------------------------------- ================================================================================ Note 5.1 Info-Finger Postings for September, 1989 1 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 24 lines 15-SEP-1989 01:54 -< RSTS/E Finger (Finger-11) V1.1-08 now available >- -------------------------------------------------------------------------------- I've just released version 1.1-08 of RSTS/E Finger (Finger-11). This ver- sion fixes a number of bugs which turned up after the original (V1.0-04) release, as well as a few minor enhancements. The corrections are as fol- lows: o Report mail forwarding and aliases (from MAIL.SYS). o Correct problem of read-only files being opened in exclusive mode, preventing simultaneous copies from working. o Display LAT dialups a little differently. o Fix problems with terminal types of 43 and up not being reported cor- rectly (they were off by one). o Fix problem where logged-in users might not be reported if they log- ged in near midnight. o Build with EIS version of compiler so sites without floating-point units can used the pre-built version. o Cluster RMSRES with CSPLIB to reduce task size, both on disk and in memory. o Report logged-out jobs as username "" rather than NONAME. This version is available from the fileserver VMSSERV@SPCVXA as file FIN- GER11.PACKAGE, as well as from the RSTS SIG BBS, directory [49,3]. Terry Kennedy terry@spcvxa.bitnet ================================================================================ Note 5.2 Info-Finger Postings for September, 1989 2 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 40 lines 15-SEP-1989 01:54 -< VMS Finger - what new feature(s) would *you* like? >- -------------------------------------------------------------------------------- I am planning to do a major overhaul of VMS Finger in the next month or so. As I currently envision it, it will take advantage of the new cluster- wide GETJPI support in VMS V5.2 (and thus will require V5.2). The list of new feature I'm considering are: o Add new /CLUSTER qualifier. When used locally this will cause information to be returned about all cluster members. When used remotely (over Jnet) it will simply issue a cluster-wide command using the Jnet '%' convention to reach all nodes with a single request. o Add /TIMEOUT=(initial, increment) to specify a non-default set of time- out values for requests over Jnet links. o Support callable TSM (in TSM V1.3) for fingering terminal servers. o Add mail support to the Jnet finger daemon. This will allow users at re- mote non-Bitnet sites to send mail to Finger to check on usernames, etc. Command responses for mailed messages would be returned via mail. o Add support for a second plan file. This second file would only be dis- played if the caller had a (installation-defined) privilege or identi- fier enabled. This would allow administrators to post home/office phone numbers, etc. in the privileged plan file, but would prohibit students from viewing the information. Users without the privilege or identifi- er would see the standard plan file. o Support other TCP packages / Provide better TCP support (such as the remote node/user for an incoming session). I need volunteers for this as I have no TCP hereat all. o Allow the user to specify the desired sizes for the common block during installation. This would solve the problem of having to distribute a *huge* common block so users without Fortran can use the package. Anyway, these are just a few ideas. What do *you* want to see in the next release of VMS Finger? If you have any suggestions, just send a message to this list (i-finger@spcvxa) and we'll see what we can do for you. Terry Kennedy terry@spcvxa.bitnet ================================================================================ Note 5.3 Info-Finger Postings for September, 1989 3 of 16 SPCVXA::INFOFINGER "Selden E. Ball, Jr. - -------------------------------------------------------------------------------- Terry, Please add my vote for TCP source/user infomation display. I also have an additional item for your Finger wish list. It would be nice if the defaults for the information displayed were somewhat different. I changed one of the earlier versions of Finger to do this, but it seems not to be so easy to persuade the more recent versions to do things this way. To be specific, I would very much like the default display to show only interactive jobs. If any qualifier is used, however, only that class should be shown. For example, $ Finger should show only interactive jobs $ Finger/batch should show only batch jobs $ Finger/batch/inter should show both. (I particularly don't like batch jobs in the default because it takes so long to look through JBCSYSQUE.DAT on our cluster.) Thanks, Selden E. Ball, Jr. Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 Wilson Synchrotron Lab BITNET: SEB@CRNLNS Judd Falls & Dryden Road Internet: SEB@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SEB = 44283::SEB ================================================================================ Note 5.4 Info-Finger Postings for September, 1989 4 of 16 SPCVXA::INFOFINGER "Laurelin of Middle Earth, x2214" 24 lines 15-SEP-1989 20:21 -< RE: finger -- what would *you* like? >- -------------------------------------------------------------------------------- Terry, It would be nice if the /CLUSTER information meant that when you FINGER someone at a cluster-alias DECnet node name, you find out that user is logged in on node [specific-node] of the cluster. (i.e., instead of DECnet getting you to a random node where this person may or may not be logged in, you find out if the person is logged in to the cluster, anywhere). About the second plan file: this should be easily ``negated'' via the CLD file so that re-building the whole thing is not required if you do NOT wish to use this feature. The ``(installation-defined) privilege or identifier'' should DEFINITELY be an identifier (NOT a privilege) -- far easier to maintain. (What about just using plain old UIC/ACL-based protection on this secondary file, then the user him/herself could determine who is/is not allowed to read it? System managers and the like would be completely removed from the loop -- a definite benefit!!) I very much like the idea of specifying the desired size for the common block. (Where, presumably, size is some multiple of the number of UAF records or some other easily-determined parameter...) Other ideas sound good -- have fun! ================================================================================ Note 5.5 Info-Finger Postings for September, 1989 5 of 16 SPCVXA::INFOFINGER "Terry Kennedy - -------------------------------------------------------------------------------- Lauri writes: > It would be nice if the /CLUSTER information meant that when you FINGER > someone at a cluster-alias DECnet node name, you find out that user is > logged in on node [specific-node] of the cluster. (i.e., instead of > DECnet getting you to a random node where this person may or may not be > logged in, you find out if the person is logged in to the cluster, > anywhere). That is the main reason for the feature. It would use the new (in V5.2) cluster GETJPI and report the node and username. /NODE would probably also be a new qualifier (generating output just to the left of the username col- umn, thusly: PID Node Username 2100034C YELLOW SOMEBODY 21400872 GREEN TEST_USER etc. /CLUSTER without /NODE would just show all users on the cluster, where both qualifiers would show the node name as well. Using neither of these would give today's default behavior. > About the second plan file: this should be easily ``negated'' via the > CLD file so that re-building the whole thing is not required if you do > NOT wish to use this feature. The ``(installation-defined) privilege or > identifier'' should DEFINITELY be an identifier (NOT a privilege) -- far > easier to maintain. (What about just using plain old UIC/ACL-based > protection on this secondary file, then the user him/herself could > determine who is/is not allowed to read it? System managers and the > like would be completely removed from the loop -- a definite benefit!!) This was requested by a specific site for a split student/administrative system (no, not here at SPC!). It was a very specific request. I'll certain- ly entertain other suggestions about it as well, though. As far as rebuilding, I don't think any builds would be necessary to ena- ble/disable the feature. If you don't have the alternate planfile it will never try to print it. In the cases where this feature would be useful, I have found there is already something (either identifier or priv.) to dif- ferentiate the 2 classes of users. The system manager wouldn't be involved except to do the setup during account creation, and as I said, there is usually some way to tell the 2 groups apart anyway. The reason privilege is allowed as well as identifiers is that some users really haven't started using them yet and don't want to start just for this. > I very much like the idea of specifying the desired size for the common > block. (Where, presumably, size is some multiple of the number of UAF > records or some other easily-determined parameter...) I am thinking of something like this for the installation process (if you respond "YES" to rebuild FINGERSHR): The default installation provides storage for X usernames, Y hosts, Z networks, and N processes. Are these values acceptable? : (if user says no:): Enter the maximum number of usernames to store? : (repeat for other values) Terry ================================================================================ Note 5.6 Info-Finger Postings for September, 1989 6 of 16 SPCVXA::INFOFINGER "James Dryfoos- PostMaster - -------------------------------------------------------------------------------- When I execute install_finger.com I get the following error: $ Link/NoTrace FingerLib/Lib/Include=Finger$Main, - Jlib/Lib, - Sys$System:Sys.Stb/Sel, - Sys$Input/Options - /Exe=DUA0:[JIM.FINGER]Finger Finger$Directory:FingerShr/Share %LINK-W-NUDFSYMS, 1 undefined symbol: %LINK-I-UDFSYM, GET_QUEUE %LINK-W-USEUNDEF, undefined symbol GET_QUEUE referenced in psect $CODE offset %X000003C2 in module USER_INFO file DUA0:[JIM.FINGER]FINGERLIB.OLB;1 $ Goto Lnk$3b Also, when I run it with certain options such as /full it shows a few processes and then crashes. Appreciate any help. -Jim *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* * James Dryfoos -- Medical Informatics - Duke University Medical Center * * * * VMS Systems Programmer -- Postmaster - Duke Electronic Mail Post Office * * DMPM@DUKEMC.BITNET -- Duke Medical Postmaster * * DRYFO001@DUKEMC.BITNET -- Personal Address * * Box 2914 D.U.M.C. Durham, NC 27710 USA -- (919) 684-6421 * * * * My PLAN is to get through this day!!!!!! * *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Thanks in advance NOTE: I am not yet on the i-finger list so please send replies to me. ================================================================================ Note 5.7 Info-Finger Postings for September, 1989 7 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 31 lines 19-SEP-1989 15:53 -< RE: Problem with install_finger.com >- -------------------------------------------------------------------------------- James Dryfoos writes: > When I execute install_finger.com I get the following error: > %LINK-W-NUDFSYMS, 1 undefined symbol: > %LINK-I-UDFSYM, GET_QUEUE > %LINK-W-USEUNDEF, undefined symbol GET_QUEUE referenced > in psect $CODE offset %X000003C2 > in module USER_INFO file DUA0:[JIM.FINGER]FINGERLIB.OLB;1 > Also, when I run it with certain options such as /full it shows a > few processes and then crashes. Get_queue is the module which determines the batch queue name for a batch job. Not having it in the image may cause the problem you report with /full crashing. Get_queue is compiled by answering "yes" to the "compile the other Fortran routines" or "compile everything" questions in finger_build.com. Did you re- build the object library if you got a source-only distribution? Did the com- piler report any warnings or errors when compiling GETQUEUE.FOR? What versions of VMS, Fortran, and Finger (please give the date at the top of the code in FINGER.FOR as well) are in use here? Also, where did you get your Finger distribution from? > NOTE: I am not yet on the i-finger list so please send replies to me. You are on the list now... Terry ================================================================================ Note 5.8 Info-Finger Postings for September, 1989 8 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 51 lines 19-SEP-1989 20:04 -< RE: Problem with install_finger.com >- -------------------------------------------------------------------------------- James Dryfoos writes (in a direct mail message; you're not missing an article): > When I compile getqueue.for I get the following: > $ fortran/nocheck/nodebug getqueue.for > %FORT-E-IMPNONE, Untyped name, must be explicitly typed > [QUI$M_SEARCH_EXECUTING_JOBS] in module GET_QUEUE at line 507 > %FORT-F-OPENOTPER, Operation not permissible on these data types > [ ] in module GET_QUEUE at line 507 > %FORT-F-ENDNOOBJ, DUA0:[JIM.FINGER]GETQUEUE.FOR;2 completed with 2 diagnostics > - object deleted > I am compiling on VMS 5.1-1 system. > I cannot tell what version of fortran -- how can I do that? > I have the most recent finger from vmsserv@spcvxa -- v51.1.21 *Very* strange. I just checked it here, and it compiled Ok (VMS V5.2, VAX Fortran V5.3-50). I've not touched GETQUEUE.FOR, so it's always compiled with whatever DEC software versions I've had. I suspect an installation problem with your Fortran compiler. In the VAX Fortran Installation Guide, p. 16, it says: "FORSYSDEF.TLB should be built during the initial VAX FORTRAN installation on a system. It does not need to be installed with succeeding VAX FORTRAN up- dates, but should be installed after a VMS update is performed on the system. In this way, the FORSYSDEF modules are automatically updated to reflect any changes to the VMS system definitions in that release of VMS." Since the queue stuff is new in V5, if the library hasn't been rebuilt the GETQUEUE code won't compile. To verify the fortran version in use, compile with the /LIST qualifier and examine the listing heading. > Note: I actually want to run it on a vms 4.7 system also. > Is this possible? This version won't easily run on V4 systems. A version to run under V4 was available, but it was before I took over maintenance, so I don't have it. Per- haps someone else on the list has a copy? To get this version to work on V4, you'd have (at least) the following: o LAT and Queue system calls are unavailable o Mail profile format is different I'd suggest either getting the old Finger code and merging (any) desired new functionality in, or upgrading the system to V5. By the way, the next major release of Finger (V52.2.00) will require V5.2, but I will continue to support (and provide distributions for) V51.1.xx for as long as people still want to run it. Terry ================================================================================ Note 5.9 Info-Finger Postings for September, 1989 9 of 16 SPCVXA::INFOFINGER "Laurelin of Middle Earth, x2214 " 4 lines 20-SEP-1989 17:20 -< another finger feature requested >- -------------------------------------------------------------------------------- Finger currently reports the number of users in I2 format. This causes output conversion errors (unit 5) around here quite frequently, because we very often have over 99 users on a node. Could this please be increased to allow for up to 999 users? Thanks, Lauri Loebel ================================================================================ Note 5.10 Info-Finger Postings for September, 1989 10 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 25 lines 20-SEP-1989 17:30 -< RE: another finger feature requested >- -------------------------------------------------------------------------------- Lauri Loebel writes: > Finger currently reports the number of users in I2 format. This causes > output conversion errors (unit 5) around here quite frequently, because > we very often have over 99 users on a node. Could this please be > increased to allow for up to 999 users? It's certainly possible, and even easy (my kind of feature request 8-). However, if you're running an intermediate patch release of VMS (V5.1-1, for example) on a VAX 700-class processor on a Wednesday, the line will wrap! This will certainly be needed for the cluster-wide Finger changes, so I will implement this in some form. Here's what I'm thinking: o Write the number out with one leading space, regardless of length. Thus, we'd get ', 2 Users' or ', 374 Users' rather than the current ', 2 Users' However, the space will have to come from somewhere. I am currently leaning towards either removing the comma between the day of the week and the date, or the '19' part of the year. I have no particular pref- erence myself, so if anyone feels strongly, please let me know. Terry ================================================================================ Note 5.11 Info-Finger Postings for September, 1989 11 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 27 lines 22-SEP-1989 16:49 -< Other discussion groups with similar areas of interest >- -------------------------------------------------------------------------------- Doug Sewell sent the following information. If you are interested in following VM-oriented user directory informatiomn, you might want to subscribe to these lists as well. Terry ---------------------------------------------------------------------- There are two discussions already on similar topics, although they are primarily VM-oriented. USRDIR-L (LISTSERV@UGA, and others) - Discussion on user directory servers. Implementations such as WHOIS@ALBNYVM1, UMNEWS@MAINE, and the /WHOIS LISTSERV mod discussed. Has been quiet lately, due to user directory services implementation on LISTSERV 1.6 being close to complete. UDD-L (LISTSERV@CEARN) - Discussion on the LISTSERV 1.6 User Directory Services implementation. Code is not completely implemented yet - Registrations are accepted from users, but presently there is no database (LDBASE) lookup, proxy registration by postmaster, etc. Current status and ongoing changes discussed. This list is also somewhat quiet lately. Doug Sewell (Watchman on RELAY - DOUG@YSUB.BITNET), Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555 >> You are in a maze of twisty little passages, all alike. ================================================================================ Note 5.12 Info-Finger Postings for September, 1989 12 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 16 lines 26-SEP-1989 09:30 -< Features for Finger >- -------------------------------------------------------------------------------- Charlie Lemond writes: > If you're still taking requestS for new features for FINGER, I'd like to > see something analagous to TYPE/PAGE for FINGER (e.g. FINGER/PAGE > that would display 23 or so lines of text then display HIT RETURN TO CONTINE. > With 90 or more users on the system info seems to scroll by rather quickly! This sounds like a good idea. I could take the page length for the current terminal, subtract one, and page that many lines at a time. Would you like to see the header repeated each time, or just at the very beginning? This feature would be a little hard to handle properly for cases like FINGER @node/PAGE, though, as I'd have to buffer the output (one can't impose flow control on Bitnet messages) somewhere. What do the rest of you think about such a feature? Terry ================================================================================ Note 5.13 Info-Finger Postings for September, 1989 13 of 16 SPCVXA::INFOFINGER "Terry M. Combs - -------------------------------------------------------------------------------- I am wondering if it would be possible to include a /SUMMARY option which would give the total number of users on a specified group in conjunction with the /CLUSTER: /NODE= Gives the header information only for this node /SUMMARY Without node would give the header information for each node in the cluster /ALL Lists all nodes in the cluster without naming them This would enable us to issue the command: $ FINGER /CLUSTER /SUMMARY All nodes (1 summary header) $ FINGER /CLUSTER /NODE=(node1,node2,node3...) Specific nodes $ FINGER /CLUSTER /SUMMARY /ALL All nodes (1 header per node) - Terry Bitnet: COMBSTM@APPSTATE ================================================================================ Note 5.14 Info-Finger Postings for September, 1989 14 of 16 SPCVXA::INFOFINGER "Terry Kennedy, Operations Mgr <" 26 lines 26-SEP-1989 16:09 -< RE: Features for Finger >- -------------------------------------------------------------------------------- Re finger/page: 1. Don't bother repeating the header. 2. The /page operation over a network is probably not such a good idea to try to support. An option to allow finger to output to a scratch file someplace would however cover this rather nicely, allowing folks to generate the finger file, then type it with one of the many page-at-a-time typer utilities (I use T from the decus C kit). I see no /output in fingercld.cld. A bit of DCL glue could pretty much cover up the tracks of the jiggery-pokery. Of course, one can $ass/user file.typ sys$output first and get this now, so it isn't all THAT important. I suspect that getting the V5.2 services support in before the fall '89 symposium is more important. When I have such problems, I'm more inclined to think in terms of adding page-at-a-time with DCL glue and T anyhow. This can certainly be locally done. You then just make your finger command look something like $ass/user tmp.jnk sys$output $finger 'p1' $typ/page tmp.jnk $del tmp.jnk. and it goes by pages, or all displays as you wanted in the first place, modulo ONE scratch file that gets deleted when you're done with it. Glenn Everhart ================================================================================ Note 5.15 Info-Finger Postings for September, 1989 15 of 16 SPCVXA::INFOFINGER "Shawn Allin - Alcan KRDC Comput" 19 lines 27-SEP-1989 08:38 -< Has anyone successfully made VMS FINGER work with CMU's TCP-IP? >- -------------------------------------------------------------------------------- Hello, Has anyone got the FINGER program currently supported by Terry Kennedy to work with CMU-TEK's TCP-IP package? I'd prefer to use this version instead of CMU's version. Thanks, Shawn Allin Alcan International Ltd., P.O. Box 8400, Kingston, Ont., Canada K7L 5L9 (613) 541-2178 Bitnet: ACCESS@ALCANKTN ================================================================================ Note 5.16 Info-Finger Postings for September, 1989 16 of 16 SPCVXA::INFOFINGER "David L. Bartlett