virtcfb for VMS 8.x

[SDIH1]

Hi,

On freeware CD 5 the virtcfb kit is available.
This doesn't work on Itanium of course, and also not on Alpha 8.3.

Does anyone know if this kit is available somewhere for more modern versions of VMS, or
maybe a(nother) port of xvfb to OpenVMS?

I have been testing the ported x11vnc server for OpenVMS, and found that it only works with an actual keyboard and mouse attached, and only on a system with an actual graphics device, using decw server 0.

With a virtual mouse/keyboard/display it would even be possible to run (multiple) vnc servers and decw sessions on a box without any Human Interface Devices.

Regards,
Jose Baars

[Hoff]

This is a discussion probably best held directly with OpenVMS Engineering and specifically with the DECwindows folks. Fred Kleinsorge would be an initial contact here at HP; Fred provided the VIRTCFB submission.

There was no newer version of the VIRTCFB pieces contributed to the Freeware up through Freeware V8.0.

There was a VNC port that was contributed but that was not included in the Freeware for reasons not germane here. That and other VNC ports are around; Google will show some potential available options. TightVNC was the first one that popped up in the search, but there are others.

[SDIH1]

Hi,

As far as I know and can find in Google is the x11vnc one is the only one working on OpenVMS. The other not completely irrelevant hits are for the vnc viewer.

I'll try to get in touch with OpenVMS engineering using support channels.

Regards,
Jose

[Hoff]

Do you specifically need VNC?

Or does a remote serial (or network) console connection work?

VNC is a thing that PC boxes tend to use, but OpenVMS can be effectively and fully managed from a serial console connection via terminal server. (Some would say the lack of a management GUI is a problem.)

As for management alternatives, there's the OpenVMS Management Station (OMS) package around.

And the Itanium management processor (MP) has capabilities in this area.

[SDIH1]

No, I don't specifically need VNC, it's one of the possible solutions to have an X application behave over a bad and slow network.

Running it over an SSH tunnel is another, easier, solution but this proves to have too much overhead (probably on the workstation side) due to the encryption/compression to not have adverse effects on performance at places where the network is performing reasonably well.

[Robert Gezelter]

Jose,

Perhaps I am missing something.

Why is a remote X-windows station not a solution if the goal is to simply run some X-windows applications?

There are a variety of X-windows clients that connect quite happily to OpenVMS.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

You've not indicated what particular problem or situation or requirements that you're looking to address through the use of VNC or X Window or ssh or such. Please consider providing some background.

OpenVMS can be and usually is managed from the command line. This can involve ssh or the rather less secure telnet and other relatively low-bandwidth connections.

If the network latency is poor and/or the network error rates are high and/or the network bandwidth is low, then you're going to have to address that first, or you're going to have to go to a more batch-oriented model for operations. A more batch-oriented approach uses local displays and operations, and pushes and pulls the files to and from the target box as required.

It might be the case that an IDE can help (one particularly with a batch back-end for hauling files; I've not checked NetBeans for that, but there may well be one of these around), or hauling files over with sftp or such and then editing locally.

This could also use a local OpenVMS box or such. Work on and test locally, then transfer and install the bits; treat the box as an embedded controller.

If it's interactive access you need, that's all on the quality of the network. And that means you need to look at more autonomous management. That could well be an embedded controller or such. Or evaluate the whole installation. If the box is going to Mars, for instance, then the system and the design and the network considerations will differ.

But again; some background on your goals (and not the proposed solutions), please?

[SDIH1]

Ok, the situation is simple: an X application
(end user, not management) running on an OpenVMS IA64 cluster that is graphically rather demanding is supposed to run on a number of remote workstations at various locations, at distances up to 200 km. Most of the network has proven to be inadequate to support this, due to latency and network errors. Observed behaviour is appallingly slow or unreliable screen updates, and erratic mouse movement response.
The network will be upgraded in due course (6-8 months), but in the meantime it would be nice to have whatever means to make this X application at least functional. At the moment at a number of locations it is not.

In the long run use of proxies like NX is considered, and in the even longer run redesign of the application to a client/server like architecture has been proposed.

[Hein van den Heuvel]

Long distance X has been performing well for me, but that's just for Oracle installs and such. Hardly graphics intense.

Just now, working in St'Louis on a system at home in Nashua, it seemed better to remote desktop back home, and run the applicaiton over there.

Have you explored the option to do the X locally on a (virtual) desktop and connect from a distance using an other protocol like RDP, Citrix, VNC or whatever you have for that. Note, I don't pretend to understand much of this, just suggesting some possiblem alternatives.

Hein.

[Robert Gezelter]

Jose,

If packets are being lost/corrupted, there is not much that can be done.

The X protocol has reasonable performance on even fairly low speed links (in the old days, 9.6kbps was not unusual).

However, if there are drop-outs, then the retransmits on the TCP stream will be a challenge.

Much more information is needed, but if the circuit is poor, it might be wise to change the various network related parameters. Today, most IP stacks presume a fairly good underlying network. Such was not the case in the past, and the parameters to adjust this exist, although they are not adjusted so often.

Before going too far, careful study with a network sniffer (e.g. WireShark) is highly recommended. As an example, in those old days, it was not uncommon for an increase in packet size to disproportionately increase the likelihood that a packet would require re-transmission.

- Bob Gezelter, http://www.rlgsc.com