pengo@tmpmbx.UUCP (Hans H. Huebner) (01/24/88)
Hello,
I hope this is no RTFM-kind of problem. It could either be a problem with
VWS or VMS in general.
I'm using a VAXStation II/RC with VWS V3.2 and MicroVMS V4.5b. VWS looks
nice to me so far, but I'm missing features like a setup-file, which saves
me from opening and repositioning four windows every time i log in.
The obvious solution i found was to write a DCL procedure, which assigns
channels to WTA0: for each terminal window i need. I intended to SPAWN
processes onto each window. To archive this, i need to know the name of the
created window, since WTA0: is only a template device. I haven't been playing
around with these template devices so far, but in my understanding i get a
new pseudodevice if i assign a channel to the template (i.e. a X.29
terminal with VAX PSI, a new window with VWS, a new pseudo tty with the pty
driver etc..). It would now at least be logical if DCL remembered the name
of the created device. Unfortunately the logical name which identifies the
opened file translates to "_TMPMBX$WTAx", where x is a number which doesn't
get used for a created terminal. For example, if i have one window on my
screen (WTA1:), and open WTA0: to create a new window, the logical of the
opened window translates to _TMPMBX$WTA2:, but WTA2: doesn't exist. The
*real* name of the new window is WTA3:. This looks at least strange to me.
Furthermore, if i open a second channel to WTA0:, the logical name again
translates to _TMPMBX$WTA3, and the device is named WTA4:.
Can anyone here explain what's going on or give me another hint on how to
set up the VAXStation without having to fiddle with the mouse endlessly ?
I'd also be interested in knowing if it's normal that VWS crashes sometimes ?
My machine Bugchecks frequently if I click in the upper right corner of the
screen. Just curious ;-)
By the way, does anyone have a version of SLIP running on VMS ?
Thanks for any hint,
Hans
(Please use the domain-address in my signature for replies, tmpmbx isn't
registered yet)
--
Hans H. Huebner, netmbx | Telex: 186672 net d
Woerther Str. 36 | DOMAIN: pengo@netmbx.UUCP (sigh)
D-1000 Berlin 20, W.Germany | ..!{{pyramid,unido}!tub,altger}!netmbx!pengo
Phone: (+49 30) 332 40 15 | BITNET: huebner@db0tui6LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (01/27/88)
I'm using a VAXStation II/RC with VWS V3.2 and MicroVMS V4.5b. VWS looks nice to me so far, but I'm missing features like a setup-file, which saves me from opening and repositioning four windows every time i log in. The obvious solution I found was to write a DCL procedure, which assigns channels to WTA0: for each terminal window i need. I intended to SPAWN processes onto each window. To archive this, i need to know the name of the created window, since WTA0: is only a template device. I haven't been playing around with these template devices so far, but in my understanding i get a new pseudodevice if i assign a channel to the template (i.e. a X.29 terminal with VAX PSI, a new window with VWS, a new pseudo tty with the pty driver etc..). It would now at least be logical if DCL remembered the name of the created device. Unfortunately the logical name which identifies the opened file translates to "_TMPMBX$WTAx", where x is a number which doesn't get used for a created terminal. For example, if i have one window on my screen (WTA1:), and open WTA0: to create a new window, the logical of the opened window translates to _TMPMBX$WTA2:, but WTA2: doesn't exist. The *real* name of the new window is WTA3:. This looks at least strange to me. Furthermore, if i open a second channel to WTA0:, the logical name again translates to _TMPMBX$WTA3, and the device is named WTA4:. This is really a long-standing DCL bug. What happens is that DCL, in the process of opening a file, ends up assigning channels to it twice. Eventually, it will use the FIRST assignment to create the logical name it gives you, then close that channel and use the second one. For everything but template devices, this causes no problems. For template devices, it ends up creating TWO of the device, destroying one, and handing you a pointer to the WRONG one. There is no workaround strictly with DCL. However, it's simple to write a small program that creates a terminal with a call to UIS$CREATE_TERMINAL and assigns a logical name to point to it. (You can't use the cloned device facility here either - as soon as your program exits, the channel it opened to create the cloned device will go away, and with it the device. Of course, you could also do the SPAWN within the program.) I'd also be interested in knowing if it's normal that VWS crashes sometimes ? My machine Bugchecks frequently if I click in the upper right corner of the screen. Just curious ;-) VWS crashes are almost always the result of running out of some resource or another. Actually, VWS has been getting MUCH better behaved of late. It used to crash on almost any resource problem. Now, most of them (at worst) delete the current process. I posted a set of parameters that have worked for me a couple of days ago. Here they are again: MODPARAMS.DAT: ! ! Local modifications: Set up for LAT by using only the username in the ! breakin database, and make LT's disconnectable by default. Go for a big ! WSMAX. Allocate more type-ahead. Allocate more paged pool to compensate ! for the increase QVSS_POOL_SIZE. Allow more global pages and sections ! - we were running low. ! LGI_BRK_TERM = 0 TTY_DEFCHAR2 = 135170 WSMAX = 8192 TTY_TYPAHDSZ = 508 ADD_PAGEDYN = 500000 ADD_GBLPAGES = 3000 ADD_GBLSECTIONS = 50 Probably only the last three have any relevence to VWS. In SYSTARTUP.COM, before the call to STARTVWS: $ define/system/exec UIS$QVSS_POOL_SIZE 1000000 I've actually configured a lot more page and swap file space than AUTOGEN recommends: Paging File Usage (pages): Free In Use Total DISK$MICROVMS:[SYS0.SYSEXE]SWAPFILE.SYS 4736 5664 10400 DISK$MICROVMS:[SYS0.SYSEXE]PAGEFILE.SYS 19121 3871 22992 BTW, this is a 10 Meg MicroVAX II with an RD53. -- Jerry -------
kvc@nrcvax.UUCP (Kevin Carosso) (01/27/88)
In article <52@tmpmbx.UUCP> pengo@tmpmbx.UUCP (Hans H. Huebner) writes: >processes onto each window. To archive this, i need to know the name of the >created window, since WTA0: is only a template device. I haven't been playing >around with these template devices so far, but in my understanding i get a >new pseudodevice if i assign a channel to the template (i.e. a X.29 >terminal with VAX PSI, a new window with VWS, a new pseudo tty with the pty >driver etc..). It would now at least be logical if DCL remembered the name >of the created device. Unfortunately the logical name which identifies the >opened file translates to "_TMPMBX$WTAx", where x is a number which doesn't >get used for a created terminal. For example, if i have one window on my >screen (WTA1:), and open WTA0: to create a new window, the logical of the >opened window translates to _TMPMBX$WTA2:, but WTA2: doesn't exist. The >*real* name of the new window is WTA3:. This looks at least strange to me. >Furthermore, if i open a second channel to WTA0:, the logical name again >translates to _TMPMBX$WTA3, and the device is named WTA4:. This less-than-desireable behaviour is attributable, I believe, to a misfeature in RMS. When you assign a channel to a template device, such as WTA0:, a new device WTAn: is created, where n is increased by one each time (and wraps around at 9999). When you open a device with RMS, it seems to assign more than one channel to the device. I'm not sure why, but perhaps it wants to retrieve device information. In any case, it does it incorrectly since it assigns a channel to the device you gave it (e.g. WTA0:), actually gets a channel to a new device (e.g. WTA3:), does whatever it's gonna do and stores away the name, then deassigns that channel (which causes WTA3: to be deleted) and assigns another one to the template (creating WTA4:). This is all fine, but for some reason it "remembers" the now-useless name of the first device -- this is what shows up in your DCL-opened logical name. I think the fault lies with RMS and not DCL because I remember having the same problems trying to do something like "COPY X.DAT WTA0:" which should create a window on the workstation, throw X.DAT at it, and then delete the window. I think that got me a "no such device" error and when you next create a window you notice that the unit number is 2 greater than before, implying that the RMS open created not one but two devices -- hence I arrived at the scenario I described above. Excuse me if I'm totally offbase here, but it was last summer when I was fooling around with this and I can't try it out right now. This is something that should be SPR'ed. /Kevin Carosso kvc@nrcvax.uucp Network Research Co. kvc%nrcvax@trwind.trw.com kvc@engvax.scg.hac.com kvc@ymir.bitnet