Patch installations

[Wim Van den Wyngaert]

Currently I refuse to install VMS patches without requalifying the applications.

Has anyone had problems with VMS or with (middleware) applications after applying patches on their system ?

Only answer if you had problems ... and only for VMS 6.2 and higher.

Wim

[labadie_1]

Yes of course :-)

The last time, I upgraded to Vms 7.3-2, and after applying SYS V 0100, the boot hanged.

Various boot conversational, startup_p1 to MIN and set/startup=opa0: to no avail

I booted to CD, renamed the culprit file and all was OK.

as they say

After installation of the VMS732_SYS-V0100 ECO
kit, subsequent reboot attempts fail after
SYSINT has created the STARTUP process and
LOGINOUT begins to run. The failure message
is:

Error opening primary input file SYS$INPUT,
Error in device name or inappropriate device type

[Uwe Zessin]

Myself, I didn't have any problems as I no longer work as a system manager, but I will respond anyway.

I have seen reports about patches (SYS, for example) that did break TCPIP(SMTP) or Pathworks/ Advanced Server or, (GULP?!) created an unbootable system.

[labadie_1]

ideally, one should have a dev node, and several test nodes (alpha test, beta test...) and of course similar computers (cpu/model...).

If your test node is an alpha station 500 and the production node a GS 160/320/1280, you may miss some points, because on the test node you can't "stress" enough the application.

But often CFO will refuse to have a similar node...

[Jan van den Ende]

Wim,

after opgrading 7.3-1 to 7.3-2 (latest patches as of mid-july) we had trouble with an application that uses some Progress communications routines (I know, no longer supported but... we depend havily on them, replacement due 2001, but not yet qualified) ) After re-linking the application became available, but didn't communicate with another app, as intended. (which in itself seemed to run OK, and communicates with app #3). Relinking app #2 repaires the communication with #1 (now both working fine, also tohether) but.. no more communication with #3. At this moment I am trying very hard to get the objects or the sources, or have the supplier do a 7.3-2 link (though I believe they are still at 7.1-some).
Until this is satisfactorily solved, we have to remain a mixed-version cluster...


Jan

[John Abbott_2]

I've had a problem with an old basic application which resulted in some unusual screen formatting problems after upgrading vms. There was an "issue" with the Basic RTL (DEC$BASRTL) it's hard to remember exactly what, as it was a long time ago - under vms v6.n. DEC fixed it (we were able to revert back to the previous image until a workaround was in place).

Never any issues with COBOL after vms upgrades, if that helps.

We have had some problems when upgrading pathworks. The patch applies ok but as a BDC we've seen issues communicating with a W2K PDC. In the past we've had to save the shares etc. re-configure pathworks into it's own domain as a PDC and re-introduce it to the W2K PDC as a BDC and re-apply the shares etc. This was logged with support, so my guess is that it *might* be fixed.

I can only add, just double check the patches you download have not been withdrwan or superseded by the time you apply them, we hit this once and had to restore (the system wouldn't reboot) and download the replacement patch.

[John Abbott_2]

Sorry, one more point worth mentioning. Note the order you apply the patches in test and at what point you reboot and stick to this when you roll it out.

Try not to apply too many patches together without rebooting. I've seen someone else apply a whole bunch of patches that resulted in the system being unbootable. When he applied them individually and rebooted there were no problems. I'm sure this was just back luck :-) and I think the bottom line is to go for the UPDATE* kits where possible and reboot each time.

[Uwe Zessin]

Patches that DO REALLY require a boot give out an extra hint and it is good practice to follow them. When it comes to patch order I try to install early issued ones first. They are supposed to have generation numbers with their files and I sometime see that a file is retained from an earlier patch, but OpenVMS has become a terribly complicated beast and one never knows...

[Uwe Zessin]

Oh, my. I am afraid you need to extend your refusal to applications as well:
-----
HP AXPVMS V73_MGMTAGENTS V3.0-36: HP Management Web Server

A current version of TCPIP was found. If you have not enabled SNMP, please
enable it now.

Insert the following lines in SYS$MANAGER:SYSHUTDWN.COM:
@pcsi$destination:[sysupd]wbem_check.com
$ show log pcsi$destination
%SHOW-S-NOTRAN, no translation for logical name PCSI$DESTINATION
$

-----
Of course I can find out where this procedure is really located (SYS$UPDATE:), but it isn't very encouraging if even so simple things are wrong.

[Volker Halle]

Uwe,

yes, I've already reported this problem with V73_MGMTAGENTS V3.0-36 and it will be fixed in a 'future version'.

The WBEM shutdown (WBEM$SHUTDOWN.COM) also won't work if it is not run from SYSTEM (or the account from which WBEM had been started) - also reported.

Some of these 'products' offer mail addresses for feedback and feedback from experienced system managers (including a suggestion for a solution), seem to be welcome.

Regarding the generic question about problems after patch installations, there is no generic answer. If you want to be sure (as 'sure' as you can get), try to test your application(s) after each patch installation on an appropriately configured test system.

Volker.