- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- virtcfb for VMS 8.x
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-26-2009 08:45 AM
тАО01-26-2009 08:45 AM
virtcfb for VMS 8.x
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-26-2009 09:05 AM
тАО01-26-2009 09:05 AM
Re: virtcfb for VMS 8.x
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-26-2009 09:20 AM
тАО01-26-2009 09:20 AM
Re: virtcfb for VMS 8.x
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-26-2009 12:36 PM
тАО01-26-2009 12:36 PM
Re: virtcfb for VMS 8.x
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2009 04:15 AM
тАО02-04-2009 04:15 AM
Re: virtcfb for VMS 8.x
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2009 04:21 AM
тАО02-04-2009 04:21 AM
Re: virtcfb for VMS 8.x
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2009 05:20 AM
тАО02-04-2009 05:20 AM
Re: virtcfb for VMS 8.x
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2009 08:20 AM
тАО02-04-2009 08:20 AM
Re: virtcfb for VMS 8.x
(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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2009 09:03 AM
тАО02-04-2009 09:03 AM
Re: virtcfb for VMS 8.x
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2009 09:11 AM
тАО02-04-2009 09:11 AM
Re: virtcfb for VMS 8.x
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