HP3000-L Archives

June 1998, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Doug Werth <[log in to unmask]>
Reply To:
Doug Werth <[log in to unmask]>
Date:
Wed, 24 Jun 1998 09:44:11 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
Christian Lheureux <[log in to unmask]> wrote:
>Hi fellow listers !
>
>As far as I remember, MPE version numbering scheme is not THAT cumbersome.
>There are some basic rules. We'll deal exclusively with MPE/XL and /iX. MPE
>V/E versions were not that different, just less compliant with their own
>conventions.

<snip long discussion on how to decode the MPE version number>

Christian,

I would have to argue that it most certainly IS that cumbersome. If it
weren't then there would have been no need for you to write a manual about
it.  /include art.bahrs.hehehe

Another point that Stan didn't mention (but has brought up many times in the
past) is that NONE of these numbers match up with what is on HP ESC
concerning bug fixes. There are other issues including:

- It's absurd we should have to maintain/document my powerpatch version with
a string in SYSGEN. MPE will update the Release number but not the user
version during an Update.

- The user in question showed a RELEASE A.00.00 and User version the same.
For Release 4.0 it should say B.40.00  I believe this to be a butchered
install as it does not match up to any releases documented in the
Communicator. (Even Release 1.0 was A.02.00)

- Applied patches are documented in a flat file that can easily be purged,
or worse, overlaid with an older copy.

In reality, whether or not it is easy to decode the version number is not
the issue. Consistency is the issue. Users need be able to easily and
effectively discern the MPE version in whatever terms help to solve their
problem.

Doug Werth                                     Beechglen Development Inc.
[log in to unmask]                                       Cincinnati, Ohio

The opinions expressed do not necessarily represent the views or opinions
of Beechglen Development. They might, but not necessarily. They represent
solely the opinions of the author.

ATOM RSS1 RSS2