TCPIP Service ECO5

[The Brit]

A couple of days ago I received notification that ECO5 had been released for TCPIP Services. I went to ftp.itrc.hp.com and navigated to

openvms_patches > i64 > layered_products > i64,

But the kit was not there.

All of the other ECO's are there (1 - 4), but ECO 5 is not there. Am I looking in the wrong place, or am I just jumping the gun ??

Dave.

[Oswald Knoppers_1]

It is over here:

http://www13.itrc.hp.com/service/patch/patchDetail.do?BC=main|search|patchDetail{HP-I64VMS-TCPIP-V0506-9ECO5-1,{openvms:i64:8.2,}}|&patchid=HP-I64VMS-TCPIP-V0506-9ECO5-1&sel={openvms:i64:8.2,}

[The Brit]

Yes, I've been there. However I dont like the added complication of downloading to an intermediate system and then ftpin' over to my cluster. I would much rather ftp directly to the destination machine.

So I was hoping that it was available somewhere on the itrc FTP server.

Dave.

[Steven Schweda]

"ECO5" for _what_, exactly?

tcpip show version

> [...]{openvms:i64:8.2,}[...]

There's something called

HP-I64VMS-TCPIP-V0506-9ECO5-1.ZIPEXE /.txt

under

ftp://ftp.itrc.hp.com/openvms_patches/i64/V8.2/

too.

TCPIP versions are tied so closely to VMS
versions these days that finding it among the
OS things instead of layered_products should
not amaze, I claim. Of course, a little
consistency might be nice, too.

[Jan van den Boogaard_1]

Strange days...

The patches directory for 8.2 Alpha has a file called
".DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE" while V0506 is coupled to 8.3.

The patches directory for 8.3 Alpha has no TCPIP patch anymore (not even ECO4).

This directory also has files with datetimestamps in the future.

[labadie_1]

I still miss the australian ECO site (no longer updated), which was a model for finding easily a patch, find which patch contained the latest image for anything...

It was a model of ergonomy, so HP shut it, and kept the worst site.

Have a look to
http://ftp.hp.com.au/

ECO Indexes
» Chronological Index
» Indexed by Version
» Indexed by Rating
» Alpha Indexed by Name
» VAX Indexed by Name
» On Hold List

:-(

[The Brit]

I hate to say this, but it looks like this is another example of how loose the OpenVMS patching service has become in recent years.

In the alerts e-mail, the ECO is list as

Products: Open VMS i64 8.X patch.

and under description,

Kit Applies To: OpenVMS Integrity Server V8.2

So I am forced to ask - Is this OK for OpenVMS 8.3-1H1 bladeservers??

Dave

[Volker Halle]

Dave,

another warning: the TCPIP V5.6 ECO 9 kits for OpenVMS Alpha and OpenVMS I64 seem to have been re-released as evidenced by the entries in the DECUServe ECO notes file:

http://eisner.decus.org/DECUServe/DECnotes/ECO/2658/SDIR.HTML

Volker.

[Graham Burley]

> http://eisner.decus.org/DECUServe/DECnotes/ECO/2658/SDIR.HTML

A better/preferred URL for this is:
http://decuserve.org/anon/htnotes/dir?f1=ECO&f2=2658.*

[Colin Butcher]

Hi,

You'll find these latest TCPIP ECO05 kits available by FTP at: ftp.itrc.hp.com/openvms_patches/alpha/V8.2
and: ftp.itrc.hp.com/openvms_patches/i64/V8.2

This breaks established conventions whereby we're previously seen them in the layered_products directory tree. I have to agree - it's another example of how the process of distributing patches has become too sloppy.

Over the past 2 years or so we've seen far too many patch kits being re-issued to fix things or update things - without the necessary rigour being applied to file naming, file locations, version numbering and documentation.

Can we please stick with established conventions, unless there's a really good reason to make changes.

Bear in mind that many of us work in environments where reliability and stability are the things that matter, so we have appropriate (and sometimes over-the-top) processes and procedures to follow before we put new versions and patches into service on production systems. For example, you can't just toss a patch into service on a major finance data system, or a national healthcare system, or an air traffic control systems.

Careless errors in patch kits and changes to the way that patches are published cause us a lot of unnecessary work and annoyance, which in turn leads to the businesses that run these systems becoming annoyed by it as well - which is bad for all of us.

Cheers, Colin (http://www.xdelta.co.uk).