| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
The following is my current SPR form. Since I've found out that VMS 5.3-1 is still field test, this has been put in as a QAR. Knowing how "fast" some QAR's are answered. I'm covering my bets and putting this in this conference. In short, what's new in VMS 5.3-1/DECwindows 2.0 from VMS 5.2/DECwindows 1.0 in the way the banner/login-password windows are controlled? For details read below. --------------------------------------------- I N E E D A N A N S W E R A S A P! ! ! -------------------------------------------- Thanks to all in advance! Richard Wallace ============================================================================= D I G I T A L FIELD CODE NO. SPR NO. ------------------------------------------------------------------------------- | OPERATING SYS | VERSION | PROGRAM OR DOC. | VERSION OR DOC. PART NO. | DATE | | VMS | 5.3-1 | LOGINOUT | X-26 |7DEC89| ------------------------------------------------------------------------------- | NAME:XXXXXXXXXXXXXX |DEC OFFICE AND CONTACT PERSON |DO YOU HAVE SOURCES | | FIRM:XXXX | XXXXXXXXXXXXXXXXXXX | YES(X) NO( ) | | |-----------------------------------------------------| | | REPORT TYPE/PRIORITY | | ADDRESS: | (x)HEAVY SYSTEM IMPACT | | XXXXXXXXXXXXXXXXXXXXXX| (x)PROBLEM/ERROR ( )MODERATE SYSTEM IMPACT | | XXXXXXXXXXXXXXXXXXX | ( )SUGGESTED ENHANCEMENT ( )MINOR SYSTEM IMPACT | | CUST. NO.: XXX | ( )OTHER ( )NO SIGNIFICANT IMPACT | | | ( )DOCUMENTATION/SUGGESTION| ------------------------------------------------------------------------------- | SUBMITTED BY: |PHONE: | CAN THE PROBLEM BE YES(X) NO( ) | |Richard Wallace| D527-3443 | REPRODUCED AT WILL? | ------------------------------------------------------------------------------| | ATTACHMENTS | COULD THIS SPR HAVE BEEN PREVENTED BY | | | BETTER OR MORE DOCUMENTATION? YES(X) NO( ) | | | PLEASE EXPLAIN IN PROVIDED SPACE BELOW. | ------------------------------------------------------------------------------- | CPU TYPE | SERIAL NO. | MEM. SIZE | DIST. MED. | SYS. DEV. | DO NOT PUBLISH | | 3520 | | 48 Mbyte | | | ( ) | ------------------------------------------------------------------------------- | In VMS 5.2 running the image SYS$SYSTEM:DECW$STARTLOGIN.EXE with a process | |name table entry for DECW$DISPLAY would run the LOGINOUT.EXE/DECW$LOGINOUT.EXE |images and the DIGITAL banner window and the Username/Password window would | |appear. Under VMS 5.3 runing the image DECW$STARTLOGIN.EXE with a job name | |table entry for DECW$DISPLAY will only restart the LOGINOUT.EXE/DECW$LOGINOUT| |.EXE when there is a)no user logged into the WSAx device and b)DECW$START | |LOGIN.EXE is run from a VT terminal. Running DECW$STARTLOGIN from a DECterm | |on the WSAx device does not work either. In both the VMS 5.2 and 5.3 cases | |the DECW$DISPLAY logical points to the WSA1: device that is created at boot | |time. In both the VMS 5.2 and 5.3 cases the server protection is "* * *" | |for trusted and allowed. | | In an experiment we have logged into an attached VT with an all privs on | |account, issued a $STOP/ID=nnnnnnnn on the process with the WSA1 process | |name, done a $DEFIN/JOB DECW$DISPLAY WSA1:, and a $MC DECW$STARTLOGIN. This | |works. In another experiment we logged into the VRxxx with the banner and | |username/password windows using an all privs on account, the DECW$DISPLAY | |logical was defined to WSA1: for us by the windowing system, and from a | |DECterm ran $MC DECW$STARTLOGIN. From examination of the ACCOUNTING log with| |image accounting enabled, we see DECW$STARTLOGIN complete successfully and | |LOGINOUT not complete successfully; the question is, "Why?" The follwing is | |the accounting log of the UNSUCCESSFUL attempt to get the banner username/ | |password windows back running $MC DECW$STARTLOGIN from a DECterm: | DECW$STARTLOGIN Image Termination --------------------------------- Username: TEMP UIC: [400,4] Account: GSRC Finish time: 7-DEC-1989 12:51:10.41 Process ID: 20A000A1 Start time: 7-DEC-1989 12:51:10.34 Owner ID: Elapsed time: 0 00:00:00.07 Terminal name: TWA4: Processor time: 0 00:00:00.00 Remote node addr: Priority: 4 Remote node name: Privilege <31-00>: FFFFFFFF Remote ID: Privilege <63-32>: FFFFFFFF Queue entry: Final status code: 00000001 Queue name: Job name: Final status text: %SYSTEM-S-NORMAL, normal successful completion Page faults: 2 Direct IO: 0 Page fault reads: 1 Buffered IO: 0 Peak working set: 225 Volumes mounted: 0 Peak page file: 648 Images executed: 42 Image name: LOFTI$DKA0:[SYS16.SYSCOMMON.][SYSEXE]DECW$STARTLOGIN.EXE;1 LOGINOUT Image Termination -------------------------- Username: SYSTEM UIC: [1,4] Account: <start> Finish time: 7-DEC-1989 12:51:12.40 Process ID: 20A000A9 Start time: 7-DEC-1989 12:51:10.45 Owner ID: Elapsed time: 0 00:00:01.95 Terminal name: Processor time: 0 00:00:00.45 Remote node addr: Priority: 4 Remote node name: Privilege <31-00>: 0010E085 Remote ID: Privilege <63-32>: 00000000 Queue entry: Final status code: 00000000 Queue name: Job name: Final status text: <no text> Page faults: 348 Direct IO: 8 Page fault reads: 38 Buffered IO: 9 Peak working set: 436 Volumes mounted: 0 Peak page file: 1529 Images executed: 0 Image name: LOFTI$DKA0:[SYS16.SYSCOMMON.][SYSEXE]LOGINOUT.EXE DETACHED Process Termination ---------------------------- Username: SYSTEM UIC: [1,4] Account: <start> Finish time: 7-DEC-1989 12:51:12.72 Process ID: 20A000A9 Start time: 7-DEC-1989 12:51:10.36 Owner ID: Elapsed time: 0 00:00:02.36 Terminal name: Processor time: 0 00:00:00.74 Remote node addr: Priority: 4 Remote node name: Privilege <31-00>: 0010C000 Remote ID: Privilege <63-32>: 00000000 Queue entry: Final status code: 00000000 Queue name: Job name: Final status text: <no text> Page faults: 416 Direct IO: 8 Page fault reads: 40 Buffered IO: 25 Peak working set: 436 Volumes mounted: 0 Peak page file: 4401 Images executed: 1 | | | ALL SUBMISSIONS BECOME THE PROPERTY OF DIGITAL EQUIPMENT CORPORATION. | ------------------------------------------------------------------------------- |SHORT NAME |MNT. CAT. |MNT. GRP. |XFER. GRP. |PL | PRB. TYPE | | | | | | | | ------------------------------------------------------------------------------- |DATE RECEIVED(MAIL) |DATE TO MAINTAINER |XFER. DATE |LOGGED ON | | | | | | ------------------------------------------------------------------------------- |DATE RECEIVED(ASG) |DATE RECEIVED FROM MAINT. |DATE ANSWERED |LOGGED OFF | | | | | | -------------------------------------------------------------------------------
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1893.1 | BLOCKP::neth | Craig Neth | Mon Dec 11 1989 16:11 | 4 | |
Why do you want to do this? Why doesn't @SYS$MANAGER:DECW$STARTUP "RESTART" do what you want? (BTW, I have no idea why what you seem to be depending on is changed in 5.3-1) | |||||
| 1893.2 | DECW$STARTUP RESTART doen't do it for customer! | GSRC::WALLACE | I bark, therefore I am. -- Descartes dog. | Mon Dec 11 1989 17:14 | 20 |
Re: .1 >>Why do you want to do this? Why doesn't @SYS$MANAGER:DECW$STARTUP "RESTART" >>do what you want? Craig, Thanks for pointing out a shortcoming in the problem description. The reason we can't use @SYS$MANAGER:DECW$STARTUP "RESTART" is that the customer has over 12 connections (over 50 windows) to the server with their application programs. Doing the restart, of course, terminates the connections and the customer's code has to restart; this is not acceptable to the customer (I don't want to discuss the customer's design). Suffice it to say that the customer wants and "instant-on" application after logging in. The issue is, "What has changed between VMS 5.2/DECwindows 1.0 and VMS 5.3-1/ DECwindows 2.0 that precludes the LOGINOUT program from successfully completing?" Thanks for the quick reply. The problem is still open. Richard | |||||
| 1893.3 | DECWIN::JMSYNGE | James M Synge, VMS Development | Tue Dec 12 1989 13:41 | 9 | |
Last time I looked at the session manager code, I noticed that it would
not put up the login window if there were any other clients running.
The reason for this is that it otherwise would be possible to create an
input only window which stole your password.
Can you explain more clearly what it is that your customer is trying to
achieve? If we knew, we might be able suggest some work arounds.
James
| |||||
| 1893.4 | Maybe we can stop the password thief? Ha! | GSRC::WALLACE | I bark, therefore I am. -- Descartes dog. | Tue Dec 12 1989 17:23 | 34 |
RE: .3 James, The goal that my customer is trying to achieve is to have all application code processes and windows up and running prior to anyone logging in. Almost all the windows are unmapped and processes in a wait state except their network processes that are getting data from the rest of their network. These network processes are constantly updating the data structures that the windowing processes use. We have X-window oriented output, PHIGS oriented output, and GKS oriented output. The VR tube at login, as seen by the user, has the banner and username/password windows mapped on top of a VR screen size black window that is covering the other unmapped windows on the tube. The path that the workstation takes at boot time is the "vanilla" boot processes/procedures that are for any as-delivered VMS 3520. The differences are that the SYS$MANAGER:DECW$SYLOGIN.COM has an added line to start one of the application code programs, and the SYS$MANAGER:DECW$STARTSM.COM has the "$run DECW$SESSION" commented out. So there is no session manager running (at least as far as I know of). There seems to be NO PROBLEM with this. The problem is when the user does an application code "logoff" we want to bring back the banner username/ password windows on top of the black window. This is done by doing a $SNDJBC call to put a command file into SYS$BATCH as [1,4] to run SYS$SYSTEM:DECW$STARTLOGIN for the banner username/password; we control the black window from the application code. The point you make about the password being stole has been one of the hypothesis that we've considered. It is one of the "fixes" that we'd like to un-fix. Any help would be MOST appreciated. A solution to this would earn you a dinner at your favorite Digital cafeteria. ;^) Richard | |||||
| 1893.5 | If it wants a terminal, give it a terminal | KELSON::GULDENSCHUH | Success lies in achieving the top of the food chain. | Wed Dec 13 1989 09:31 | 6 |
Try putting the following line BEFORE the "MCR DECW$STARTLOGIN" $ ASSIGN/USER OPA0: SYS$COMMAND $ MCR DECW$STARTLOGIN /s/ Chuck | |||||