From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 7-FEB-1991 00:45:35.34 To: MRGATE::"ARISIA::EVERHART" CC: Subj: RE: DECwindows Login process Received: by crdgw1.ge.com (5.57/GE 1.80) id AA03195; Wed, 6 Feb 91 16:45:42 EST Message-Id: <9102062145.AA03195@crdgw1.ge.com> Received: From CUNYVM.CUNY.EDU by CRVAX.SRI.COM with TCP; Wed, 6 FEB 91 10:22:42 PST Received: from DGOGWDG1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8830; Wed, 06 Feb 91 13:23:03 EST Received: from dnet.gwdg.de by DGOGWDG1.BITNET (Mailer R2.07) with BSMTP id 6013; Wed, 06 Feb 91 19:21:01 MEZ Date: Wed, 06 Feb 1991 19:20:59 +0100 From: "GWDGV1::MOELLER" To: FLJ@epavax.GE.COM, info-vax@sri.com Cc: "info-vax@sri.com"@GWDGI.DECNET, MOELLER@CRVAX.SRI.COM Subject: RE: DECwindows Login process Frank Bounds asks: > I am writing a document for use by System Managers at remote > EPA sites. This document will detail various things about > DECwindows from a system managers point of view. >[...] > 3. RUN SYS$SYSTEM:DECW$STARTLOGIN > - translates DECW$DISPLAY > - sends message to job controller that there is > input on __source__(WSAxx:). > > 4. Job controller > - create detached process under SYSTEM UIC > - Run LOGINOUT.EXE > > 5. LOGINOUT.EXE > - Obtains device from job controller by translating SYS$INPUT. > - Activate DECW$LOGINOUT.EXE to diplay LOGO and USERNAME/ > PASSWORD. > - Accept input > > How do these get run from this point? > 6. DECW$SESSION.EXE (??) > - Translate DECW$WIMGEXE (??) > 7. DECW$WINMGR.EXE (??) Ok, I'll bite. Take the following as a first draft (applies to VMS 5.4) ... Note: I learned the following information from fiches and observation of actual system behaviour; since it's undocumented, it's prone to change with any new release. 5. LOGINOUT.EXE - Obtains device from job controller by translating SYS$INPUT. - Activates (via LIB$FIND_IMAGE_SYMBOL) DECW$LOGINOUT.EXE - translates DECW$LOGIN_BACKGROUND: if that's undefined, it displays the "digital" logo, otherwise it creates a detached process (user=SYSTEM, prcnam=LOGO) to run the *command procedure* pointed at by the logical. - opens up the USERNAME/PASSWORD window and waits for valid input (possibly spending some CPU time ...) - once valid input has been received (note that USERNAME can have the qualifiers known from terminal login) ... - stops the LOGO process, if applicable. - changes the X-server access list to allow for 0 - creates a detached process for the user (prcnam=DECW$WM_) which runs DECW$WINMGREXE (a.k.a. DECW$WINMGR.EXE) - maps DCL (analogous to an interactive process), but instead of the normal files (SYS$SYLOGIN and `lgicmd') asks it to execute in order: - SYS$MANAGER:DECW$SYLOGIN.COM (or maybe the file given by the system logical DECW$SYLOGIN - I haven't checked this) - DECW$LOGIN.COM in the user's default directory, or the command file mentioned as /COMMAND= with the USERNAME - SYS$MANAGER:DECW$SESSION.COM which in turn runs DECW$SESSION. (6) DECW$SESSION feeds the X-Server with all the funny things that you can select from its customize menus, among them a possibly new access list. - in order to create most application(s), DECW$SESSION creates another logged-in interactive process with SYS$COMMAND pointing to a *mailbox*, and feeds it the command(s) required to start the application(s), and stops that process when done. => this is the infamous *interactive* process that dies when => a user's LOGIN.COM contains INQUIRE commands etc. [I only care for DECterms at this point and have not yet studied the workings of VUE.] (7) If the above application was a DECterm, the command would have been CREATE/TERMINAL/DETACH, which in turn creates a detached process (prcnam=DECW$TE_) to run DECW$TERMINAL.EXE (unless that process already exists). Also, it creates the desired logged-in interactive process with SYS$INPUT=SYS$OUTPUT pointing to the TW device that ultimately gets mapped to the actual terminal window. (8) The next interesting thing happens when you click the "QUIT" command in the session manager menu: DECW$SESSION ... - kills all X-server clients - does some more cleanup in the X-server databases - closes its own display and additionally tells the X-server explicitly to reset. [I don't know why & how; this was not in 5.2] - finally does the same as DECW$STARTLOGIN: tells JOBCTL that a login is pending on its WS-device. - logs itself out. Here, the loop closes (at (4)), unless the X-server's default access list does not allow a connection from SYSTEM in which case everything would end (with an empty screen ...). Note that prior to (3) above, you might have modified the X-server's access list to allow for just this access. On VAXstations, the initial invocation of DECW$STARTLOGIN is done by one of the DECW$STARTUP command procedures (usually invoked by the system startup) and ought not to be required later on; other X-servers will require an invocation by some other means, and if they are suitably well-behaved, the loop will likewise continue forever. I think that on some Xterminals the X-server reset is so hard that the new login triggered by DECW$SESSION actually fails, and a new invocation of DECW$STARTLOGIN is required at a later stage (VT1300s use DECnet task-to-task communication here). I'm sure there's a lot to be added to this draft ... Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ... Bitnet/Earn: U0012@DGOGWDG5 Phone: +49 551 201516 | No claim intended! Internet: Moeller@gwdgv1.dnet.gwdg.de | This space intentionally left blank.