HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Evaluating Patches

 

Evaluating Patches

Does anyone know of a document that correlates the patch names to the module('s) affected? Additonaly does anyone know of a document that provides an overview of the modules and their function.

We read the release notes and pass on the info to our developers and QA. It would be helpful if more specific info could be supplied as to the effect of the patch being applied

Thank you
2 REPLIES
Dave Gudewicz
Valued Contributor

Re: Evaluating Patches

Usually the ECO Cover Letter includes what modules/images are affected by installing the particular kit.

As far as an overview of the modules is concerned, I'd start by looking through the VMS Doc. set.

Dave...
Hoff
Honored Contributor

Re: Evaluating Patches

I am aware of no similar document available outside of HP OpenVMS Engineering.

You can construct your own local version of the image-level information, using the PCSI PRODUCT commands to extract the contents of the ECO kits, and cross-indexing these images with the information from the OpenVMS source listings. From that, you can work upwards to user APIs in some areas. Other images can and will have affects throughout the system environment, and won't have a single or visible user API associated with the API. Errors and changes within the modular executive images and within many of the core device drivers, for instance, can manifest themselves most anywhere in the environment.

If you're tracking back to what OpenVMS Engineering calls the source module level, then you'll definitely need access to internal HP details; that level of detail is not particularly available outside of HP. These source modules are the starting point for building or rebuilding OpenVMS itself, and you'll see listings of most of these on the source listings distributions.

I'd tend to look at the DEC test manager (DTM) or other such, and work on evaluating the application itself. With large applications, this can involve integrating debugging and testing support -- even if it's as simple as suppressing the details of the dates or the PID values or other such details that can through off DTM-level comparisons -- can be quite useful. For many applications, a DTM test suite can be used periodically and potentially even automatically. From the DTM suite, direct testing of the application and indirect testing of the ECOs...

Not the answer that you want, I expect.