Changes to OpenVMS Patch Kit Formats
george.p...@hp.com
for OpenVMS Patch kits. Following is the Customer Advisory that was
released about these changes.
OpenVMS Patch Kit Format Changes
CUSTOMER NOTICE
Description
Changes are being made to the packaging and compression formats used
for OpenVMS patch kits.
Details
The following changes are being made to formats used for OpenVMS PCSI
patch kits and for the compressed files used for shipping kits to the
ITRC patch distribution site and to customers:
· PCSI$COMPRESSED
Patch kits will now be produced as KIT_NAME.PCSI$COMPRESSED files
rather than the usual PATCH_KIT_NAME.PCSI files. The PCSI$COMPRESSED
format uses the PCSI utility's integrated compression capability,
producing smaller files that will conserve disk space on user's
systems. From a user standpoint, there is no difference from the way
PCSI$COMPRESSED files and PCSI files are installed. All PRODUCT
commands can be used and function the same on PCSI$COMPRESSED files as
they do on PCSI files.
· ZIPEXE
OpenVMS patch kit packages have been produced in a variety of formats
- DCX as well as ZIPEXE. Patch kit formats for all supported
versions of OpenVMS are being standardized and will now ship as
self-extracting ZIPEXE packages. When run, the ZIPEXE package will
expand into the PCSI$COMPRESSED installable kit.
· OpenVMS V8.3 and Secure Delivery
OpenVMS V8.3 will include Secure Delivery capability allowing shipment
of digitally signed patch kits. OpenVMS Secure Delivery automatically
ensures that software installed on OpenVMS was not tampered with prior
to installation. When run, V8.3 ZIPEXE package will expand into two
files - the digitally signed PCSI$COMPRESSED installable kit and the
PCSI$COMPRESSED_ESW patch manifest or digital signature file. Both
files will expand into the same directory and must be present in the
same directory at installation time for patch validation to occur.
When the patch kit is installed, PCSI will check for the existence of a
manifest for any kits that are being installed. If no manifest is
found, PCSI will issue a warning and ask if you want to proceed. If a
manifest is found but does not match the kit, the installation will be
aborted. The PCSI database will contain an indication as to whether a
kit used Secure Delivery on installation.
For additional information on Secure Delivery and PCSI, refer to
section "5.2 CDSA for OpenVMS and Secure Delivery" in the "HP OpenVMS
Version 8.3 New Features and Documentation Overview"
These format changes are being implemented immediately. Since patch
kits that are already in production will not be re-manufactured to
update the formats, for a short time, users may see a combination of
PCSI and PCSI$COMPRESSED, as well as DCX and ZIPEXE patch kit formats.
JF Mezei
> versions of OpenVMS are being standardized and will now ship as
> self-extracting ZIPEXE packages. When run, the ZIPEXE package will
> expand into the PCSI$COMPRESSED installable kit.
While I assume this is a done deal which cannot be changed, was there
any consideration that double compression often results in a larger file ?
If you're going to be zipping the package for transport, why generate
PCSI$COMPRESSED packages ?
Also, will there be any way for cross platform extraction from that
ZIPEXE file ?
For instance, if I download from an Alpha and wish to manage the patches
there and distribute the .PSCI files to various other nodes of different
architectures, will there be some tool on the ALPHA to unzip a patch
meant for VAX or that IA64 thing ?
(can the standard ZIP skip over the executable part of a ZIPEXE file and
get to the actual compressed contents ?)
Peter 'EPLAN' LANGSTOEGER
>"george.p...@hp.com" wrote:
>> versions of OpenVMS are being standardized and will now ship as
>> self-extracting ZIPEXE packages. When run, the ZIPEXE package will
>> expand into the PCSI$COMPRESSED installable kit.
>
>While I assume this is a done deal which cannot be changed, was there
>any consideration that double compression often results in a larger file ?
Have you ever tried it? It never resulted in larger files for me so far.
In fact, a ZIPped .PCSI$COMPRESSED file was always smaller than the original.
>If you're going to be zipping the package for transport, why generate
>PCSI$COMPRESSED packages ?
Because after the transport, you keep your kits unZIPped on disk ;-)
And a .PCSI$COMPRESSED files _is_ way smaller, while not losing functionality
(in regard to a .PCSI file). You could also translate them from .PCSI to
.PCSI$COMPRESSED (and vice versa) with standard DCL PRODUCT commands.
And the reason why you download a .ZIP* file and not a .PCSI$COMPRESSED
file is: a) ZIP has checksums and you see easily if the archive is corrupted
b) the VMS attributes and dates are not lost during transfer
btw On VAX there is still no .PCSI$COMPRESSED, and also VMS ECOs are still
VMSINSTALlable. I personally don't think, this will ever change, but I hope.
>Also, will there be any way for cross platform extraction from that
>ZIPEXE file ?
This has never been a problem. It was used in (not only) VMS freeware world
for over a decade now, was then used in other software for VMS world and
has now finally reached VMS engineering. And I thank for that.
>For instance, if I download from an Alpha and wish to manage the patches
>there and distribute the .PSCI files to various other nodes of different
>architectures, will there be some tool on the ALPHA to unzip a patch
>meant for VAX or that IA64 thing ?
>
>(can the standard ZIP skip over the executable part of a ZIPEXE file and
>get to the actual compressed contents ?)
ZIPEXE is ZIPSFX. You can unzip it with your own UNZIP program on any
platform you like (eg. you unpack the IA64 or VAX ECO on your MARVEL) and
you can unpack it on the intended platform without any UNZIP.EXE (because
it is part of the archive file).
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail pe...@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
David J. Dachtera
>
> "george.p...@hp.com" wrote:
> > versions of OpenVMS are being standardized and will now ship as
> > self-extracting ZIPEXE packages. When run, the ZIPEXE package will
> > expand into the PCSI$COMPRESSED installable kit.
>
> While I assume this is a done deal which cannot be changed, was there
> any consideration that double compression often results in a larger file ?
DCX is not real efficient. I believe that's what PCIS uses to make
PCSI$COMPRESSED output. DCXed archives will typically squeeze down
another 33% of the DCX-only size.
> If you're going to be zipping the package for transport, why generate
> PCSI$COMPRESSED packages ?
Because UNZIP can detect a damaged archive, and may ecven be able to fix
it, depending on the dgree/type of damage. DCX has no such provisions.
> Also, will there be any way for cross platform extraction from that
> ZIPEXE file ?
Any version of UNZIP should be smart enough to detect/ignore the SFX
stub prepended to the archive and extract the content, even if the
offsets were not adjusted - UNZIP simply notifies about unexpected stuff
before the archive content was located.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Peter 'EPLAN' LANGSTOEGER
>DCX is not real efficient. I believe that's what PCIS uses to make
>PCSI$COMPRESSED output. DCXed archives will typically squeeze down
>another 33% of the DCX-only size.
DCX has also had big problems with not detecting corrupted downloads.
I often had .PCSI files produced from incomplete downloads without any hint
and wondered why I couldn't install them successfully. It was neccessary
to add an additional step (looking for checksums, extracting release notes
or unpacking the whole .PCSI kit) just to detect the corrupted .PCSI file.
This is no longer neccessary (but could still be done if you're paranoid ;-)
>Any version of UNZIP should be smart enough to detect/ignore the SFX
>stub prepended to the archive and extract the content, even if the
>offsets were not adjusted - UNZIP simply notifies about unexpected stuff
>before the archive content was located.
btw: I once had problems with WINZIP not successfully unpacking archives
where VMS attributes were saved ("-V"). But this is a done deal nowadays...
Wayne Morrison
> "george.p...@hp.com" wrote:
>
>>versions of OpenVMS are being standardized and will now ship as
>>self-extracting ZIPEXE packages. When run, the ZIPEXE package will
>>expand into the PCSI$COMPRESSED installable kit.
>
> If you're going to be zipping the package for transport, why generate
> PCSI$COMPRESSED packages ?
The primary reason why all kits are now starting to appear as
PCSI$COMPRESSED files is because of the new Secure Delivery process in
V8.3. When kits are digitally signed so that they can be later
validated, the process automatically creates as output a PCSI$COMPRESSED
kit with the associated manifest, rather than a full PCSI kit. This
makes packaging (CD/DVD) and transport of the files easier and smaller,
as an added bonus to the security provided by the digital signature.
Because we needed to process all the kits for Secure Delivery anyway,
there was no good reason NOT to compress them at the same time.
Wayne Morrison, CISSP
OpenVMS Security/eBusiness Engineering
Hewlett-Packard Company
george.p...@hp.com
are V8.3 and later kits. Kits for versions prior to V8.3 will not be
signed. The reason for shipping PCSI$COMPRESSED kits for those earlier
versions is so that we can standardize on one packaging format across
all supported versions.
George Pagliarulo
ECO Release Process
OpenVMS Sustaining Engineering
Hewlett-Packard Company
Peter 'EPLAN' LANGSTOEGER
>To reiterate, the only VMS patch kits that will be digitally signed
>are V8.3 and later kits. Kits for versions prior to V8.3 will not be
>signed. The reason for shipping PCSI$COMPRESSED kits for those earlier
>versions is so that we can standardize on one packaging format across
>all supported versions.
...except OpenVAX
(until a newer PCSI utility/ECO comes out for OpenVMS VAX V7.3 and
OpenVMS VAX V7.3 ECOs are then in PCSI instead of VMSINSTAL format)
SCNR
george.p...@hp.com
Dave Froble
Ah, some good news. VAX is to be saved from the PCSI madness.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
bradhamilton
> george.p...@hp.com wrote:
>> Correct. We will never ship VAX PCSI patch kits. Sorry Peter.
>>
>> George Pagliarulo
>> ECO Release Process
>> OpenVMS Sustaining Engineering
>> Hewlett-Packard Company
>>
>
> Ah, some good news. VAX is to be saved from the PCSI madness.
Seeing as how VAX is no longer manufactured, a Pyrrhic victory, eh what?
Dave Froble
In these dark days we take any small victory we can.
Phillip Helbig---remove CLOTHES to reply
<da...@tsoft-inc.com> writes:
> george.p...@hp.com wrote:
> > Correct. We will never ship VAX PCSI patch kits. Sorry Peter.
> >
> > George Pagliarulo
> > ECO Release Process
> > OpenVMS Sustaining Engineering
> > Hewlett-Packard Company
> >
>
> Ah, some good news. VAX is to be saved from the PCSI madness.
There is, of course, PCSI for VAX...
$ product show product
----------------------------------- ----------- ------------
PRODUCT KIT TYPE STATE
----------------------------------- ----------- ------------
DEC VAXVMS DCE V3.0 Full LP Installed
DEC VAXVMS DECNET_PHASE_IV V7.3 Full LP Installed
DEC VAXVMS DWMOTIF V1.2-6 Full LP Installed
DEC VAXVMS FORTRAN V6.6-201 Full LP Installed
DEC VAXVMS RTR V4.2-351 Full LP Installed
DEC VAXVMS TCPIP V5.3-18 Full LP Installed
DEC VAXVMS VMS V7.3 Transition Installed
DEC VMS NS_NAV_EXPORT V3.3 Full LP Installed
----------------------------------- ----------- ------------
8 items found
$ wso f$getsyi("hw_name")
VAX 4000-105A
$
...though for full kits, not patches.
Peter 'EPLAN' LANGSTOEGER
>In article <sfGdnVZw8uSKAZ3Y...@libcom.com>, Dave Froble
><da...@tsoft-inc.com> writes:
>
>> > Correct. We will never ship VAX PCSI patch kits. Sorry Peter.
It expected this of course. But in the case you make OpenVMS VAX V8,
then please change this decision.
>>
>> Ah, some good news. VAX is to be saved from the PCSI madness.
Only in your eyes. I see PCSI as an advantage (think of PRODUCT REMOVE),
but with a sour taste (think of corrupted PCSI database).
>There is, of course, PCSI for VAX...
Yes. Since many years. And your point is?
>[snip]
>....though for full kits, not patches.
Ah, there it is, but:
Wrong. The application developer (or product manager) decides this.
And for OpenVMS VAX ECOs the decision was so far not changed towards PCSI.
But for other products (like TCPIP, DECnet-Plus, ...) there are now (and
since many years) ECOs in PCSI available for VAX (again: not for VMS itself).
And PCSI UNDO PATCH (via recovery data) is also still not available for
OpenVMS VAX as it requires a newer PCSI version than in OpenVMS VAX V7.3
(but a VAXPCSIxx_073 could fix this of course)
-EPLAN
Dave Froble
> In article <ee6ura$8v6$1...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
>> In article <sfGdnVZw8uSKAZ3Y...@libcom.com>, Dave Froble
>> <da...@tsoft-inc.com> writes:
>>
>>> george.p...@hp.com wrote:
>>>> Correct. We will never ship VAX PCSI patch kits. Sorry Peter.
>
> It expected this of course. But in the case you make OpenVMS VAX V8,
> then please change this decision.
>>> Ah, some good news. VAX is to be saved from the PCSI madness.
>
> Only in your eyes. I see PCSI as an advantage (think of PRODUCT REMOVE),
> but with a sour taste (think of corrupted PCSI database).
Well, it's a perspective thing. I'm used to being more aware of the
details of such things. Guess it all started back with RSTS/E V4B,
where we would gen the OS using DOS (the PDP11 DOS, not the MS shit),
and continued through things like VMSINSTAL and such. Yeah, more
handholding, but, I could fix just about anything.
I'm guessing a corrupt PCSI database is fixable, but, from some recent
posts, it appears to be non-trivial, and non-supported.
So, from my perspective, a potentially corrupt PCSI database isn't worth
the convenience.
A bit like windows is a nice user interface, but if it presents a
problem, I can get along just fine with a command line interface. When
DCL is the command line interface, it's even easier to do without the GUI.
Larry Kilgallen
>>In article <sfGdnVZw8uSKAZ3Y...@libcom.com>, Dave Froble
>><da...@tsoft-inc.com> writes:
>>
>>> Ah, some good news. VAX is to be saved from the PCSI madness.
>
> Only in your eyes. I see PCSI as an advantage (think of PRODUCT REMOVE),
> but with a sour taste (think of corrupted PCSI database).
For sufficiently complex product needs, PCSI is not workable. For
instance, LJK/Security creates a username, but PCSI cannot handle
the notion of clusters with multiple system disks. If you use
the PRODUCT REMOVE command to remove LJK/Security from a single
system disk, it will remove that username from SYSUAF even if it
is still in use by LJK/Security installed on other system disks
that share the same SYSUAF. Note also that some security rules
require disabling rather than removing usernames to ensure they
will not be reissued and to ensure that audit analysis will still
be meaningful.
I know of a DEC layered product that did not use PCSI until
certain improvments are made, but there are still improvements
required for PCSI to be viable in all cases.
Steve Matzura
wrote:
>Well, it's a perspective thing. I'm used to being more aware of the
>details of such things. Guess it all started back with RSTS/E V4B,
>where we would gen the OS using DOS (the PDP11 DOS, not the MS shit),
>and continued through things like VMSINSTAL and such. Yeah, more
>handholding, but, I could fix just about anything.
I don't go back quite that far, only to V06C, but my first experience
with VMS being V4.2/4.4, I instantly noticed, and missed, that level
of control and customizability.