Well, now that V5.1 and DECwindows is out lets get some VMS DECwindows related goodies onto this list! To start things rolling, here's a little hack to allow non workstation hosts, generally large, multiuser VAXen, to create a DECwindows (DW from now on, my fingers are tired of that!) LOGINOUT screen on a workstation running just the server. Our little development cluster here at Ashton-Tate consists of a fairly hefty MicroVAX 3600 with a couple of GPX workstations (till our PVAXen show up :-). We all like running on the 3600 and it's a pain to login on the GPX and then use SET HOST to get your terminal windows onto the faster machine. Also, things like DW MAIL and DW TPU are kinda slow to start up and the 3600 makes a difference. When DW starts up it determines if it is running on a workstation or not. If not, it simply does the things that need to be done on a client-only machine, not much, and exits. On a workstation it goes on to start the server and then create a DW LOGINOUT process which throws up the wonderful "|D|i|g|i|t|a|l|" logo and the "Username/Password" dialog box. What we do here is create the DW LOGINOUT on the client-only machine and not on the workstation. When you login your session manager, window manager, DECterm controller, etc. processes are all running on the client-only machine with all windows directed, by default, to the workstation over the network. This sort of configuration is also useful for VAXstations, like the 2000, which might not have enough memory or CPU to handle the DW X server as well as all your DECterm sessions and DW applications. By running the server only, it may well be possible to get acceptable DW performance out of a VAXstation 2000 with only 4 Mb of memory. I have not tried it, but I suspect this is a good way to breathe some new life into such a system. I do know that my 16 Mb VAXstation II/GPXs make fine DW server-only machines... By the way, you can have multiple LOGINOUT dialog boxes on a workstation and you can even login through all of them, creating an interesting jumble of session managers, icon boxes, etc! Of course the LOGINOUT dialog boxes are always created at the same screen coordinate so you only see one on the screen until you satisfy it, uncovering the next one. Interesting, but not terribly useful. Anyway, back to the topic at hand... To get this to work, you need to do the following: Step 1: ------- You have to modify the DW startup slightly to allow for the site-dependent DECW_LOGIN_SATELLITES.COM procedure to be invoked. Unfortunately this mod is to a Digital-distributed DCL command procedure, DECW$STARTAPPS.COM, which may be replaced in future releases. It is a simple change but keep in mind that you may have to check and reapply it later. DECW_LOGIN_SATELLITES.COM should be modified for your configuration and placed in SYS$COMMON:[SYSMGR]. It is meant to be executed by all members of a cluster. A DIFFERENCES listing of my DECW$STARTAPPS.COM with the standard VMS V5.1 version appears at the end of this message. DECW_LOGIN_SATELLITES.COM is called by all systems at startup and is solely responsible for creating DW LOGINOUT processes for a client on the appropriate satellite workstations. Note that the workstations run this as well, but if they don't have an entry they won't start a DW LOGINOUT on themselves. They could, if you so choose, or they could create one on another satellite workstation. That might be appropriate if you have a big fast workstation and want to allow another user from a small VAXstation 2000 onto the big workstation. Keep in mind that the two-user license limit for workstations and VAXservers will be enforced with DW LOGINOUT. I run my client hosts and my workstations all in one homogeneous LAVC. Since DW only requires a network connection between client and server, the client and the satellite do not have to be in the same cluster. You will need to keep an appropriate copy of DECW_LOGIN_SATELLITES.COM on each, however. My DECW_LOGIN_SATELLITES.COM appears at the end of this message. Step 2. ------- When the DW server starts up, it maintains a list of hosts which are allowed to make network connections to the server. There are, apparently, two categories of access: "trusted" and "allowed". I have not experimented much with this, but I believe "allowed" means that the incoming host may create windows and do other typical X functions while "trusted" would also permit the incoming host to perform such privileged functions as modifying the list of allowed hosts. By default, the DW server considers only itself to be "allowed" and "trusted". Once you have logged into the session manager, the list of hosts with "allowed" access is modified to those you specified in your security customization. When you logout the list reverts to the local host only (this was not true in FT DW -- your access list stuck around after you logged out. I'm glad they fixed it before final release.). To modify this behaviour the server reads, at startup time, files called DECW$SERVER_ACCESS_TRUSTED and DECW$SERVER_ACCESS_ALLOWED using SYS$MANAGER:.DAT as the default file specification. This action, as well as the format of these files, is not documented anywhere that I could find. I did, however, figure out all I needed to know about the process. These files consist of entries, one per line, of three fields separated by whitespace. The fields are: PROTOCOL-NAME SYSTEM-NAME USER-NAME. An asterisk, "*", may be used as a wildcard match. The default is equivalent to DECW$SERVER_ACCESS_TRUSTED.DAT containing the line: * 0 SYSTEM meaning trusted access is granted to any protocol connection, from myself (host 0), with username SYSTEM. Since the session manager needs to modify the list of allowed hosts when you login to DW, I assumed that "trusted" access is required for my remote login trick and didn't experiment with DECW$SERVER_ACCESS_ALLOWED at all. My DECW$SERVER_ACCESS_TRUSTED file contains an entry specifying all protocols, username "SYSTEM", for the local host and then for each member of the cluster for whom I may want to allow DW LOGINOUT to run. Since DW LOGINOUT runs as "SYSTEM" that is the only username that needs to be specified. Other users and hosts may be specified in your session manager security customization just as before. Here's mine: * 0 SYSTEM * FRIDAY SYSTEM * MARDI SYSTEM * LUNDI SYSTEM Step 3. ------- Edit DECW_LOGIN_SATELLITES.COM to your configuration. Basically you define, for each client host that you wish to start a login process, what workstations to use. The comments and examples in the file should be sufficient to get you started. Step 4. ------- You have to restart the DW server to make it read DECW$SERVER_ACCESS_TRUSTED. Log in from a LAT terminal or to the console port or over the network as SYSTEM and restart the server with: $ @DECW$STARTUP RESTART This takes awhile, but eventually things will stabilize. You may end up with a login dialog on the screen or not, depending on whether the restart used your new DECW_LOGIN_SATELLITES.COM procedure. If you do get a login dialog you must kill its process. Hunt down and kill the process with the characteristics: Phys Base Process Image PID Term Term Username State Prio Name Name -------- ------- ------- ------------ ----- ---- --------------- -------------- 20E0013F lef 4 _WSA2: *Loginout (this is output from our NAMES utility. You'll have to look for something similar with SHOW SYSTEM). The login dialog should disappear, leaving the workstation screen blank. The login to the client hosts and execute DECW_LOGIN_SATELLITES.COM on each one. You should see the appropriate dialogs start up on your worstations. Caveats: -------- There are some minor problems. Since the DW LOGINOUT process is meant to be robust to errors from the server, it will kill itself and create a new process if anything goes wrong. This can make your client host look pretty busy if it's trying desperately to create a login dialog on a workstation that has gone south. You can kill the process (type fast!, those PIDs increment fairly rapidly!) and restart it later (using DECW_LOGIN_SATELLITES.COM or by hand if that would affect other logins that are working ok and create duplicates!) I have rebooted the client machines and the workstations individually with this but I have not rebooted everyone at once. I think it will work then, but don't know for sure. There may be other problems I don't know about. Please let me know if you enhance this thing. I will try to help if you have trouble but I'm pretty busy these days. I am looking at other interesting DW tricks and hacks and hope that others out there are as well! /Kevin Carosso kvc@friday.a-t.com Innosoft International Inc. kvc@ymir.bitnet