From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 30-MAR-1993 22:16:11.97 To: Info-VAX@KL.SRI.COM CC: Subj: Re: Operator terminals - global data structures?y In article <1993Mar30.120304.4913@ucsvc.ucs.unimelb.edu.au>, jonathan@ucsvc.ucs.unimelb.edu.au writes: > I am wanting to programatically examine and modify the operator status of > operator terminals. It is straightforward to determine which terminals on the > local node are operator terminals using $DEVICE_SCAN and $GETDVI. One can use > $SNDOPR to enable/disable operator classes and to display operator status, but > this does not return information to the program and (presumably) produces > associated OPCOM messages. > > Questions: > > 1. What global data structures can be used to determine: > . all enabled operator terminals > > 2. What global data structures can be used to examine and modify: > . operator classes enabled on a given terminal > . temporary or permanent status of operator terminal > > 3. Can any of this be done on a cluster-wide basis from the local node, > presumably using system services? > > Code examples would be useful. > I attacked this problem some time ago as a self-set exercise - I think when my site was running V5.0 of VMS. Basically, all of the operator status information (including a lot more that it records but doesn't display to you, including the operator's UIC and enabled privileges at the time the terminal was enabled) are stored in P0 space for the OPCOM process. In other words, the only way to access it is via tricky privileged programming. I wrote a program to report all of the operators enabled, their usernames, UICs, privileges and enabled classes cluster-wide. Cluster-wide was made easy by the fact that all OPCOM processes communicate to each other and all let each other know about their operator friends on each node. So any operator on any node will have info about him/her in P0 of every OPCOM in the cluster. To get this info, my program delivered an AST to OPCOM telling it to run a bit of code that I wanted it to. This code got it to traverse it's OPCOM data structures and write selected info about each operator to a global section I had created. I then picked the info out of the global section and dumped it on the screen. There was only one problem with the program, and the problem is more with OPCOM than my code. OPCOM has to allow for the fact that some operators do not "disable" their terminal before logging out, and for the fact that their processes might die before they disable a terminal. So it is possible that an operator that OPCOM thinks is there has gone away. When OPCOM tries to talk (ie. broadcast) to an operator and finds that he/she has gone home without telling it, OPCOM deletes the operator from it's database (effectively a "reply/disable"). To cope with this, before my code dumps info about an operator to the screen, it checks that the enabled terminal still exists (using $GETDVI) (yes I'm talking about LAT terminals). Naturally it was not possible to use $GETDVI to check terminals on another node, even though OPCOM held info about other nodes. FLAME ON I think OPCOM is brain dead. Your statement that "one can use $SNDOPR to enable/disable operator classes and to display operator status, but this does not return information to the program and (presumably) produces associated OPCOM messages" is correct. $SNDOPR can return no info to the caller about enabled operators and in fact *does* send a broadcast message about the status of *your* request to the *other* terminal. In other words, if you request status information about any terminal, the result of that request will be a broadcast message to the terminal that the info was requested about ! No info is returned to you - the caller ! A number of our unprivileged users found this out and used it to annoy other users and operators, and there is no way of finding out who they are. It's even easier with DCL. REPLY gives you no opportunity to specify another terminal like $SNDOPR does, but it uses SYS$COMMAND. Just define SYS$COMMAND to be some other terminal and you can send rubbish to that terminal, even without OPER privilege. Try this : $ define/user sys$command opa0: $ reply/status Any unprivileged user can do this and send OPA0's operator status to OPA0. This might be the OPCOM banner followed by "an illegal operator request was made" or it might be "CARDS,CENTRAL,SECURITY,TAPES" etc. Try this specifying any terminal and repeat it a large number of times (eg. in a command procedure) to virtually make ANY terminal useless by bombarding it with OPCOM messages. As a system or security manager, try finding out who is doing it - no can do ! I reported this to Telephone Support as a problem and the response was "sorry - log an SPR", which I did, but still no fix ! FLAME OFF To answer your questions, you can get operator information from OPCOM, but you need to be able to write code that delivers an AST to it asking it to return the information to you. You also need to know the internal OPCOM data structure layouts. This can be determined from the VMS source listings under the heading OPCOM. I had to change my program for at least one release of VMS and I haven't run it for a while. It may not work under my current VMS version (5.5-2), but it's fun keeping up with the changes and seeing what DEC change each time. I suppose you could use similar techniques to *modify* operator status, or even add or remove operators, but I would recommend sticking to $SNDOPR for changes, even if $SNDOPR's and OPCOM's functionality is typical of version 1 (field test) of a cheap software product. If you want a copy of my code, ask. Craig McGill. VMS System Programmer. Canberra, Australia. [The opinions expressed in this note are not necessarily those of anyone but me]