Excursion windows - how can one stop a user from closing via the top right hand X

[J Asson]

We have a mission critical application on VMS and use eXcursion as the interface to same.

The issue we have is that sometimes the users hit the big X in the top right hand corner and close a window (actually just a decterm) and the result is that some applications can no longer output to that device.

I was wondering (and I am not a programmer but can pass this onto folks more in the know) if the use of the X can be ignored via coding or not ?

Cheers
John Asson from Sunny Queensland Australia

[Hein van den Heuvel]

Obviously there is nothing OpenVMS can do to stop the user from tellign Windoze to kill a window. That output will stop.

However, you may be able to proserve the OpenVMS process for re-connect. That would require a concept called 'virtual terminal on VMS. Not sure you can get those directly from excursion (probably). If not, an intermediate SET HOST could do the trick

Google for: +openvms +"virtual terminal"

http://h71000.www7.hp.com/wizard/wiz_7980.html


hth,
Hein van den Heuvel

[Hoff]

As Hein writes, OpenVMS can do nothing about what the remote operating system might allow. The big red X is a Microsoft Windows thing, after all.

Poke around in the land of Microsoft Windows, and see if you can find a way to remove the decoration from the particular Window. It might or might not be feasible.

The application itself can detect the window has gone away, but that's a code change.

Details on setting up IP virtual terminals with TCP/IP Services are in the FAQ, too. ("How to enable telnet virtual terminals?" www.hoffmanlabs.com has the FAQ. See below for the text from this section.)

I might well select a different terminal emulator, and at how the server brings up the display, too. eXcursion works; there are simply various other ways to connect into an OpenVMS host other than DECterm via DECwindows via eXcursion.

Stephen Hoffman
HoffmanLabs

--from the FAQ--

To enable virtual terminal support for telnet and
rlogin devices, add the following logical name
definitions into SYLOGICALS.COM:

$ DEFINE/SYSTEM/EXECUTIVE TCPIP$RLOGIN_VTA TRUE
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNET_VTA TRUE

See SYS$STARTUP:SYLOGICALS.TEMPLATE for details on the
typical contents of SYLOGICALS.COM.

In SYSTARTUP_VMS.COM, ensure that a command similar to
the following is invoked:

$ SYSMAN IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE

In MODPARAMS.DAT, add the following line or (if already
present) mask the specified hexidecimal value into an
existing TTY_DEFCHAR2, and perform a subsequent AUTOGEN
with an eventual reboot:

TTY_DEFCHAR2 = %X20000

This value is TT2$M_DISCONNECT.

On older TCP/IP Services-versions prior to V5.0-you
will have to perform the following UCX command:

$ UCX
UCX> SET CONF COMM/REMOTE=VIRTUAL

[Colin Butcher]

Many years ago I designed a family of real-time control systems which use DECwindows as the interface. I don't have access to the startup code these days, but I do remember that it was possible to auto-start the entire user interface without having anyone log in to the VMS system and without having all the usual Motif Session Manager stuff active.

I think we just had the Window Manager bits. I also managed to prevent anyone from doing things like starting a DECterm, unless they knew a very specific key sequnce. It was also possible to disable the "file > exit" type stuff on the windows, so the only way an X window would die wuold be under the control of the main application.

There was lots of poking around in the DECwindows startup files, setting a few key values in command files, and quite a lot of changes to the assorted DECwindows / Motif resource files.

I don't think you'll be able to prevent anyone stopping the Excursion X display server at the PC end (maybe you can lock down the PC account enough to do that - I've not tried).

It would be an interesting experiment to use the Excursion X display server rather than a local display and see if all the auto-startup stuff would work and if that would solve your problem.

Cheers, Colin (www.xdelta.co.uk).

[John Gillings]

John,

Virtual terminals will solve your immediate issue (" the result is that some applications can no longer output to that device."). They'll be able to output to the device for the timeout period. For your purposes, I'd guess the default timeout of 15 minutes is probably inadequate. You'll need to adjust the SYSGEN parameter TTY_TIMEOUT. It can be raised to very high values. Just a few caveats...

1) Make sure your users are told about the new prompt they may see when they login asking if they want to reconnect to a disconnected session. In general they should just accept the default (hit return).

1a) If users DON'T reconnect, creating a new session, and you have a high timeout, you will accumulate disconnected sessions, and may hit MAXPROCESSCNT or other system resource limits.

2) If multiple users login to the same username, be aware that they may pick up someone else's session

3) If a screen based application is running on the disconnected session, you should issue a ^W (refresh) to repaint the screen.

4) Output sent to the terminal while it is disconnected is lost.

(with a bit of ingenuity, you may be able to set up a "watchdog" type process that detects if the X terminal has gone, and restarts it automatically)