1751972 Members
4532 Online
108783 Solutions
New Discussion юеВ

Evaluating Patches

 
Douglas Fisher
Advisor

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 2
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.