Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Finding Patch Level of VMS and various layered products

129 views
Skip to first unread message

KADOW@USOPS.enet.dec.com dtn:297-5349, MR01-1/A65

unread,
May 30, 1996, 3:00:00 AM5/30/96
to

How does one find the Patch level of either VMS or one of the
layered products on VMS?

-thanks, Paul


Mike Rada

unread,
May 31, 1996, 3:00:00 AM5/31/96
to

Generally , ANALYZE/IMAGE <image_name> will do the job for this.


--------------------------------------------------------------------
Mike Rada
Chicago, Illinois U.S.A
E-mail: mjr...@mcs.com
---------------------------------------------------------------------

Brian Tillman

unread,
May 31, 1996, 3:00:00 AM5/31/96
to

In article <960530145...@us1rmc.bb.dec.com>, ka...@usops.ENET.dec.com
says...

>
>How does one find the Patch level of either VMS or one of the
>layered products on VMS?

There's nothing I would call a "patch level" associated with VMS or any of its
layered products. Most ECOs for VMS and its layered products are autonomous.
They can be applied independently. Thus, if you apply an RMS ECO to VMS V6.0
and I apply a SYS ECO, what would you call the patch level for our two
systems.

In VMS there are base releases and point releases (VMS V5.0, V5.1, V5.2,
etc.). One in a while, something called a mandatory update might come out
that appends a dash-number (VMS V5.5-2), but it's still not a patch level.

Similar things can be said about layered products. The closest thing to
"patch level" in a layered product is the image version, which can be found
with ANALYZE/IMAGE, like this:

$ analyze/image sys$system:decc$compiler
<snip>
Image Identification Information

image name: "DECC$COMPILER_PROD"
image file identification: "C V5.2-003"
link date/time: 24-OCT-1995 00:08:32.20
linker identification: "05-13"

Patch Information

There are no patches at this time.
--
-----------------------------+--------------------------------
Brian Tillman | Internet: til...@swdev.si.com
Smiths Industries, Inc. | tillma...@si.com
4141 Eastern Ave., MS239 | Hey, I said this stuff myself.
Grand Rapids, MI 49518-8727 | My company has no part in it.
-----------------------------+--------------------------------


Steve Lionel

unread,
May 31, 1996, 3:00:00 AM5/31/96
to

In article <960530145...@us1rmc.bb.dec.com>,
Paul Kadow <ka...@usops.ENET.dec.com> writes:

|>How does one find the Patch level of either VMS or one of the
|>layered products on VMS?

For layered products, you can do an ANALYZE/IMAGE/INTER on the major product
executable image and look for the image identification string. Some products
do offer some sort of "SHOW VERSION" command or qualifier.

For the operating system, this is much harder, as there is no single "patch
level" - you may have any number of independent "ECO kits" applied. The
description for each ECO kit should identify the images changed and what the
image ident is.

As a Digital internal user, I would advise you to use internal resources for
such questions rather than newsgroups.
--

Steve Lionel mailto:lio...@quark.zko.dec.com
Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"

For information on Digital Fortran, see http://www.digital.com/info/hpc/fortran/

mat...@seqaxp.bio.caltech.edu

unread,
Jun 3, 1996, 3:00:00 AM6/3/96
to

In article <DsA08...@esseye.si.com>, tillma...@si.com (Brian Tillman) writes:
>In article <960530145...@us1rmc.bb.dec.com>, ka...@usops.ENET.dec.com
>says...
>>
>>How does one find the Patch level of either VMS or one of the
>>layered products on VMS?
>
>There's nothing I would call a "patch level" associated with VMS or any of its
>layered products. Most ECOs for VMS and its layered products are autonomous.
> They can be applied independently. Thus, if you apply an RMS ECO to VMS V6.0
>and I apply a SYS ECO, what would you call the patch level for our two
>systems.
<snip>
> Image Identification Information
>
> image name: "DECC$COMPILER_PROD"
> image file identification: "C V5.2-003"
> link date/time: 24-OCT-1995 00:08:32.20
> linker identification: "05-13"
>

I think what the original poster is looking for is something along the
lines of what one finds on an Irix system, where there is a central utility
which keeps track of everything that has been installed on a system and the
various dependencies between them. The ECOs for VMS are not nearly so
interlinked as on Irix and a duplicate of that tool probably isn't needed.

However, it would still be very useful to have access to some tool/service
for determining what versions of what are currently on a system and
which should be loaded onto a system.

For instance, I just upgraded 90% of the software on our Alpha, and had to
manually look through all of the ECOs to see which patches I wanted to
intall and for which products. This was a major pain in the butt, and
turned out to have been not quite adequate (see my recent postings about
bizarre goings on in VMS mail -> the search had failed to turn up that
there is a bug in Pathworks 5.0 which isn't patched until a very recent ECO
and which causes PCSA%"" type forwards to fail.) Ie, one of the few things
I didn't upgrade was Pathworks (since the ONLY function in that we use is
PCSA mail forwarding :-( ), and even if I had upgraded, the most recent
release we had access to didn't have the required ECO incorporated. (Note
that this ECO is not currently on the Digital service web site, or at
least, does not turn up with searches against PCSA or PATHWORKS.)

To eliminate this sort of problem, it would be nice to have acess to a
Digital supplied web page where one could set: model number, target OS
version (6.2, for instance) and list layered software, and it would come
back with a list of versions/patches required to make it all work. Granted
setting this up might be a bit of work for Digital, but it would probably save
them a lot of support costs in the long run, not having to answer so many
support calls asking for exactly the same information.

Secondly, while the PRODUCT tool does keep some records, and so does
VMSINSTAL, it would be nice if this information could all be summarized
quickly for input/comparison with the Web tool envisioned above. That is,
if the Web tool above said that I needed ALPMANA01_062 (which we happen to
have loaded) I would still have to manually do

$ PRODUCT SHOW

and

$ TYPE SYS$UPDATE:VMSINSTAL.HISTORY

to figure out if that was already in place

Thirdly, if this tool was designed properly, a system manager contemplating
an upgrade would be able to:

1. Fire up a web browser on the Digital service page
2. Gather all information required about the proposed upgrades (will it
break existing layered software or hardware, which new versions are
required, etc.)
3. Download and unpack any and all required patches (contracts and disk
space allowing)
4. Download custom instructions on installation order (if it matters,
which ECOs go on first.)

And then do the upgrades. Theoretically, all of this without ever phoning
in for support.

Regards,

David Mathog
mat...@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech

0 new messages