I’ve been doing some research into handling XML (Extensible Markup Language) data on VOS and OpenVOS, and I thought it would be useful to share what I learned with a wider audience.
I’ve been fielding questions from VOS customers who are considering upgrading to OpenVOS Release 17.0 and they are all asking the same question – what’s new, and why should I upgrade?
I recently fielded a question from a VOS customer who wanted to know how to get his shared virtual memory regions to align between his legacy non-POSIX programs and his new, POSIX-based programs.
The information about current releases/versions of the VOS/OpenVOS operating system for V Series and Continuum systems has changed locations on the Stratus web pages.
Your application just detected a critical condition, you can write a message to an application log or even the syserr_log but how do you notify someone right now that the application needs attention?
Unless good records are kept when VOS products are installed, determining the revision of all the products on a module can be a daunting task.
Having the correct time on your module is critical for all kinds of activities including log synchronization and security certificate validation.
In this blog I will address how to determine if enough osl_server_processes are started; in a future blog discuss how to determine if the max_open_servers value is correct for your environment.
This is an updated version of an article that was first posted on November 16, 2010. This version adds several diagrams and covers some additional subtopics.
I recently diagnosed an apparent compiler problem for an OpenVOS customer. He has two modules running OpenVOS Release 17.1.