From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 11-OCT-1990 18:27:01.28 To: MRGATE::"ARISIA::EVERHART" CC: Subj: re: Three questions... Received: by crdgw1.ge.com (5.57/GE 1.73) id AA06786; Thu, 11 Oct 90 18:12:02 EDT Received: From VENUS.YCC.YALE.EDU by CRVAX.SRI.COM with TCP; Thu, 11 OCT 90 06:36:04 PDT Received: from BULLDOG.CS.YALE.EDU by Venus.YCC.Yale.Edu; Thu, 11 Oct 90 09:26 EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Thu, 11 Oct 90 09:20:37 EDT Received: by lrw.UUCP (DECUS UUCP w/Smail); Thu, 11 Oct 90 09:04:34 EDT Date: Thu, 11 Oct 90 09:04:34 EDT From: Jerry Leichter Subject: re: Three questions... To: INFO-VAX@KL.SRI.COM Message-Id: <9010111320.AA26495@BULLDOG.CS.YALE.EDU> X-Vms-Mail-To: IN%"mdchaney@bronze.ucs.indiana.edu",INFOVAX X-Envelope-To: info-vax@kl.sri.COM 1. In VWS, we've found that if the process attached to a window dies or is stopped, the window is impossible to delete without rebooting the workstation. Is that really true. We can't figure it out. This is a known bug in VWS V4.2. There's another manifestation of the bug: If you log out of a process with subprocesses, the window may also stick around in the same way. In this case, you can sometimes clean things up by deleting the subprocesses. The best way to avoid the problem is to avoid deleting processes! You MAY be able to avoid it entirely in a different way: If you look in the VWS startup file (SYS$MANAGER:STARTVWS.COM), you'll find a section "Start emulator process if necessary". In earlier versions of VWS, this was executed by default. Now, it is skipped by default; but there is a logical you can define that will cause it to be executed. All it does is create a process named VWS$EMULATORS. (For the curious: A VWS VT terminal emulator window is managed by code that runs as a kernel-mode thread in some process. Prior to V3.something of VWS, this kernel-mode thread ran in the first process to touch the window. For a login process, for example, this would normally be the top process in the job tree. I/O to the window in the process that was running the kernel-mode thread simply calls into the thread. I/O from any other process has to pass the information over to the process running the thread, then do a process swap. The direct calls are, for obvious reasons, faster and are preferred. The original approach ran into problems in clusters: If Hold Screen was hit, the kernel-mode thread could be blocked. If the process running the thread were holding some important lock - e.g., if you were logging in and you hap- pened to hit Hold Screen while LOGINOUT had a lock on SYSUAF.DAT - it had no way to release it, since it was blocked in kernel mode. This could lead to cluster crashes. There was a short-term fix which modified Hold Screen to release its lock after a short time (like 30 seconds); but this was not an acceptable solution. It was replaced by the VWS$EMULATORS hack. The VWS$EMULATORS process, if it exists, becomes the owner of ALL the kernel-mode threads. This means that ALL processes must use the indirect, higher-overhead method of doing I/O to terminal windows; but it also means that the process that might get blocked in kernel mode is never the one that might hold some important lock. In VWS 4.2, the mechanism was changed again (I don't know exactly how) to allow the VWS$EMULATORS process to be "retired". Once again, under normal conditions the kernel-mode thread runs in the first process that touched the window. Unfortunately, the logic isn't quite right, and there are situations in which the kernel-mode thread does not get called at the right time, or just plain doesn't clean up properly. The result is the dead windows you see on your screen.) VWS V4.3 is out there - anyone know if this problem has been fixed. 2. I have a little program that uses UIS (the VWS graphics stuff) to do some funky pictures. However, if I try to do a big one, it get the "exceeded quota" error. That process then locks up, while sucking the CPU in Kernal mode, and both that window and the graphics window that it created are in the state that I asked about in question 1. What's wrong? Stop/ID and ForceExit have no effect. Some quota is too small! VWS is very closely integrated with VMS, and has always had a problem recovering from various quota problems. In early versions, running out of quota tended to crash the system. There have been major improvements over the years; these days, you usually just lose the process involved. Obviously, you've found another failure mode - a more unfortunate one at that. Try using SHOW PROCESS/QUOTA or ANALYZE/SYSTEM to figure out which quota the process is running out of. (There are many possibilities; I won't even try to guess.) Then increase that quota for the affected processes. 3. Finally, I can create a subprocess that communicates with the main process through a mailbox. I'd like to be able to create one, that, perhaps does DCL commands. The problem is, although output lines are sent to the mailbox, prompts seem to be lost. I know it is possible, because things such as "set host" work. What do I need to do to get prompts, etc? Prompts are written using a "read with prompt" modifier to the read operation of the terminal driver. The mailbox driver doesn't support this modifier, so the prompt is ignored. It's impossible to do what you want using the mailbox driver. (Even if you got around the prompting problem, there would be others. For example, DCL ignores end-of-file from a terminal, but if it gets it from some other device, like a mailbox, it logs out.) What you need is a pseudo-terminal driver. There has been one available from DECUS for years; there are multiple net sources (though off-hand I can't point you to one). Actually - surprise - you have one on your system: The VWS TEK4125 emulator uses the TJ/PZ pair of drivers, where TJ is the "terminal" side and PZ is the "control" side. I'm pretty sure this is the DECUS driver under another name. (The same driver is also used for ALL terminal emulators in DECWindows.) -- Jerry