Is VMS84I_MUP-V0500 really mandatory?

[Jess Goodman]

Usually Mandatory UPdate kits are reserved for a security fix, or to prevent crashes that could affect many VMS customers.

The README file for VMS84I_MUP-V0500 states that it addresses just one new problem:

  5.2.1.1  Problem Description:

               The OpenVMS OTS library string comparison routines
               OTS$STRCMP_LSSP and OTS$STRCMP_LEQP might return
               inaccurate results when used with specific string
               patterns.

               This issue can occur on OpenVMS V8.4 patched with
               VMS84I_UPDATE-V0500 and higher.

So this MUP is to fix a bug introduced by UPDATE 5.  Its README file states:

           The LIBOTS Run-Time Library (RTL) has nine variants of the
           OTS$STRCMP routines. These routines are written in BLISS programming
           language. They perform a byte-to-byte comparison, which leads to
           poor performance.

           In this release of the update kit, the OTS$STRCMP routines are rewritten
           in Itanium assembly, thereby improving the performance significantly.

           Images affected:

           - [SYSLIB]LIBOTS.EXE
           - [SYSLIB]LIBOTS.OLB

I can find no other documnentation on the OTS$STRCMP routines, which would imply that at most sites they would only be used by compilers.

"OTS$STRCMP_LSSP and OTS$STRCMP_LEQP"

The "P" at the end of the two routine names that this MUP fix would seem to indicate that they would be used only for comparing  packed-decimal strings. 

So customers using the COBOL compiler, or third-party COBOL applications would definitly want to install this patch.  But is there any VMS OS or layered software written in COBOL?  I'd rather not install this patch if it's not necessary since I have a special version of LIB$RTL.EXE with a performance fix that I requested from VMS support.

Jess

[abrsvc]

I don't think the installation of this patched LIBOTS will be a problem. Your fix is in the LIB$RTL image correct? Check the kit to see if other images are changed. It sounds to me lkike the only image changed in the OTS so your fix won't be affected.

TO be 100% sure, submit a request through normal support channels to get the official response.

Dan

[Jess Goodman]

Well, that's the other odd thing about this MUP - it updates these seven files:

7  FILES PATCHED OR REPLACED:


      o  [SYSLIB]LIBOTS.EXE (new image)

         Image Identification Information

         Image name: "LIBOTS"
         Image file identification: "V1.0-1"
         Image build identification: "0100000100"
         linker identification:  "Linker I02-37"
         Link Date/Time: 22-FEB-2013 13:10:51.49
         Overall Image Checksum: 87BBA7D9

      o  [SYSLIB]LIBRTL.EXE (new image)

         Image Identification Information

         Image name: "LIBRTL"
         Image file identification: "X01-001"
         Image build identification: "0100000100"
         linker identification:  "Linker I02-37"
         Link Date/Time: 22-FEB-2013 13:10:51.88
         Overall Image Checksum: 992B8504

      o  [SYSLIB]SDA$SHARE.EXE (new image)

         Image Identification Information

         Image name: "SDA$SHARE"
         Image file identification: "X-2"
         Image build identification: "0100000101"
         linker identification:  "Linker I02-37"
         Link Date/Time: 5-MAR-2013 12:21:38.98
         Overall Image Checksum: 55F99C26

      o  [SYS$LDR]SYS$BASE_IMAGE.EXE (new image)

         Image Identification Information

         Image name: "SYS$BASE_IMAGE"
         Image file identification: "IA64 XCFR-J2I"
         Image build identification: "0100000101"
         linker identification:  "Linker I02-37"
         Link Date/Time: 5-MAR-2013 12:18:04.88
         Overall Image Checksum: 80641649

                                                                Page 5


      o  [SYSLIB]LIBOTS.STB (new file)

      o  [SYSLIB]LIBRTL.DSF (new file)

      o  [SYSLIB]LIBRTL.STB (new file)

[John Gillings]

Jess,

   MUPs are rare. The hoops required to get something declared as a MUP inside VMS engineering are fairly daunting, so it's not likely to be something taken lightly (or at least that was how it was in my time...).

   Similarly, translating routines into Itanium assembly language is not something that anyone does for fun. It's really only done for routines which can be shown to have a significant performance impact for a majority of customers. The implications of a bug in a core routine can be very serious, so again, not something taken lightly (for example, they may need to be fixed with a MUP ;-)

  Although I can't fault your logic for the nature of the routine, I don't necessarily agree with your conclusion. It's possible the LSSP and LEQP are used in places you might not expect, for example, perhaps in some of the security related routines? Also remember that engineers don't always reveal the entire nature of their fixes, possibly for egotistical reasons, but sometimes for security (by obscurity ;-). That LIBOTS, LIBRTL and VMS$BASE_IMAGE are being updated hints that it's rather more than just some obscure packed decimal routines.

  If someone has gone through the pain of getting this declared a MUP, and that it's affecting three very fundamental RTLs, I'd be taking it seriously.

  (could be an interesting exercise in reverse engineering to compare the images to see what they really changed)