From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 25-AUG-1993 08:57:03.77 To: EVERHART CC: Subj: Re: VAXstation 2000 to X terminal X-Newsgroups: comp.os.vms Subject: Re: VAXstation 2000 to X terminal Message-Id: From: kalisiak@cs.buffalo.edu (Chris Kalisiak) Date: Sun, 22 Aug 1993 16:35:10 GMT Sender: nntp@acsu.buffalo.edu Organization: UB Nntp-Posting-Host: armstrong.cs.buffalo.edu X-Newsreader: TIN [version 1.1 PL8] Lines: 244 To: Info-VAX@kl.sri.com X-Gateway-Source-Info: USENET fairfield@slacvx.slac.stanford.edu wrote: >In article , jburns@agora.rain.com (Jamie Burns) writes: >> Does anyone know how I can convert my historic VAXstation 2000 >> to support X, since its diskless. I have a 7000-630 to use as the >> server. I have only heard about it, so I was just wondering. Thanks. > Yes, there's a DEC product called EWS which tunrs your lowly VS2000 > into an X-terminal. It's really VAX/ELN linked to do just DECwindows > (with DECnet or LAT and a little TPC/IP thrown in for connectivity). I have been told (but have not purchased and/or used the product, so I don't know for sure) that EWS is not that great. > Minimum requirement is 6 MB of memeory, but the more the better. I thought 6meg was the _maximum_ that was required. It seems to me someone posted here and said that you can have more than 6meg, but was a waste. > I have a color VS2000 with 10 MB and it's _passable_. But believe > it or not (yeah, I guess I'd believe it :-), a 33Mhz 486 PC running > HCL eXceed or VisionWare's XVision (as the X-server) does a much > better job [and I'm no fan of PC's]. ISA, EISA, or VESA? There is a huge difference between the three. Following is a description that was extracted from comp.os.vms a while back. It doesn't require any more than 6meg of memory and doesn't require a local disk. It's called "Poor Man's X Terminal". I use it and love it. It didn't cost anything more than 1/2 hour's worth of time. One thing to keep in mind is that you have to follow the directions explicitly or it won't work (until you go through and figure out what you didn't type in correctly. :-) >From acsu.buffalo.edu!ub!rutgers!uwm.edu!linac!att!princeton!pupgg.princeton.edu!GROTH Tue Jun 22 17:21:54 1993 Path: acsu.buffalo.edu!ub!rutgers!uwm.edu!linac!att!princeton!pupgg.princeton.edu!GROTH From: GROTH@pupgg.princeton.edu (Edward J. Groth 609-258-4361) Newsgroups: comp.os.vms Subject: Poor Man's X Terminal Message-ID: <1993Jun22.174403.22442@Princeton.EDU> Date: 22 Jun 93 17:44:03 GMT Sender: news@Princeton.EDU (USENET News System) Reply-To: groth@pupgg.princeton.edu Organization: Physics Department, Princeton University Lines: 188 Originator: news@nimaster Nntp-Posting-Host: pupggg.princeton.edu There has been some recent discussion in this group on using VAXstation 2000's as X terminals. I've been thinking of doing the same thing and the discussion led me to believe I would have a hard time getting (and getting to work) the VXT2000 software. There has also been some discussion about allowing access to the X server when the access hasn't been set by the session manager and its security options. This has proved very helpful in what follows. I'm going to describe how I set up what I call a poor man's X terminal. This is a VAXstation 2000 running vms and decwindows, but only the server. The login box and all other client functions are running on some other more powerful CPU which is running DECwindows (but not necessarily a decwindows server, I believe.) The configurations I've tried this out on are a VS2000 4 plane system with 10Mbytes, a VS2000 4 plane system with 6Mbytes, and a VS2000 1 plane system with 6Mbytes as servers and a VAXstation 4000/90 running the clients. All are running VMS 5.5-2 and Motif 1.1. They are part of a homogeneous cluster but need not be, I believe. In what follows, I will refer to the server as node XSERV and the client as node XCLI. The steps to get this to work are: (1) Set up an account for a decnet object; (2) Create the object login procedure; (3) Create the object; (4) Allow access to the server from the client; (5) Modify DECW$PRIVATE_APPS_SETUP.COM; (6) Create a procedure to be run in place of DECW$STARTLOGIN. 1. Set up an account for a decnet object: Use authorize and create an account with the following specifications: User: PMXTERM /Owner ="Poor Man's Xterminal Start" /Account =PMXTERM /UIC =[mmm,ggg] (pick a non-system UIC which doesn't conflict with others) /Device =SYS$COMMON /Direct =[PMXTERM] /LGICMD =PMXTERM_STARTLOGIN.COM /Flags =(Restricted,Diswelcome,Dismail,Disreport,Disreconnect) /Password=you pick one but remember it for below /NOPWDEX /NOBATCH /NOLOCAL /NODIALUP /NOREMOTE /Defpriv=(CMKRNL,SYSNAM,TMPMBX,NETMBX) All the other UAF parameters can probably be left to defaults (at least they could on my system!). 2. Create the object's login procedure: $ CREATE/DIRECTORY/OWNER=PMXTERM SYS$COMMON:[PMXTERM] and put the following file in it (named PMXTERM_STARTLOGIN.COM): $! This procedure is used as a poor man's x terminal startup $! $! We just create a display on the remote node and $! then run the decwindows startlogin program $! $! Edward J. Groth June 19, 1993 $! $! $! $ purge/keep=2 netserver.log $ set display/create/perm/transport=decnet/node='f$trnlnm("sys$rem_node")' $ run sys$system:decw$startlogin $ open/write pmxtermlink sys$net !this is to let the other end know we're done $ write pmxtermlink "Done" $ wait 00:00:05 $ close pmxtermlink $ logout 3. Create the Decnet object. On the client node, run ncp and define a decnet object as follows: NCP>define object pmxterm number 0 user pmxterm - password NCP>define object pmxterm alias incoming disabled NCP>define object pmxterm alias outgoing disabled NCP>define object pmxterm file sys$common:[pmxterm]pmxterm_startlogin.com NCP>set object pmxterm all 4. Allow access to the server from the client: Create a file named DECW$SERVER_ACCESS_TRUSTED.DAT in SYS$SPECIFIC:[SYSMGR] for node XSERV (and all other nodes which you intend to be poor man's x terminals). The file should contain the line DECNET XCLI * (transport node user) (be sure to substitute your correct node name for XCLI) 5. Modify SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM Add the following to decw$private_apps_setup.com $! $! For nodes which are to be "poor man's x terminals", redefine the main $! application. $ pmxtermnodes="XSERV" !Be sure to substitute for XSERV $ nodename=f$getsyi("NODENAME") $ if f$locate(nodename,pmxtermnodes) .lt. f$length(pmxtermnodes) $ then $ decw$mainapp == "@sys$common:[pmxterm]pmxtermstart" $ endif If you have more than one node you want to be an X terminal, then use $ pmxtermnodes="XSERV1/XSERV2/XSERV3" etc. 6. Create the new mainapp procedure. In SYS$COMMON:[PMXTERM], place the following file named pmxtermstart.com $! This procedure is to be pointed at by decw$mainapps in $! decw$private_apps_setup.com. $! It is used to fire up a login process on a remote node $! rather than the local node. $! $! Edward J. Groth June, 1993 $! $ open pmxtermlink XCLI::"task=pmxterm" !Substitute for XCLI $ read pmxtermlink junk !Wait for the other end to finish $ close pmxtermlink $ exit If you've completed all the steps above, then on the server node do $ @sys$manager:decw$startup restart And you should wind up with node XSERV running only the decwindows server and node XCLI running the decwindows login process. In my case, this makes a painfully slow VS2000s pretty spiffy. Of course, your VS2000 is still running VMS and requires a page file somewhere, etc., so it's not quite as nice as having a real X terminal - that's why it's a poor man's X terminal! Discussion on the net mentioned DECW$SERVER_ACCESS_ALLOWED.DAT and DECW$SERVER_ACCESS_TRUSTED.DAT. I could not find any documentation on these files. Both of these seem to specify for access to the server. I did some experiments and concluded the following: the access specified by ...ALLOWED.DAT is "permanent" and the access specified by ...TRUSTED.DAT is overwritten by the access specified in the security options menu of the session manager. Note that the access must be specified with a * for the user so that when a random USER logs in and the client node tries to connect on behalf of USER, access is granted. Thus, while the login box is showing, anyone on node XCLI can connect to the server. If the access is specified by ...ALLOWED.DAT, this continues to be true even after someone has logged in (BAD). If the access is specified by ...TRUSTED.DAT, then once a user has logged in and the session manager is running, access is denied to other users (GOOD). At least it worked this way in my experiments! If someone has already posted a solution like this, I'm sorry - I didn't see it. If anyone has any suggestions for improvements, I would be interested in hearing them. - Ed /----------------------------------------------------------------------\ | Edward J. Groth | Phone: 609-258-4361 | | Physics Dept., Jadwin Hall | Fax: 609-258-6853 <- Changed 1-Feb-93 | | Princeton University | SPAN/HEPNET: PUPGG::GROTH=44117::GROTH | | Princeton, NJ 08544 | Internet: groth@pupgg.princeton.edu | \----------------------------------------------------------------------/ -- Chris Kalisiak | "Pound for pound, lame puns are your best kalisiak@cs.buffalo.edu | entertainment value." -- Gogo Dodo, Tiny Toons V076N3W7@ubvms.cc.buffalo.edu| "Stimpy, your wealth of ignorance astounds me." V076N3W7@ubvms.bitnet | -- Ren Hoek, Ren and Stimpy