Conference vaxaxp::vmsnotes

   I'd raise an IPMT, and let folks putting together the patches know that
   the present use of the patch naming scheme is causing unnecessary
   confusion.  (And this choice of patch names is causing some entirely
   understandable confusion.)  I'm not sure what I'd suggest to replace
   this naming scheme -- a hyperlink on the component images and any
   superceded patch kits is about the only thing I can think of here...

   If the customer is running OpenVMS Alpha V6.2, ALPDRIV04_062 replaces
   SYS$DRDRIVER.EXE -- the driver patches do not appear directly cumulative,
   as one might expect.  The ALPDRIV04_062 patch is not needed on V7.0 or
   later releases.  ALPDRIV04_070 is not related to SYS$DRDRIVER.EXE.

   ALPSYS02_062 includes LOCKING.EXE.  ALPDRIV07_070 -- which has been
   superceded by ALPSYS08_070 -- is not related to LOCKING.EXE fix, and
   does not supercede ALPSYS02_062.

    
    Well the problem with the names is that DEC standard... whatever,
    requires that as part of the name we use the facility that the
    code in the patch comes from. That works fine when you only have
    one image in a facility. But as you see, things like SYS and DRIVER
    get confusing real fast. When someone recommends a patch kit to
    a customer it would be better if they just specify.. Get the latest
    kit for xxdriver, at least xxdrivxx_xxx. By only referencing the
    name of the kit you don't really know that as in this case they
    wanted them to get the latest DRDRIVER. The reason some kits have
    _062 and others have _070, and you will also be seeing _071 is that
    this tells you the highest version supported by the kit. The kit may
    have many other versions as well.

    As Steve also pointed out... a better smarter mechanism for tracking
    and cross referencing patch kits is called for....

    any volunteers 

    Kevin

  Kevin,

    Since you understand it, perhaps you know who to lobby to have the standard
  improved? In addition to problems with ambiguity, I believe the name should
  also reflect the importance of the patch. I've sent the following suggestion
  as a TIMA/TOOLS COMMENT on a patch twice with no response:

  1) The new "installation rating" should be appended to the patch name.
     For example, ALPRMS04_061 has a rating of 1 (effectively mandatory),
     so the patch name becomes ALPRMS04_061_1. 

  2) Articles describing patches should contain an unique keyword for their
     rating so that searches can be performed according to rating. This could
     be a descriptive but obscure English word (for example: "VACCINE" for
     rating 1) or an artificial word, such as RATING_1

  Customers are getting more and more critical of Digital handling of patches.
  We have the systems and potential for providing a first class service, with
  very little extra effort. Small changes like proper ratings can help a lot,
  but limiting the rating to the lines:

"     Installation Rating:  1 - To be installed on all systems running         
                               the listed version(s) of OpenVMS."

  inside the patch description does nothing for electronic searching,
  browsing FTP listings on the web or "at a glance" TIMAGRAM notifications.
  The sites already exist, but customers and employees now have to read every
  "README" to find out what's important and what's not. 

  Simple change, almost zero cost, huge benefit to customers and employees.
  So who do I hassle about it? Maybe we can fix the ambiguity problem at
  the same time?
						John Gillings, Sydney CSC

    re .0
    
    I also find it worrying when I have to install a patch ending in e.g.
    070 on a VMS 6.2 system. Granted that the kit may well check that it
    supports the version being installed on but it is warmer and fuzzier if
    separate kits were created. A related problem is that typically one
    doesn't know which savesets are required for the particular target
    version. Of course one can pull down all savesets but that wastes time
    and net bandwidth.

The 070 indicates the highest product version to which the ECO applies.  (This
is a change from an earlier revision of DEC STD 204 in which the indication was
for the LOWEST version!)  The kits are supposed to check for the proper
version.

It would be wasteful duplication to have a kit for each VMS version, especially
when there are so many intermediate releases.

				Steve

    re .5
    
    I know what the 070 indicates. If the idea of kits for multiple
    versions is retained then perhaps the name should reflect both the
    lower and upper bound on VMS version.
    
    As for wasteful duplication, it depends on how automated kit creation
    is and where you want to put your waste. At the moment the wasteful
    duplication simply occurs with the system manager.

  Steve,

>It would be wasteful duplication to have a kit for each VMS version, especially
>when there are so many intermediate releases.

    Many of the kits which cover multiple OpenVMS versions are actually 
  seperate kits anyway. There are often .A, .B, .C, .D, .E etc... savesets
  with .A containing KITINSTAL.COM and release notes. .B contains the 
  components for V5.5-2, .C for V6.1, .D for V6.2 etc... So, if I send this
  patch to a customer, first of all I have to individually request each
  saveset (thanks to the brain dead TIMA interface), then I have to send the
  customer 4 times more bits than they actually need. On tape it's not
  so much of a problem, but electronically it's just a waste of time and
  bandwidth.

    Very little duplication required, just splitting up the existing kits.
  Indeed it would *simplify* the patch kits to make them version specific.

    Let's face it, Digital is not very good at patches. The storage, 
  naming, notification and delivery systems are clumsy and confusing and
  there is very little consistency in documenting the importance of or
  interdependencies between patches (numerous examples available on request!).

    Yes it would require money and effort to fix this, perhaps a full time
  patch librarian or two. No, it won't generate any direct revenue, but
  it's reaching a point where we will begin to lose customers over this
  issue.
						John Gillings, Sydney CSC

    additional to .6,.7
    
    While pulling over the 10k day patch files (by FTP) I noted down the
    transfer rates. The lowest seen was 580 bytes/second and the highest
    was 1630 bytes/second. Had I pulled over all savesets of the VAX
    version of the kit (A + 6 other savesets) it would have taken many hours.
    Hopefully I have pulled over the right one of the six.