topic Re: Question PROD on 8.2 in Operating System - OpenVMS

Question PROD on 8.2

Willem Grooters — Sun, 30 Oct 2005 16:10:05 GMT

Installing patches on 8.2 (Alpha) puzzles me...
I have installed patches before, from DAK0 (the system disk, labeled IO_SYS82 and mounted using that logical), and a product on DKA100 (labled as IO_DATA and mounted as such). I remember it complained about a destination disk being not mounted or not having an associeated volume name.
Now I try to install new patches, whatever I do I get the message:

%PCSI-E-OPENOUT, error opening IO_DATA: as output
-PCSI-E-INVSPIDST1, destination device is not mounted or does not have an associ
ated logical volume name
%PCSI-E-S_OPFAIL, operation failed
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition
$

even when I specify "/dest=io_sys82

What do I do wrong?

(The system is cluster member, but with it's own system disk)

Re: Question PROD on 8.2

Willem Grooters — Sun, 30 Oct 2005 16:20:12 GMT

Additional:
After I dismounted all disks form the other clusternode, dismounted IO_DATA from the system itself and remounted it locally, I could start PROD and it gave me the list I expected. However, there is no ALL option (no problem) and the TCPIP patch - that came as an PCSI$COMPRESSED type, could not be processed:

%PCSI-E-READERR, error reading DKA0:[SYSMGR.][install]DEC-AXPVMS-TCPIP-V0505-11E
CO1-1.PCSI$COMPRESSED;1
-RMS-W-RTB, 813 byte record too large for user's buffer
%PCSI-E-OPENIN, error opening DKA0:[SYSMGR.][install]DEC-AXPVMS-TCPIP-V0505-11EC
O1-1.PCSI$COMPRESSED;1 as input
%PCSI-E-S_OPFAIL, operation failed
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition
$

Did I miss something?

Re: Question PROD on 8.2

Willem Grooters — Sun, 30 Oct 2005 16:34:38 GMT

Addition 2:

the TCPIP kit will not install:

$ prod install */kit_attributes=(format=compressed)
%PCSI-E-READERR, error reading DKA0:[SYSMGR.][install]DEC-AXPVMS-TCPIP-V0505-11E
CO1-1.PCSI$COMPRESSED;1
-RMS-W-RTB, 813 byte record too large for user's buffer
%PCSI-E-OPENIN, error opening DKA0:[SYSMGR.][install]DEC-AXPVMS-TCPIP-V0505-11EC
O1-1.PCSI$COMPRESSED;1 as input
%PCSI-E-S_OPFAIL, operation failed
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

Re: Question PROD on 8.2

Alex Daniels — Sun, 30 Oct 2005 19:17:56 GMT

You don't need to manually specify the kit_attributes=(format=compressed)

Just install it like it was a .pcsi

If you still have problems, post the output from including you prod command, but use /trace as well.

Does a 'prod list' of the kit work?

Also checksum the kit and compare that to the release notes.

Re: Question PROD on 8.2

Steven Schweda — Sun, 30 Oct 2005 23:52:14 GMT

> -RMS-W-RTB, 813 byte record too large for user's buffer

I think that I needed to reset the file
attributes on the last compressed PCSI kit I
sucked down. I think that it was for V8.2,
too, but I've lost track. DIRE /FULL. If you
used a Web browser and got Stream_LF, you may
need to set it to fixed-512 (or something).

Re: Question PROD on 8.2

Volker Halle — Mon, 31 Oct 2005 02:36:25 GMT

Willem,

a .PCSI$COMPRESSED kit file needs to be:

Record format: Fixed length 512 byte records
Record attributes: None

Volker.

Re: Question PROD on 8.2

Kris Clippeleyr — Mon, 31 Oct 2005 03:03:11 GMT

Willem,
About the error INVSPIDST1. It means that one of the disks referenced in the PCSI database is not mounted on the system, at least not with the correct LOGVOLNAM. Somehow I think that this is a "feature" of PRODUCT that is not entirely correct. IMHO, PRODUCT should not complain about a disk not being mounted, if that disk does not play part in the operation. If it can access both the source disk (where the .PCSI kit is) and the destination disk (where you want the kit to be installed), it should simply do its job. I stumbled over the same error when trying to extract release notes. I opened a call for it with HP. Let you know what they have to say.
Greetz,
Kris (aka Qkcl)

Re: Question PROD on 8.2

Willem Grooters — Mon, 31 Oct 2005 04:23:43 GMT

Alex:
Makes no difference. I didn't check the checksum yet, will check just to see.
Steven, Volker:
Will try that on the first occasion (may be some days), but it shouldn't have come as such in the first place.

All needed patchkits (when will there come a search-by-DATE....) have been downloaded using the one-zip possibility; the zip has been extracted on VMS, and the regular files (AXPEXE) ran flawlessly and produced usable files (all FIXED 8192, have been installed), just this one was STREAM-LF and caused problems.
I've done this before without problems.

Kris:
The issue might be that the disks were mounted /CLUSTER in this system itself (IO) - both IO_SYS82 (the system disk) and IO_DATA. For IO_SYS82, that one is obviously mounted /SYSTEM originally, probably "promoted" to /CLUSTER; but PROD complained about IO_DATA only.And that as mounted /CLUSTER from the start. On the other cluster node, theer has not been an explicit MOUNT command; it might be that one that caused problems. But dismounting it there only did not help. It was after I dismounted that disk on IO, and mounted it privately, that PROD could get to work.
We'll see what HP has to comment.

Re: Question PROD on 8.2

Karl Rohwedder — Mon, 31 Oct 2005 05:53:20 GMT

Has the disk IO_DATA been copied from one physical disk to another, e.g. DA200->DA100?

Such changes should be registered in PCSI using PROD REGISTER VOLUME.

regards Kalle

Re: Question PROD on 8.2

Volker Halle — Mon, 31 Oct 2005 07:13:05 GMT

Willem,

or did you ever change the volume label on DKA100: AFTER you've installed products on that disk ?

HELP PROD REGISTER VOLUME is worth reading.

Volker.

Re: Question PROD on 8.2

Steven Schweda — Mon, 31 Oct 2005 10:05:37 GMT

Re: Patch kit file attributes

It all seems to depend on your FTP client.
Using (old, fast) Netscape 3, for example, to
suck down a .PCSI$COMPRESSED file leaves a
Stream_LF file, with which PRODUCT can't
cope. I haven't tried this with a newer
browser, but I'd expect a similar result.

Of course, Netscape 3 does not do so well
with a name like "x.PCSI%24COMPRESSED" on
an ODS2 disk, either, but that's easier to
work around.

A simple FTP client is more likely to create
a fixed-512 file for a binary FTP transfer.

Wget since 1.9.1d creates a fixed-512 file
(by default) for a binary FTP transfer, for
what that's worth.

It would be nice if VMS engineering could try
this stuff the way typical users do before
making the big switch. It'd also be nice if
programs like BACKUP and PRODUCT were a bit
less fussy about file attributes.

The Zip-compressed kits do better, but they
seem to be using UnZip 5.42 to make them,
and, as I like to say, UnZip 5.52 is
considerably faster on larger files. It's
more work, but if you have a fresh UnZip it
may be worth the effort to use an explicit
UnZip command rather than run the
self-extracting executable.

Everything's complicated.

And "it's own system disk" should have been
"its own system disk". For details, Google
"Lynne Truss panda".

Re: Question PROD on 8.2

Ian Miller. — Mon, 31 Oct 2005 10:16:52 GMT

when you mounted the drive did you specify the logical name parameter?

Re: Question PROD on 8.2

Willem Grooters — Tue, 01 Nov 2005 03:25:18 GMT

Karl, Volker:
The disk has been initialized IO_DATA, but after I installed VMS on IO_SYS82.
There is just one product installed on that disk - where I had exactly the same problem (and used the same solution). Before installation, I added on directory, for the rest, the disk just contained the usual files. But I will look into the registration.
Nevertheless - this check should only be done if that disk was required in the installation process (source or destination), no matter HOW it was mounted.
Ian:
During startup the next line is executed:
$ MOUNT/CLUSTER DAK100 IO_DATA IO_DATA

After I dismount the disk (on IO) and mount
$ MOUNT/SYSTEM DAK100 IO_DATA IO_DATA

there is no trouble.

Steven,
Download (from VMS) is not the issue.
There were a number of patches to be installed, so on the ITRC patch site I selected the pathes, had them downloaded in one zip file onto a PC (to store them on CD as well), FTP's the file (binary) to VMS and unzipped it there. All files are Ok: AXPEXE's run and PCSI's can be installed - but this one.
I will check what plain FTP would give me (or has anyone else tried that already, then please tell), my thought are it will eb the same. EIther it is the ZIP at HP that introduces the problem, or the file is not correct in the first place.

(When will we get DECNet access??? I think it would solve a lot of issues in this area)

Re: Question PROD on 8.2

Ian Miller. — Tue, 01 Nov 2005 04:48:13 GMT

I have successfully downloaded using ftp via a pc the TCPIP V5.5 ECO1 kit for I64 and alpha.
Both are fine.

I have read somewhere of a PCSI bug to do with how a disk was mounted. Not specifying the logical parameter was the workaround.

Re: Question PROD on 8.2

Steven Schweda — Tue, 01 Nov 2005 09:34:23 GMT

Re: Patch kit file attributes

> Download (from VMS) is not the issue.

Yes, it is. (Well, one of them.)

> There were a number of patches to be installed, so on the ITRC patch site I selected
> the pathes, had them downloaded in one zip file onto a PC (to store them on CD as well),
> FTP's the file (binary) to VMS and unzipped it there. All files are Ok: AXPEXE's run and
> PCSI's can be installed - but this one.

PRODUCT expects (demands?) a fixed-512 record
format for a .PCSI$COMPRESSED kit, and that
long chain of steps you used (badly
described, with the PC in the middle) won't
give you that. ("downloaded in one zip
file"? You mean, "downloaded by some
unknown program on a PC, and Zip-compressed
by some other unknown program on a PC"?)

The other kits were executables, and RUN is
not so fussy about file attributes.

Re: Question PROD on 8.2

Willem Grooters — Tue, 01 Nov 2005 10:22:21 GMT

Steven,
[quote]
("downloaded in one zip file"? You mean, "downloaded by some unknown program on a PC, and Zip-compressed by some other unknown program on a PC"?)
[/quote]

No, just a method SUPPLIED AND SUPPORTED BY HP.

The HP patch site gives you the opportunity to select patches you want to download, and you have the choice in different protocols and formats. File by file, either HTTP or FTP manually (hit the button and wait); FTP can be done "automated" by a sentscript that will do the download (by FTP), or you can decide to retrieve all patches in one .ZIP or .GZ file.
No matter how I do it, I retrieve the files onto a PC - I have no CD-RW on my Alpha to burn them. I've done this from the moment I got this machine, before and elsewhere. I exchange quite a lot of data between unconnected Alpha's, zipping files on one system, passing the zip files on to a PC and passing them onto other VMS systems to unzip on these. Without any trouble - at all.

So:
NO, it's NOT the method used, nor is it ZIP, UNZIP or FTP - none of these used on a PC - and the zipfile itself is fine)
NO, download to VMS is no issue (not used)
YES, it _might_ be the fact that the HP site is HP-UX and not VMS, that causes the problem when ZIPping the files. The ZIP file itself is fine but it's contents is bad.

(The problem would not exist at all if the fiels were stored on a VMS box, that could be accessed using DECNet. But HP seems to forget that there are better solutions than "standard")

Willem

Re: Question PROD on 8.2

Steven Schweda — Tue, 01 Nov 2005 15:06:14 GMT

Ah. Thanks for the details. I normally go
straight to "ftp://ftp.itrc.hp.com/openvms_patches/"
with Netscape 3, so I miss some (most?) of
the excitement of the modern world.

I fear that almost anything other than real
binary FTP to VMS will leave a
.PCSI$COMPRESSED kit with the wrong file
attributes. Thus, you (and most users,
probably) are doomed to do some fiddling on
those kits after download. And installing
directly from an ISO 9660 CD-ROM is similarly
doomed.

You could copy the data to an ODS2 or ODS5
LD pseudo-disk on a VMS system, fiddle the
attributes there, then copy the resulting
disk image back to the PC with the CD writer,
and make a CD from that. (What could be
simpler?)

I suspect that a quick procedure to check
and alter the attributes of all the
.PCSI$COMPRESSED files in a user-specified
directory spec would be more popular,
however, unless you really did want to do the
installation directly from the CD.

Re: Question PROD on 8.2

Willem Grooters — Wed, 02 Nov 2005 05:36:27 GMT

Steven,

In the past I copied files (FTP or HTTP) manually since transferring ZIPs would brake in the transfer, and never had any trouble.
Of course there are several ways to get areound it, but that requirement to 'fiddle around' with the file attributes is pathetic. HP should get things right, not their clients (us).

BACKUP/LOG HPOVMS::PATCHDISK:[732]*.*/since=26-Oct-2005 SMAN:[PATCH.02-Nov-2005]

would be the VMS solution...

Re: Question PROD on 8.2

Willem Grooters — Wed, 02 Nov 2005 06:20:11 GMT

I am considering this a matter for HP to solve, since the problem is not related to the download itself, but to creation of the ZIP file.
Workaround: don't use this option again - or prepare to do some error handling.