Question PROD on 8.2

[Steven Schweda]

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

[Ian Miller.]

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

[Willem Grooters]

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)

[Ian Miller.]

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.

[Steven Schweda]

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.

[Willem Grooters]

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

[Steven Schweda]

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.

[Willem Grooters]

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

[Willem Grooters]

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.