Conference vaxaxp::vmsnotes

    Re: .0
    
    Since you didn't post the BLITZ contents, I ASSuME that it might be
    referring to an OpenVMS RTL Enhancement, not a BugFix.. (See, e.g.
    Topic 946 in the RTL conference about LIB$CVT_TO_INTERNAL_TIME())
    
    John.

  We had a rather long document circulate which implied that there *was* some
  kind of problem associated with this limit. Lots of management speak with
  little or no technical content (in other words I could tell you precisely
  who attended what con-call to discuss the issue, but cannot say what the
  actual problem is). I sent an EM back to one of the sources asking for more
  detail, without any helpful response (ie: go away, we're dealing with it).

  Reading between the lines, I'm guessing that it's something to do with
  DECthreads. The changes to LIB$ routines will prevent whatever the problem
  is. I'll probably have to wait for my first customer call to get a clear
  description of the symptoms :-(. Perhaps I'll go on leave in May.

						John Gillings, Sydney CSC

Assuming we are talking about the same blitz message, the problem isn't in
the LIB$xxx routines with the 10K restriction; it is their misuse by a number
of components and the effect that had on the applications that layer on top
of them.  As the blitz text said, the RTL calls and their behavior were
well-documented, but they were used by multi-OS, common-source software to 
convert Unix-based Epoch timing formats to OpenVMS Smithsonian format.  The
former is expressed in units (seconds, I think) from Jan 1, 1970.  The 
applications took that offset and turned it into a delta time using 
LIB$CVT_TO_INTERNAL_TIME and LIB$FROM_INTERNAL_TIME in various places without
noticing the 10K restriction on the routines.  10K days from Jan 1, 1970 is
the magic May 19th day and, on the stroke of midnight, time no longer works for
the applications that depend on the underlying components that do the Unix
conversion.   Some handle the condition (at least on the surface) and some 
fold up.  The biggest effect I've seen is from DecThreads and CMARTL; with
OpenVMS Alpha V7.0, those products started using the incorrect calls as their
base timing routines and didn't handle the error condition.  Consequently,
threaded applications start to fail; in OpenVMS it is most noticeable in 
SECURITY_SERVER.  Written in ADA, it uses CMARTL as its threaded architecture 
under V7.  The blitz has more information on the exact effects and 
the degree that it happens in other releases, but, bottom line, take this
seriously and install the patches - this can be fatal for some applications 
and it is not at all obvious that you'll have a problem until it hits.  You 
might want to get a jump on your Y2K testing and try setting the time forward  
" ON A TEST SYSTEM " to see how bad the most blatant effects are.  There is
a document with guideline steps for creating a testing environment somewhere
in the OpenVMS Y2K common areas.  If you have access to it, the pointer should
be posted in the EVMS::Y2K notesfile.

   Short answer: get the CMARTL patch from the patch area, and apply it.
   This patch is available for V6.1 and later OpenVMS releases, with a
   fix for V5.5-x in the works.

   This patch, or a decendent, should be applied to all pre-V7.1 OpenVMS
   systems before 17-May-1997...  (That's when we reach 10K days since
   1-Jan-1970; when the mis-used RTL calls will start returning errors.)

   If the Blitz provides insufficient information, please contact the
   folks that sent the blitz, and ask for an update.

This is all news to me, though it doesn't astonish me.  Is there an internal
location where internal users can get the patch?  Are internal users being
notified about it?

					Steve

:This is all news to me, though it doesn't astonish me.  Is there an internal
:location where internal users can get the patch?  Are internal users being
:notified about it?

   The discussions around the distribution and notification of internal
   and (more importantly) external sites is presently underway -- once
   the necessary decisions have been reached, this information will
   likely become far more widely distributed internally and externally.

   The patches for V6.1 and later are available at the Internet patch
   area, with the patches for most releases having been posted there
   last summer.  The patches will likely also be made directly available
   internally, probably somewhere on BULOVA::...

   Internet patch area:

	http://www.service.digital.com/html/patch_public.html

Also available via anonymous login at ftp.service.digital.com in
/pub/vms/vax/v6.2

vaxlibr02_070.CHKSUM
vaxlibr02_070.CVRLET_TXT
vaxlibr02_070.README
vaxlibr02_070.a-dcx_vaxexe
vaxlibr02_070.b-dcx_vaxexe
vaxlibr02_070.c-dcx_vaxexe
vaxlibr02_070.d-dcx_vaxexe

/pub/vms/axp/v6.2

alplibr04_070.CHKSUM
alplibr04_070.CVRLET_TXT
alplibr04_070.README
alplibr04_070.a-dcx_axpexe
alplibr04_070.b-dcx_axpexe
alplibr04_070.c-dcx_axpexe
alplibr04_070.d-dcx_axpexe

Jilly

    hoo boy, am I going to have ISVs' applications falling into a pit?
    
    Mark Schafer
    Software Partner Engineering
    297-3524

:    hoo boy, am I going to have ISVs' applications falling into a pit?

   I've been told that the `real' Blitz -- .0 apparently got a review
   copy and `ran' with it -- should be out this Thursday.

   Midnight of the morning of 19-May-1997 is `10K-day' for applications
   that mix OpenVMS delta-times and the UNIX/C 1-Jan-1970 base date.
   This is when the delta-time day field can no longer hold the number
   of days since the UNIX base date.  (Users not trying to manipulate
   large delta-time values -- which is a mistake that has been made in
   CMA and undoubtedly in a few customer applications -- will not see
   any 10K-relevent problems during May.)

    re .*
    
    Think of it as a trial run for the year 2000.
    
    (I can't see any reason why this limit to 9999 days for a delta time
    was imposed. In 64-bit ADT format obviously delta times have about the
    same limit as absolute times i.e. tens of thousands of years. $NUMTIM
    imposes its own much smaller limit of 65535 days but even this would be
    nicer than 9999 days.)

    I have asked the moderators to set this note HIDDEN.
    
    This should not be discussed.  There are serious implications to all of
    this.  We have to get our message correct.  It is dilligently being
    worked.
    
    Software Security Response Team and their lawyers are involved.  If you
    require more information, please contact someone from SSRT:
    
    Rich BSS:: Boren
    Chuck MINOTR:: Noble
    Dave VARDAF:: Church
    
    Thanks,
    
    Grahame

   Various previous notes in this string will be unhidden, likely later
   today.  The entire notes string will likely be unhidden by next week.
   This and the immediately previous note will likely be deleted.

   Hoff
   <moderator>

    OpenVMS Engineering and various other DIGITAL Corporate groups are
    presently developing a customer notification letter and a
    comprehensive "Blitz" that will help resolve any customer problems
    that might arise, and any problems in DIGITAL or customer software
    that may arise from the incorrect use of the OpenVMS delta-time
    format and associated conversion routines.  This customer letter
    will be directly distributed to DIGITAL's OpenVMS customers, and
    will include information on detecting code with potential problems,
    and information on obtaining any patches potentially necessary.

    A draft version of the Blitz has been circulated to various internal
    DIGITAL users not on the review list, and was mentioned in previous
    notes in this VMSNOTES 238.* notes string.  Please *DO NOT* propogate
    any draft copies of this Blitz further, as information in the draft
    Blitz is presently under review by engineering, legal, and other
    DIGITAL-internal organizations, and may prove misleading or mistaken.

    The final copy of the Blitz will be distributed through the standard
    support channels, including the normal e-mail messages and TIMA GRAM
    customer notifications.  Distribution of the final Blitz is expected
    by 28-Feb-1997.

    The final Blitz will be posted in place of this message, and all notes
    in this string not already visible will be unhidden at that time.

    Your patience and understanding is appreciated.

    If you have further questions on this issue, please contact Leo Demers,
    the OpenVMS Security Product Manager, at 603-881-2245, DTN 381-2245,
    [email protected], or STAR::DEMERS.

From:   STAR::DEMERS "Leo 381-2245 OpenVMS/SEVMS Security Product Manager 04-Mar-1997 0906 -0500"
To:     HOFFMAN
CC:     DEMERS
Subj:   Please post and unlock the note 238 in VMSNotes

From:   STAR::AVERY "Sue Avery ** DTN 381-0163  04-Mar-1997 0753 -0500" 4-MAR-1997 08:12:20.91
To:     @LP_CONTACTS
CC:     VMSSPT::MICHAUD,PLAISTED,EVMS::KAUFFMAN,AVERY
Subj:   A: OpenVMS Delta Time Limit BLITZ and Cover Letter

Hi,

I've attached 2 pieces of mail (a Digital Internal BLITZ and a Customer
Letter) that describe a delta-time restriction with the OpenVMS operating
system that may cause a serious error in some applications and OpenVMS
components beginning on or around 19-MAY-1997.  DIGITAL has provided ECOs
(Engineering Change Orders) that remove the delta-time limit.

Please read the attached messages (note that they're lengthy!) and make sure 
that your group thoroughly understands the impact it might have on your 
product.  The OpenVMS Delta Time Limit Customer Letter is being sent to
OpenVMS VAX SPL customers and OpenVMS MDDS Service Customers.  Customer
mailings are scheduled to start on 3/12/97.

If you have questions about this mail, please contact any of the following
folks:

Engineering contact: 		Grahame Plaisted (STAR::PLAISTED) 
Engineering contact:		Jim Kauffman (EVMS::KAUFFMAN)
Product Management contact:	Mary Jane Vazquez (STAR::VAZQUEZ)

thanks,

- Sue


+---------------------------+TM
                             
  d   i   g   i   t   a   l        TIME   DEPENDENT   BLITZ
                             
+---------------------------+ 

      OpenVMS Delta-Time Restrictions and 19-May-1997

      AUTHOR: Grahame Plaisted              DATE: 28-Feb-1997
      DTN: 381-0910                         TD #:
      ENET: SPSEG::PLAISTED                 REFERENCE #'s: UTO101272, SSRT0450V
      DEPARTMENT: OpenVMS RTL Support Eng.  (PRISM/TIME/CLD#'s)  HPAQA23C1,
      INTENDED AUDIENCE: All                HPXQ10TSV, EVMS-GRYPHON QAR 1490
      (U.S./EUROPE/GIA)                     PRIORITY LEVEL: 1


          1  EXECUTIVE SUMMARY                                               
                                                                              
          The OpenVMS operating system has a documented delta-time 
          restriction that may cause a serious error in some applications 
          and OpenVMS components beginning on or around 19-MAY-1997. 
          DIGITAL has provided ECOs (Engineering Change Orders) that 
          remove the delta-time limit.

          DIGITAL strongly recommends that all customers running the 
          affected versions of OpenVMS install the appropriate ECO.
                                                                              
          DIGITAL will proactively communicate this problem and solution      
          to the OpenVMS user community.  These measures are documented       
          in this article.                                                    
                                                                              
          The remainder of this article explains the problem in detail.       
          An example C program is attached that illustrates the problem.      

          2  PROBLEM

          OpenVMS customers may experience errors in some applications        
          and OpenVMS components when dates are specified on or around
          19-MAY-1997.

          Applications and OpenVMS components most likely to experience       
          errors are those that pass delta-time arguments with values         
          exceeding 9999 days on system-supplied date routines. The most      
          likely date that these errors will occur is 19-MAY-1997:00:00,      
          which is 10,000 days after the common UNIX time origin of           
          1-JAN-1970. The errors take various forms, and affect               
          applications that are both non-threaded and multi-threaded.         
          (Applications can also encounter errors before the system           
          clock reaches 19-MAY-1997 if an application uses future dates       
          and specifies a date of 19-MAY-1997 or later.) See the DESCRIPTION  
          section for more information.                                       
                                                                              
          The versions of OpenVMS that are affected by the 10,000 day         
          delta-time restriction are:                                        

          o  OpenVMS Alpha Version 6.1 through Version 7.0 (inclusive):

             OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2, V6.2, V6.2-1H1, V6.2-
             1H2, V6.2-1H3, V7.0

          o  OpenVMS VAX Version 5.5 through Version 7.0 (inclusive):

             OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2HW, V5.5-2H4, 
             V5.5-2HF, OpenVMS VAX V6.0, OpenVMS VAX V6.1, 
             OpenVMS VAX V6.2, OpenVMS VAX V7.0

          Systems running OpenVMS VAX Version 7.1 or OpenVMS Alpha Version    
          7.1 are not impacted and do not need to install the ECO.

          The following OpenVMS components and software products are known
          to be affected by the delta-time limit. The ECOs correct the
          problems observed in these products.

          ________________________________________________________________
          Product_____________________________OpenVMS_Version_____________

          OpenVMS SECURITY Server             OpenVMS Alpha V7.0 only

          DECwindows Motif for OpenVMS        OpenVMS Alpha V7.0 only

          Distributed Computing Environment   OpenVMS Alpha V6.2 only
          (DCE) for OpenVMS

          OpenVMS DECthreads                  OpenVMS Alpha and OpenVMS VAX 
                                              V5.5 through V7.0

          (OSU) DECthreads HTTP Server        OpenVMS Alpha and OpenVMS VAX 
          (freeware provided with the         V5.5 through V7.0
          OpenVMS Internet Product Suite)
          ________________________________________________________________

          Other software products running on OpenVMS might also experi-
          ence errors stemming from this delta-time limit. Contact the
          appropriate software vendor for more information.

          3  SOLUTION                                                         
                                                                              
          The following ECOs resolve all known instances of this error        
          in OpenVMS.                                                         

             OpenVMS Alpha: ALPLIBR05_070
             OpenVMS VAX:   VAXLIBR05_070

          It is essential that DIGITAL customers are aware of this issue.
          DIGITAL will take the following proactive measures:

          o  Send a letter to current OpenVMS MDDS service customers          

          o  Include a letter in the March 1997 OpenVMS VAX Software 
             Layered Products Library
                                                                              
          o  Work with FIRST and other Internet notification groups to        
             provide additional coverage/notice to customers                  

          o  Post information in USENET newsgroup comp.os.vms

          o  Distribute ECOs through:                                         
                                                                              
             -  DIGITAL Electronic Service Delivery Tools (such as DSNlink, 
                Web Information and Support Service (WIS), and DIGITAL 
                Dial-In Access (DIA))

             -  the World Wide Web at:

                   http://www.service.digital.com/html/patch_main.html

             -  the following FTP address:

                   ftp://ftp.service.digital.com/public/vms/

          For further information, DIGITAL customers can contact their 
          normal DIGITAL support channel.

          4  SYMPTOMS/IMPACT

          The following sections describe specific errors encountered         
          on OpenVMS Alpha Version 7.0 and OpenVMS Alpha Version 6.2.         
          These or similar errors may be encountered on other versions of     
          OpenVMS affected by the 10,000 day delta-time restriction.          

          For OpenVMS Alpha Version 7.0 systems:

          The following error may be displayed on the console which will
          cause the security server to hang.

         %CMA-F_EXCCOPLOS, exception raised: some information lost
         -CMA-F-BADPARAM, parameter to DECthreads operation is invalid
         %ADA-I-TASTERUNH, Task with ID %TASK 9 of type
         Verify_Dependant_Tasks_type has terminated due to unhandled exception

          The above messages stem from the SECURITY_SERVER. Service is not
          denied, but security event messages are not recorded.

          On OpenVMS Alpha Version 7.0 systems, DECWindows Motif will
          cease to function on or around 19-MAY-1997. This will prohibit 
          users from logging into their workstations or from starting any 
          new applications.

          For OpenVMS Alpha Version 6.2 systems:

          The OpenVMS DCE RPC Daemon (DCE$RPCD) fails to start on sys-
          tems with the 10,000 day delta-time restriction. In the files
          DCE$RPCD.ERR and DCE$RPCD.OUT, the DCE$RPCD process logs the
          following error:

             %CMA-F-BADPARAM, parameter to DECthreads operation is invalid

          This error is identical to the console scenario in the previ-
          ous section. There may be additional products or scenarios that
          yield this same result for the 10,000 day delta-time restric-
          tion.

          5  DESCRIPTION

          With the increasing number of UNIX applications that have been
          ported to OpenVMS, the 10,000 day delta-time restriction has
          become an important issue. This restriction has been removed
          from OpenVMS RTL Library (LIB$) routines and the $NUMTIM system
          service. However, LIB$SYS_ASCTIM and the $ASCTIM system service
          continue to have a 10,000 day delta-time restriction.

          The original implementation of the 10,000 day limit was inten-
          tional, is currently documented and was intended to bound the
          length of the string returned from $ASCTIM. ($ASCTIM is the only    
          routine that requires the restriction.) The risk in removing the    
          restriction from the $ASCTIM system service is that there may be
          decades worth of programs and DCL command procedures that depend
          on a maximum of four digits in the ASCII string returned.

          The most serious error is the DECthreads error that occurs when
          the OpenVMS Alpha SECURITY_SERVER attempts to log a message on
          the console. The date/time is handled as part of an exception
          that is initially managed by the DEC ADA Run-Time Library and is
          subsequently passed to DECthreads. DECthreads converts UNIX time
          to OpenVMS time by calling LIB$CVT_TO_INTERNAL_TIME, specifying
          the 10,000 day delta time. LIB$CVT_TO_INTERNAL_TIME returns an
          error to DECthreads on dates beginning on or around 19-MAY-1997 
          (10,000 days after the UNIX time origin) which results in the 
          console errors.

          For threaded applications:

          The 10,000 day issue only arises in cases where a UNIX time is
          converted to an OpenVMS time. The original implementation of the
          DECthreads interface did not involve any UNIX time specifica-
          tions on OpenVMS. These were introduced with the implementation
          of the draft POSIX interface, which was layered on top of the
          original, proprietary (CMA) interface. Therefore, prior to Ver-
          sion 7.0, only software that uses the draft POSIX interface (and
          which makes use of timed waits) is affected.

          In OpenVMS Version 7.0 DECthreads provided an implementation of
          the newly accepted POSIX standard interface for threading ser-
          vices. The POSIX standard interface became the core interface
          and the other interfaces were reimplemented on top of it. Begin-
          ning in OpenVMS Version 7.0, all software that uses timed thread
          waits may encounter the 10,000 day delta-time errors.

          DECthreads source code is identical for OpenVMS VAX Version 7.0
          and OpenVMS Alpha Version 7.0.

          For all applications:

          If your application calls the following OpenVMS RTL Library
          (LIB$) routines, you may encounter the 10,000 day delta-time
          errors.

             LIB$CVT_TO_INTERNAL_TIME         LIB$ADD_TIMES 
             LIB$CVT_FROM_INTERNAL_TIME       LIB$SUB_TIMES
             LIB$CVTF_TO_INTERNAL_TIME        LIB$MULT_DELTA_TIME
             LIB$CVTF_FROM_INTERNAL_TIME      LIB$MULTF_DELTA_TIME
             LIB$CVT_VECTIM                   LIB$CONVERT_DATE_STRING

          Applications that are written in DEC C and contain portable code    
          that calls only ANSI time functions are not impacted. This is       
          because the DEC C Run Time Library calculates time locally and
          does not call OpenVMS RTL Library (LIB$) time routines. These
          ANSI time functions are as follows:

             ctime     ftime
             mktime    strftime
             fstat     gmtime
             stat      time

          The one exception to this list is the ANSI time function sleep.     
          The DEC C Run Time Library continues to enforce the 9999 day        
          delta-time restriction on sleep. 

          6  IMPACT ON APPLICATION DEVELOPERS

          Attached to this BLITZ is a short C program that demonstrates
          the current 10,000 day delta-time restriction to application
          developers. In all cases, application developers and their
          customers must install the ECO.

          If an application developer uses OpenVMS shareable images,
          there is no required code change and relinking is not necessary;
          installing the ECO on the customer system corrects the problem.

          If an application developer does not use OpenVMS shareable im-
          ages (that is, links using STARLET) and the application is
          subject to the 10,000 day restriction, no code change is required,
          but the developer must relink the application after installing
          the ECO and might need to redistribute the software. The appli-
          cation developer's customers must also install the ECO on 
          their systems. 

          There are two possible methods of redistributing the software:

          o  Distribute full executable without shareable images

             After installing the ECO and relinking the application,
             the application developer redistributes the product to all
             customers.

          o  Link on target system

             After installing the ECO, the application developer ships
             the object files/libraries they require to the customer. The
             application developer's customers must install the ECO and
             relink the application.

          7  RESOLUTION

          If OpenVMS components hang with a message on the console (DEC-
          netPlus Phase V, OSI, and DTSS are most likely to hang), you
          must set the time ahead. To do so, enter the following 
          commands:

             $ MCR SYSMAN
             SYSMAN> SET ENVIRONMENT/CLUSTER
             SYSMAN> DO MCR NCL DISABLE NODE 0 DTSS
             SYSMAN> DO MCR NCL DELETE  NODE 0 DTSS
             SYSMAN> SET TIME=20-MAY-1997:01:00
             SYSMAN> EXIT

          At this point, install the appropriate ECO and perform a system
          reboot.

   8  C PROGRAM ATTACHMENT

   ATTACHMENT: (Show10K.C)
  /*
  **  Program to illustrate 10K day delta time limit
  **
  **
  **  Compilation instructions for DEC C compiler:
  **
  **  Compile:    CC/DECC Show10K
  **  Link:
  **    Using shareable images/IMAGELIB:  LINK Show10K
  **    Using STARLET:                    LINK Show10K/NOSYSSHR
  **
  **
  **  Compilation instructions for VAX C compiler:
  **
  **  Compile:    CC/VAXC Show10K
  **              or
  **              CC Show10K
  **  Link:
  **    Using shareable images:
  **      LINK Show10K,SYS$INPUT/OPTION
  **      SYS$SHARE:VAXCRTL.EXE/SHARE
  **    Using VAX C RTL object library:
  **      LINK Show10K,SYS$SHARE:VAXCRTL/LIBRARY
  **    Using STARLET and VAX C RTL object library:
  **      LINK Show10K/NOSYSSHR,SYS$SHARE:VAXCRTL/LIBRARY,SYS$INPUT/OPTION
  **      SYS$SHARE:CMA$TIS_SHR.EXE/SHARE
  **
  **
  **  Execute:    RUN Show10K
  **
  **  Results:
  **
  **      If you receive the following errors during LINK (/NOSYSSHR), then
  **      somehow DEC C RTL routines are no longer in STARLET.  This is
  **      easily resolved by first installing any DEC C RTL ECO.
  **
  **      %LINK-W-NUDFSYMS, 3 undefined symbols:
  **      %LINK-I-UDFSYM,         DECC$DPRINTF
  **      %LINK-I-UDFSYM,         DECC$EXIT
  **      %LINK-I-UDFSYM,         DECC$MAIN
  **      %LINK-W-USEUNDEF, undefined symbol DECC$MAIN referenced
  **              in psect $CODE offset %X0000004E
  **              in module SHOW10K file FOO$:[USER]SHOW10K.OBJ;1
  **      %LINK-W-USEUNDEF, undefined symbol DECC$DPRINTF referenced
  **              in psect $CODE offset %X0000009E
  **              in module SHOW10K file FOO$:[USER]SHOW10K.OBJ;1
  **      %LINK-W-USEUNDEF, undefined symbol DECC$DPRINTF referenced
  **              in psect $CODE offset %X000000B1
  **              in module SHOW10K file FOO$:[USER]SHOW10K.OBJ;1
  **      %LINK-W-USEUNDEF, undefined symbol DECC$EXIT referenced
  **              in psect $CODE offset %X000000C9
  **              in module SHOW10K file FOO$:[USER]SHOW10K.OBJ;1
  **
  **
  **
  **      If the restriction is present:
  **
  **              OpenVMS ALPHA: You must install ECO ALPLIBR05_070.
  **              OpenVMS VAX:   You must install ECO VAXLIBR05_070.
  **
  **
  **      If ECO applied and restriction removed:
  **
  **              You do not require the ECO.
  **
  */

  #include <stdio.h>
  #include <string.h>
  #include <lib$routines.h>       /* LIBRTL routine prototypes             */
  #include <libdef.h>             /* return codes                          */
  #include <libdtdef.h>           /* operation code for date/time routines */


  #ifdef __ALPHA
  #define KITNAME "ALPLIBR05_070"
  #else
  #define KITNAME "VAXLIBR05_070"
  #endif


  main()
  {
          long int  K_10K = 10000 ;                /* 10000 days in future */
  
          unsigned 
          long int  operation = LIB$K_DELTA_DAYS , /* Operation            */
                    status ;                       /* return status        */
  
          unsigned 
          char      ResultTime[ 8 ] ;              /* Quadword for time    */

          char      ECOname[ 14 ] = KITNAME ;

          /*
          **  Illustrate what happens
          **
          **  If LIB$_IVTIME is returned, then you will require
          **  the ECO [ALP|VAX]LIBR05_070.
          */


          status = lib$cvt_to_internal_time( &operation ,
                                             &K_10K     ,
                                             &ResultTime
                                           );

          /*
          **  This "catch all" for those systems that might have
          **  ALPLIBR04_070 or VAXLIBR02_070 installed.
          */

          if (status == LIB$_NORMAL)
             status = lib$cvt_from_internal_time( &operation,
                                                  &K_10K,
                                                  &ResultTime
                                                );

          switch (status) {
                  case LIB$_NORMAL:
                          printf( "You do not require the ECO.\n" );
                          break;
                  case LIB$_IVTIME:
                          printf( "You must install ECO %s.\n", ECOname );
                          break;
                  default: /* unknown error -- signal it */
                          lib$signal(status);
          }
  
  }



          DIGITAL


          OpenVMS[TM] Delta-Time Limit Notification Cover Letter

          AV-R4Y1A-TE

          February 1997

          Dear OpenVMS Customer,

          The OpenVMS operating system has a documented delta-time limit
          that may cause a serious error in some applications and OpenVMS
          components beginning on or around 19-MAY-1997. DIGITAL has
          provided ECOs (Engineering Change Orders) that remove the delta-
          time limit.

          Applications and OpenVMS components most likely to experience
          errors are those that pass delta-time arguments with values
          exceeding 9999 days on system-supplied date routines. The most
          likely date that these errors will occur is 19-MAY-1997:00:00,
          which is 10,000 days after the common UNIX time origin of 1-JAN-
          1970.

          DIGITAL strongly recommends that all customers running the
          affected versions of OpenVMS install the appropriate ECO, as
          follows:

           For OpenVMS Alpha Version 6.1 through Version 7.0:  ALPLIBR05_070
           For OpenVMS VAX Version 5.5 through Version 7.0:    VAXLIBR05_070

          Systems running OpenVMS Alpha Version 7.1 and OpenVMS VAX Ver-
          sion 7.1 are not affected and do not need to install the ECO.

          The following OpenVMS components and software products are known
          to be affected by the delta-time limit. The ECOs correct the
          problems observed in these products.

          ________________________________________________________________
          Product________________________________OpenVMS_Version__________

          OpenVMS SECURITY Server                OpenVMS Alpha V7.0 only

          DECwindows Motif for OpenVMS           OpenVMS Alpha V7.0 only

          Distributed Computing Environment      OpenVMS Alpha V6.2 only
          (DCE) for OpenVMS

          OpenVMS DECthreads                     OpenVMS Alpha and OpenVMS
                                                 VAX V5.5 through V7.0

          (OSU) DECthreads HTTP Server (free-    OpenVMS Alpha and OpenVMS
          ware provided with the OpenVMS         VAX V5.5 through V7.0
          Internet_Product_Suite)_________________________________________

          Other software products running on OpenVMS might also experi-
          ence errors stemming from this delta-time limit. Contact the
          appropriate software vendor for more information.


 


          Impact on Application Developers

          Application developers and their customers must install the
          appropriate ECO.

          If an application developer uses OpenVMS shareable images,
          there is no required code change and relinking is not necessary;
          installing the ECO on the customer system corrects the problem.

          If an application developer does not use OpenVMS shareable
          images (that is, links using STARLET) and the application is
          subject to the 10,000 day restriction, no code change is re-
          quired. However, the developer must relink the application after
          installing the ECO and might need to redistribute the software.
          The application developer's customers must also install the ECO
          on their systems.

          If your application calls the following OpenVMS RTL Library
          (LIB$) routines, you may encounter errors due to the 10,000 day
          delta-time limit.

          LIB$CVT_TO_INTERNAL_TIME         LIB$SUB_TIMES
          LIB$CVT_FROM_INTERNAL_TIME       LIB$MULT_DELTA_TIME
          LIB$CVTF_TO_INTERNAL_TIME        LIB$MULTF_DELTA_TIME
          LIB$CVTF_FROM_INTERNAL_TIME      LIB$CONVERT_DATE_STRING
          LIB$CVT_VECTIM                   LIB$ADD_TIMES

          Applications that are written in DEC C and contain portable code
          that calls only ANSI time functions are not impacted.

          Distribution Channels

          DIGITAL is distributing the ECOs only through the following
          channels. Customers should obtain the ECOs from:

          o  DIGITAL Electronic Service Delivery Tools (such as DSNlink,
             Web Information and Support Service (WIS), and DIGITAL Dial-
             In Access (DIA))

          o  the World Wide Web at:

                http://www.service.digital.com/html/patch_main.html

          o  the following FTP address:

                ftp://ftp.service.digital.com/public/vms/

          If you need further information, please contact your normal
          DIGITAL support channel.

          DIGITAL appreciates your cooperation and patience. We regret any
          inconvenience applying this update may cause.

              �Digital Equipment Corporation. 1997. All rights reserved.
          ___________________
       [TM] The following are trademarks of Digital Equipment Corporation:
            OpenVMS, VAX, VMS, and the DIGITAL logo.

                                          2

   ...from the folks responsible for getting the kits to the customers:

"Just wanted to let everyone know that

	VAXLIBR05_070
	ALPLIBR05_070

have been released to TIMA.  In addition, the following will also occur:

o  They will be available electronically (DNSlink, DIA, WIS) to all
   customer tomorrow, March 5.

o  They will be available on the Internet via FTP access today and
   WWW access tomorrow.

o  SSB processing has begun.   They should be available for media
   request from the CSC/USA in a few days.

o  Blitz article should be released today.

o  DSNlink FLASH mail to US customers should start to occur tomorrow.

That about covers it from here."

> That about covers it from here.

  "Slight" problem here in Australia. We don't have a very high penetration
  of customers with electronic access. I expect the CSC will be innundated
  with calls requesting these patch kits and we simply don't have the resources
  to create and ship the expected volume of requests. I would have thought
  that a problem of this magnitude warranted shipment of patch (MUP?) media
  to all contract customers. Why has it been left to the CSCs to pay for the
  distribution of this patch?

  Yet another example of poor handling of patch kits by Digital.

						John Gillings, Sydney CSC

    I'm surprised that the customers in Australia haven't seen and found
    the light of 'internet', otherwise I expect they would just download
    the patches from there instead calling you to make them a tape...
    
    /cmos

    re .16
    
    Use of the net is quite prevalent here. However unless we mirror the
    patch site down under (John?), getting patches would be very s...l...o...w.

:    Use of the net is quite prevalent here. However unless we mirror the
:    patch site down under (John?), getting patches would be very s...l...o...w.

   There's a Madagascar mirror site for www.digital.com coming on-line,
   if memory serves.

  /cmos,

>    I'm surprised that the customers in Australia haven't seen and found
>    the light of 'internet'

    Some have, some haven't. Please remember how big Australia is and
  how spread out it is. Consider that the cost of a network link is
  *substantially* more expensive than it is in the USA. Bottom line is 
  that we don't have anywhere near the penetration, and that isn't likely
  to change before 19th May.

> otherwise I expect they would just download
> the patches from there instead calling you to make them a tape

    Even with a network like, assuming a 28.8 modem, downloading the 4.5MB
  of the Alpha patch and/or the 2.5MB of the VAX patch would be prohibitive
  in both time and cost. It's only just inside our DSNlink system's cut off
  for patch size over which the request is routed for manual processing (we
  have only 6 modems on our DSNlink system).

    What we will probably do is cut a CD containing the patches and ship it
  to all customers (which is what I think should have been done for everyone).

> However unless we mirror the
>    patch site down under (John?)

    We have a mirror site at ftp.service.digital.com.au, but the LIBR patches
  haven't shown up yet.
						John Gillings, Sydney CSC

    re .19
    
    (Roll on the cable network...)
    
    Would I be right in thinking that within Digital Australia we can't use
    the Australian patch mirror site without some incantation? ping and ftp
    both say the node is unreachable however Netscape can get there.

Hi, one of my customer application has used $ASCTIM system service.

Question: 

a) Will the application has any problem because of 10k restriction?
b) Is there a problem if $ASCTIM is called in the following way:
     CALL SYS$ASCTIM(,ASC_DATE,,) in Fortran ?
c) Will Lib$Sys_ASCTim and $ASCTIM system services still has the
   10K restriction after the ECO patch? 
d) DO I need modification to my application even I apply the ECO?

Thanks.
THS

   Please read through the previously-posted information -- it describes
   the problem in great detail...   Please also learn more about the DELTA
   and ABSOLUTE time formats, as that piece of knowledge is critical to
   the understanding of this ECO.

   If your application has followed the long-standing four-digit day
   field width limit when working with DELTA times, you will see no
   problems with your application, and -- with the application of the
   ECO or the upgrade to V7.1 -- lower level RTL code will not see
   any problems, either.

   If your code is using ABSOLUTE times, there is no problem.

:a) Will the application has any problem because of 10k restriction?

   Unknown.  Insufficient information for a meaningful response.

:b) Is there a problem if $ASCTIM is called in the following way:
:     CALL SYS$ASCTIM(,ASC_DATE,,) in Fortran ?

   This particular syntax is not using a `delta time', it is returning
   an `absolute time'.  If these terms are not clear to you, please
   take a look at HELP SPECIFY DATE for details.

   Only if your application has violated the long-standing four-digit
   day field width limit FOR DELTA TIMES, will your application code
   see problems.  And if your code has violated this long-standing
   requirement, the installation of the ECO kit will alleviate your
   programming error.
   
:c) Will Lib$Sys_ASCTim and $ASCTIM system services still has the
:   10K restriction after the ECO patch? 

   The limit will be lengthened out -- but since you're already doing
   an analysis of year-2000 issues (right?), you can fix the problem
   once and for all.  These and other calls will accept a rather larger
   day field width limit...

:d) DO I need modification to my application even I apply the ECO?

   Only if you have linked against 

.22> :c) Will Lib$Sys_ASCTim and $ASCTIM system services still has the
.22> :   10K restriction after the ECO patch? 
.22> 
.22>    The limit will be lengthened out -- but since you're already doing
.22>    an analysis of year-2000 issues (right?), you can fix the problem
.22>    once and for all.  These and other calls will accept a rather larger
.22>    day field width limit...

This contradicts my reading of the ECO's description:

.13>          With the increasing number of UNIX applications that have been
.13>          ported to OpenVMS, the 10,000 day delta-time restriction has
.13>          become an important issue. This restriction has been removed
.13>          from OpenVMS RTL Library (LIB$) routines and the $NUMTIM system
.13>          service. However, LIB$SYS_ASCTIM and the $ASCTIM system service
.13>          continue to have a 10,000 day delta-time restriction.
.13>
.13>          The original implementation of the 10,000 day limit was inten-
.13>          tional, is currently documented and was intended to bound the
.13>          length of the string returned from $ASCTIM. ($ASCTIM is the only  
 
.13>          routine that requires the restriction.) The risk in removing the  
 
.13>          restriction from the $ASCTIM system service is that there may be
.13>          decades worth of programs and DCL command procedures that depend
.13>          on a maximum of four digits in the ASCII string returned.

    re: .19
    
    John,
    
    I know Finland isn't as big as Australia, but in northern Lapland where
    only reindeers and Santa Claus are living and the other not so heavy
    population in Finland still allows you access to Internet etc., but
    thats probably because Finland is pretty mature in the Telecom area...
    
    I know it's not always easy, so I should probably have inserted a small
    :-) in my reply...
    
    /cmos

Bill (Noyce) is correct.  LIB$SYS_ASCTIM and the $ASCTIM system service
have _not_ been changed.  That is, both these routines still and always 
will have the 10,000 day restriction.

Mary

So, I pulled the patch kits and started installing them around.  The alpha 
kit worked fine on my V6.2 system.  The VAX kit worked fine on my V6.2 
cluster.

However, the VAX kit did *not* work fine on my V5.5-2 cluster.  The system 
was continually crashing.  After I backed out the patch, the cluster is 
again stable.

Does anyone else have any experience with this kit on a V5.5-2 VAX system?  

Ray

save set		creation date (from BACKUP/LIST)
========		================================
VAXLIBR05_070.A		27-FEB-1997 17:14:26.04
VAXLIBR05_070.B		27-FEB-1997 17:14:33.96
VAXLIBR05_070.C		27-FEB-1997 17:14:47.57
VAXLIBR05_070.D		27-FEB-1997 17:15:01.46
VAXLIBR05_070.E		27-FEB-1997 17:15:12.94
VAXLIBR05_070.F		27-FEB-1997 17:15:30.83
VAXLIBR05_070.G		27-FEB-1997 17:15:49.51

: May 19 ain't that far away...

   Correct.

:Does anyone else have any experience with this kit on a V5.5-2 VAX system?  

   See if you can determine exactly what was crashing -- hopefully,
   this is something site-specific.  If you are not familiar with
   digging through a crashdump, go directly to the IPMT or QAR.

   Unless you can determine this is something local that's causing
   the crash, you will want to log a high-priority IPMT or QAR.

   You may/will be asked to provide CLUE output or a copy of the
   dumpfile from the crash, please set a copy aside to prevent
   it from being overwritten by another crash.

    re .21
    
    Elaborating on Steve's response...
    
    The ASCII format of delta times has always been limited to 9999 days
    while the ASCII format of absolute times has always been limited to the
    year 9999.

    The binary format of absolute time is limited to 63 bits and is
    equivalent to tens of thousands of years. The binary format of delta
    time while potentially having the same limit as absolute time is
    currently limited to 9999 days (about 27 years).
    
    There is also a "numtim" format where each of the fields of the
    absolute or delta time is represented separately as a word (16 bits)
    but this too when representing a delta time is limited to 9999 days
    (even though it could go as far as 179 years).
    
    The logic of this is presumably that you then cannot have a binary or
    numtim delta time that cannot be converted to an ASCII delta time
    (although the same logic was not applied with binary absolute times).
    
    The problem with this is that, since a much long binary delta time and a
    somewhat longer numtim delta time make sense and can be represented,
    people may have overlooked the limit to 9999 days.
    
    The 10k day problem applies specifically to those who use delta times.
    
    (The y10k problem applies specifically to those who use absolute times
    (and then only if they use them in ASCII format) and noone is too
    worried about this with 8000 years to fix it.)
    
    A specific example of where the 10k day problem can arise is in
    converting a UNIX style "seconds since 1-JAN-1970" to a VMS style
    absolute time, if one does this by converting the seconds to whole
    days and remaining hours, minutes and seconds and then tries to convert
    this as a numtim delta time to a binary delta time (in order to "add"
    it to the absolute binary delta time for 1-JAN-1970). This will work for
    27 years and then suddenly in May, 1997 one will get an error in the
    conversion (which, even worse, may not be checked for).
    
    Such an error does occur in some part of DECthreads (as I understand
    it) and could occur in any code doing the same.
    
    So with that background...
    
>Hi, one of my customer application has used $ASCTIM system service.
    
    This ipso facto is not a problem.
    
>a) Will the application has any problem because of 10k restriction?
    
    Insufficient information. If the only call to SYS$ASCTIM is the one you
    show and you make no other time service or time library routine calls
    and the application code does not itself introduce any restrictions then
    the answer is "no".
    
>b) Is there a problem if $ASCTIM is called in the following way:
>     CALL SYS$ASCTIM(,ASC_DATE,,) in Fortran ?
    
    No. This is converting the current system time (implicitly this is an
    absolute time) and so being an absolute time does not have a problem
    any time within the next 8000 years.
    
>c) Will Lib$Sys_ASCTim and $ASCTIM system services still has the
>   10K day restriction after the ECO patch? 
    
    Yes. But this is only relevant to delta times, not absolute times.
    
>d) DO I need modification to my application even I apply the ECO?
    
    Insufficient information. As above, if the only call to any time
    service or time library routine is the one above and you don't make the
    same mistake in any time conversions that you yourself have coded then
    there should be no problem in the application (with or without the
    ECO).
                                                                  

    Re: .21
    
> b) Is there a problem if $ASCTIM is called in the following way:
>     CALL SYS$ASCTIM(,ASC_DATE,,) in Fortran ?
    
    Yes, you're ignoring the returned condition value!  This routine should be
    referenced as a FUNCTION.
    
    John.

Hi,

	Just got a query from a VMS 5.4 customer. 

	- Is the patch applicable to VMS 5.4 ? The release note says 5.5-7.0

	- What is our offical position on this ?

Regards,
YongLee

Do they have a Prior Version support contract at least?  Are they willing 
to pay for the fix to be ported back that far?

Jilly

:	Just got a query from a VMS 5.4 customer. 

   Interesting, since we haven't sent out the BLITZ yet.

   Inform the customer that OpenVMS V7.1 is the current release.

   Under standard support contracts, *only* V7.0 and V7.1 are presently
   supported releases.

:	- Is the patch applicable to VMS 5.4 ? The release note says 5.5-7.0

   No, the patch is not applicable to and not tested on OpenVMS VAX V5.4.

:	- What is our offical position on this ?

   The customer presently has no support -- the oldest version of OpenVMS
   under "Prior Version Support" in most DIGITAL geographies is V5.5-2.
   (This, of course, can vary by country, but I'm not aware of any DIGITAL
   country that's supporting as far back as V5.4.)

   Given that the most common problem here is DECthreads and DECthreads
   does not exist for V5.4, I'm not sure why this question is even being
   asked.  If the customer has other instances of this problem they've
   coded into their application(s) in spite of the documented limits,
   they have several choices:

	o pay DIGITAL to back-port the fix to V5.4
	o fix the problem in their source code.

   --

   To acquire a rush shipment of a previous OpenVMS release, contact
   the Software Supply Business that handles your region -- see VTX
   ATOZ or the low-numbered notes for the US SSB contact info, and
   call them for contact info for other countries -- and request a
   priority shipment of the necessary OpenVMS upgrade kit(s).

   I've attached some typical OpenVMS VAX upgrade paths:

   --
   OpenVMS VAX release upgrade paths:

     From V5.0 through V5.4-3 inclusive, one can upgrade to V5.5.
     From V5.5, V5.5-1, or V5.5-2HW, one can upgrade to V5.5-2.
     From V5.5, V5.5-1, or V5.5-2, one can upgrade to V6.0.
     From V5.5-2, V5.5-2H4, or V6.0, one can upgrade to V6.1.
     From V6.0, or V6.1, one can upgrade to V6.2.
     From V6.1, or V6.2, one can upgrade to V7.0.
     From V6.1, V6.2, or V7.0, one can upgrade to V7.1.

     Some typical OpenVMS VAX upgrade paths are:
         V5.x -> V5.5 -> V6.0 -> V6.2 -> (V7.0, or V7.1)
         V5.5-2, or V5.5-2H4 -> V6.1 -> (V6.2, V7.0, or V7.1)

     Note that OpenVMS VAX V6.0 does not include support for hardware
     and/or configurations first added in OpenVMS VAX V5.5-2H4, one
     must upgrade to OpenVMS VAX V6.1.

>   Interesting, since we haven't sent out the BLITZ yet.

  Ha! I spoke to a customer inquiring about this patch yesterday who said he'd
  heard about this problem from at least 4 independent sources. It's been on
  the Web and the usenet for quite some time.

						John Gillings, Sydney CSC

    re .last few
    
    Given that we are just BLITZing now (or not even yet) and any site that
    will have a problem will have it in only two months time, it is *not*
    reasonable IMHO to tell customers to upgrade to a current release of
    VMS. For many sites with lots of interdependent layered products and
    third party software and demanding availability requirements, two
    months is simply not enough elapsed time for a VMS upgrade.
    
    re .30
    
    If you want an official position then obviously you ask a Product
    Manager (not in Notes) or else you could have the customer IPMT it but...
    
    before you do that, you might want to have the customer assess whether
    the problem even affects them.
    
    To get some confidence that the problem does or does not affect them,
    they could look at what products they use and what the vendor says
    about the product's status post-10k days and for any other applications
    where they have source (e.g. in house) a code "inspection" would be in
    order.

    In parallel with that, on a test system, set the time forward to June
    and see what happens.
    
    Basically this is a trial run for the year 2000.

    
:    Given that we are just BLITZing now (or not even yet) and any site that
:    will have a problem will have it in only two months time, it is *not*
:    reasonable IMHO to tell customers to upgrade to a current release of
:    VMS. For many sites with lots of interdependent layered products and
:    third party software and demanding availability requirements, two
:    months is simply not enough elapsed time for a VMS upgrade.

   You're right.  We've been telling this customer and others to upgrade
   to V5.5 or later if they want support -- this message has been going
   out to customers for quite some time.

   We (OpenVMS engineering; DIGITAL) cannot continue `no-cost' engineering
   support for a release six full OpenVMS releases back, excluding an
   assortment of hardware and `dash' releases.
    
   A patch for most instances of this problem (fixed RTLs) has been available
   for V6.1 and later for circa six months -- though the *LIB05* patch fixes
   a few other areas (fixed OLBs, for those that avoid use of RTLs) where
   this problem was found lurking.  (Note that folks that link against the
   OLBs *will* need to relink their application(s).)

.34:    before you do that, you might want to have the customer assess whether
.34:    the problem even affects them.

   It likely does not, but .30 needs to read through the notes in this
   string and confirm this in the customer's source code.

 To update this string and highlight a few points...

   re: .30 YoungLee, Is there a 10k Patch for V5.4?  
           The answer is "No" and there are two reasons for it
             First, As numerous folks have pointed out, OpenVMS Engineering
                    had determine "how far back" is reasonable and feasible.
                    It was agreed that going back to Version 5.5 met that
                    criteria especially in light of the second point.

            Second, In Version 5.4 the problem does not occur in the most
                    common place DECthreads. So a version 5.4 application
                    will just need to assure that they are not effected by 
                    improper coding practices. 

   re: .26 Ray Fusci, Version 5.5-2 and 10K patch causing problems.
           
          The testing group in OpenVMS engineering performed some extensive
          testing on numerous configurations running 5.5-2.  After your
          note here, the patch was successfully re-tested and test engineering
          has been unable to reproduce the problem.
            Ray, I realize that Testing engineering has been in contact with
          you. I would just like others to test 5.5-2 as well to see if this
          is a problem particular to your configuration.

   re: .19&earlier John Gillings, "Why not MUP it?"

          John, we went around and around on this issue and this was not a
          trivial "oh just ECO it decision". In the end, the reason we 
          decided not to MUP it was mostly due to accessibility of our fixes
          over the web combined with:

            1.) The current shipping version of the operating system 7.1
                was built with the fix in it and it's available now.

            2.) The "Obvious" base operating system problems with this 
                problem are on the Alpha V7.0 release.  Note that even
                these "obvious" 7.0 problems do not crash the system.
          
             3.) A fix/"patch", has been available for the 6.1 & 6.2
                 releases for some time now.

           That said, we realized that this is a serious issue and that
           needs our customers to be alert to the fact that their
           application could experience an error with this restriction. 
           Thus the reason for the notification letter. 

           Note that in some cases the SSB can produce CD-ROM's of
           patches for customers. I believe the Australian contact to
           the SSB would be ZGOVC::AGNESSEK.

                                          - Leo Demers
                                          OpenVMS & SEVMS 
                                          Security Product Manager
                                          Tel: (603)881-2245
                                          DTN:381-2245

This is the most concrete information I have had to date on V5.5-2 problem
reports (thank you Dave Levy).  Still need 2nd site confirmation.

What happens when you run AUTOGEN?  Does the system crash?

Example:

           $ Submit/Keep/NOPrint/Queue=System$Queue               -
                 /Log=sys$manager:/User=System/after=15:00               -
                 /Param=("SAVPARAMS","SAVPARAMS")                        -
                 sys$update:autogen.com


Grahame

I have a customer who installed VAXLIBR05_070 on VMS V5.5-2 and now the system
continually crashes during boot. The crash is a Kernal Stack not valid 
(KRNLSTAKNV) in DECPS-DC (PSDC$DC_SERVER.EXE) with a PC of ACP$MOUNT+0008F.

I've also been able to reproduce the problem on an offline machine using a
VAXSTATION 3100, VMS V5.5-2, DECPS-DC V2.2 and DECWINDOWS/MOTIF V1.2-4.

This is on a customer site so its not easy to make the dump available but it
appears to be readily reproduceable using the above configuration.

Please let me know if further details are required.

Geoff..

    Geoff,
    
    could you somehow make the dump available on the Easynet or at least
    obtain a CLUE file from this dump and send it to the CANASTA Mail
    Server. I can then have a look at the CLUE file and write a CANASTA
    troubleshooting rule for it.
    
    Please see note 233 for more information.
    
    Volker.

[OpenVMS] System Crashes With KRTNLSTAKNV At ACP$MOUNT+0008F


     Any party granted access to the following copyrighted information
     (protected under Federal Copyright Laws), pursuant to a duly executed
     Digital Service Agreement may, under the terms of such agreement copy
     all or selected portions of this information for internal use and
     distribution only. No other copying or distribution for any other
     purpose is authorized.

Copyright (c) Digital Equipment Corporation 1995, 1996.  All rights reserved.

PRODUCT:     OpenVMS VAX, Version 5.5-2

COMPONENTS:  Files-11 ODS-1 ACP
             Bugcheck

SOURCE:      Digital Equipment Corporation


SYMPTOM:

A system crashes with the following insufficient kernel stack
space to build the ACP buffer error:

     KRNLSTAKNV, Kernel stack not valid

NOTE:  Output from a crash dump analysis is included in the CRASH
       DUMP ANALYSIS section at the end of this article.  Please refer
       to this section to determine if you are experiencing the same
       problem described in this article.


SOLUTION:

According to OpenVMS Engineering, this problem is corrected in OpenVMS
VAX, Version 6.0.
\
\
\ ENGINEERING RESPONSE:
\
\ Our research indicates that this problem is fixed for 5.5-2 by
\ installing CSCPAT_1120 which is VAXMSCP08_U2055.  The kit is now
\ called VAXSHAD04_061.
\
\ The following is the answer received for V551-FT #00264:
\
\ A fix for this problem has been coded and checked into
\ the Blade stream.  The fixed code now attempts to first
\ use a KRP for the temporary space needed.  If no KRP is
\ available, it attempts to allocate some paged pool,
\ and if that is not available, it attempts to probe the
\ kernel stack.  If it is successful in any of these
\ attempts, it carries on and releases the temporary space
\ when it is finished.  If all attempts at allocating
\ the temporary space fail, the user's I/O request
\ is aborted.


WORKAROUND:

The ECO kit VAXSHAD may address the problem described in this article.
Refer to the ECO-SUMMARY article to determine if this ECO corrects the
problem for your specific configuration.  More information regarding this
kit may be found in the ECO-SUMMARY database by using a query of
VAXSHAD.
\
\    Note:  TIMA users should access the TIMATOOLS ECO_MUP_CERT database
\           to view the ECO-SUMMARY information.


CRASH DUMP ANALYSIS:

The following crash dump analysis may be helpful in determining if you
have experienced this problem:

Time of system crash: 20-JUL-1994 09:12:06.45
Version of system: VAX/VMS VERSION V5.5-2
System type: VAX 4000-500
CPU 00 reason for Bugcheck: KRNLSTAKNV, Kernel stack not valid
Process currently executing on this CPU: DECPS_DC
Current IPL: 31  (decimal)
CPU database address:  83AE0000

General registers:

        R0  = 80002000   R1  = 004E2408   R2  = 82FC89CC   R3  = 82FC89A0
        R4  = 810A9840   R5  = 80FEF350   R6  = 7FF743A0   R7  = 00000032
        R8  = 81730994   R9  = 00000032   R10 = 00000050   R11 = 7FFE7194 <-n.b.
        AP  = 7FFE7328   FP  = 7FFE72B4   SP  = 83AE11F8   PC  = 803AD544
        PSL = 041F0000

Processor registers:

        P0BR   = 879A5A00     SBR    = 0BABEA00     ASTLVL = 00000004
        P0LR   = 00002892     SLR    = 0014A580     SISR   = 00000000
        P1BR   = 8732D800     PCBB   = 09966C20     ICCS   = 00000041
        P1LR   = 001FF90C     SCBB   = 0BAA9C00     SID    = 13000202

Processor registers:

        P0BR   = 879A5A00     SBR    = 0BABEA00     ASTLVL = 00000004
        P0LR   = 00002892     SLR    = 0014A580     SISR   = 00000000
        P1BR   = 8732D800     PCBB   = 09966C20     ICCS   = 00000041
        P1LR   = 001FF90C     SCBB   = 0BAA9C00     SID    = 13000202

        ISP    = 83AE11F8
        KSP    = 7FFE7194
        ESP    = 7FFE9800
        SSP    = 7FFED800
        USP    = 7FF23F90

                83AE11D8  00000032
                83AE11DC  00000050
                83AE11E0  7FFE7194      CTL$GL_KSTKBASEXP+00794
                83AE11E4  7FFE7328      CTL$GL_KSTKBAS+00128
                83AE11E8  7FFE72B4      CTL$GL_KSTKBAS+000B4
                83AE11EC  83AE11F0
                83AE11F0  803AD544      EXE$MCHECK
                83AE11F4  041F0000

         SP =>  83AE11F8  80419C39      ACP$MOUNT+0008F
                83AE11FC  00020000      UCB$M_LCL_VALID
\
\ This code stream results in accessing a page beyond the limits of the k-stack:
\
\ ACP$MOUNT+00071:  BSBW    IOC$TESTUNIT+00092
\ ACP$MOUNT+00074:  MOVZWL  #007C,R0
\ ACP$MOUNT+00079:  BRB     ACP$MOUNT+00080
\ ACP$MOUNT+0007B:  MOVZWL  #0064,R0
\ ACP$MOUNT+00080:  BRW     EXE$ABORTIO
\ ACP$MOUNT+00083:  MOVAB   -0118(SP),SP
\ ACP$MOUNT+00088:  MOVL    SP,R11
\ ACP$MOUNT+0008B:  MOVZBL  #50,R10
\ ACP$MOUNT+0008F:  MOVL    #04,(R11)+
\
\ Process page table
\ ------------------
\
\         ADDRESS     SVAPTE    PTE       TYPE  PROT  BITS PAGTYP    LOC
\ STATE TY
\ PE  REFCNT   BAK       SVAPTE    FLINK      BLINK
\
\        7FFE7000    8DFC20E0 04000000    PGFIL NONE     K
\        7FFE7200    8DFC20E4 D4082860    VALID SRKW M L K PROCESS ACTIVE
\ 07   0
\ 0      1   04000000   8DFC20E4  00000000  0000006B
\        7FFE7400    8DFC20E8 D4082861    VALID SRKW M L K PROCESS ACTIVE
\ 07   0
\ 0      1   04000000   8DFC20E8  00000000  0000006A
\        7FFE7600    8DFC20EC D4082862    VALID SRKW M L K PROCESS ACTIVE
\ 07   0
\
\ The code:
\
\ .SBTTL  BUILD ACP BUFFER
\ ;
\ ; Subroutine to build ACP buffer and interlock the UCB. This routine
\ ; probes the function dependent parameters and builds the complex
\ ; buffer packet that is to be shipped off to the ACP (or XQP).
\
\ ;
\ ; To avoid an extra subroutine call in the main FDT routines, this
\ ; routine also redirects the I/O function to the UCB of the open file
\ ; (if any, on disk) and takes out the UCB fork lock.
\ ;
\ ; Inputs:
\ ;
\ ;       R3 = address of I/O request packet.
\ ;       R4 = current process PCB address.
\ ;       R5 = assigned device UCB address.
\ ;       R6 = address of CCB.
\ ;       AP = address of first function dependent parameter.
\ ;
\ .ENABL  LSB
\ BUILDACPBUF:                        ; build ACP buffer
\        MOVAB   -MXDESCR*8(SP),SP    ; allocate space for maximum descriptors
\        MOVL    SP,R11               ; set address to store descriptors
\        MOVZBL  #ARB$L_UIC+4+16,R10  ; set initial byte count
\        MOVL    #4,(R11)+            ; insert window address length and access
\                     |- crash now as r11 points to a page beyond the current
\                                        kernel stack limits
\
\
\ TESTING INFORMATION:
\
\ Has this issue been reproduced on CSC lab systems? no
\     Explain: The issue seems to be documented.
\
\ Is this issue consistently reproducible at the customer site? n
\     Explain: Not reproducible, but repeated.
\
\
\ REFERENCES:
\
\ Escalations reported on this problem:
\
\      CHAMP/CSC Service Request (SRQ) #:  C940720-989
\      Field Service Log #:  HPAQ835D5
\      QARs:  V551-FT #00264   SPR_VMS_V5 #04056
\
\
\ CONTRIBUTORS:
\
\      Technical:
\           P. J. Mills (154151)
\           Reuven Somberg (173834)
\
\      Editorial:
\           Judy Mautino (216077)
\
\\ VMS F11ACP BUGCHK
\\ PROD=OPENVMS-VAX SPD=25.01 CAT=OPSYS GRP=OPENVMS-VAX OS=OPENVMS-VAX
\\ 154151 173834
\\ HPAQ835D5 SRC940720000989
\\ EDIT_SRQ=C950414-5621 EDIT_SRQ=C950414-5621 EDIT_SRQ=C960621-5416
\\ CSCPAT VAXSHAD
\\ QREVIEW=199612 TYPE=ESCALATION TYPE=KNOWN_PROBLEM TYPE=ECO FIXEDSSB
    

Volker,

< [OpenVMS] System Crashes With KRTNLSTAKNV At ACP$MOUNT+0008F

Yes I also saw that article in TIMA. I just installed VAXSHAD09_u2055 on both
machines that broke after installing VAXLIBR05_070 on V5.5-2 and it fixed 
the problem. 

This needs to be added to the release notes. From what I've seen it is
mandatory if DECPS-DC is installed but who knows what other applications may 
show up this problem.

Thanks,
Geoff..

    
    I have a customer who is now having problems after installing both
    Alpha and VAX ECOs.  On the VAX, running 5.5-2, the system now
    continually crashes.  On the Alpha, they claim that the Delta time
    patch did not work.  I have no more details as of now.  This could be a
    major problem for my large installed base of banks here in NY.  I would
    like to know, sooner rather than later, if I need to stop my customers
    from installing these ECOs.  Thank you.
    
    

: I would like to know, sooner rather than later, if I need to stop my
: customers from installing these ECOs.  Thank you.

   Uh, where's the high-priority IPMT reporting the 10K crashes?

    We have a customer with same autogen crashing problem on 5.5-2
    after installing vaxlibr05_070. We do not have access to the dumpfile.
    Customer installed the SHAD kits and the crashes did not go away.
    

re .42
    
>  On the Alpha, they claim that the Delta time
>    patch did not work.  I have no more details as of now.
    
    At the very least, if they have a C compiler installed, have them run
    the program supplied in the BLITZ (? - at any rate in one of the
    postings in this topic). This will make a minimal test as to whether
    one of the RTL functions that should have been changed in behaviour by
    the patch has so done.

    Re: .43
    
> : I would like to know, sooner rather than later, if I need to stop my
> : customers from installing these ECOs.  Thank you.
>
>   Uh, where's the high-priority IPMT reporting the 10K crashes?

    I'm not sure what an IPMT is but the log number at Mission Critical
    support center is C970311-5140.  Rob Hansen in mission critical is
    working on this, and also Mark Michaud in Sustaining Engineering.
    
    Citibank also passed this along to Bankers Trust who is now demanding
    answers from us.  This is turning into an avalanche for me.  I just
    need to know what to tell my customers.  Thanks.
    
    

   I'd appreciate some exposure of the program in 238.46, for V5.5 and
   later OpenVMS VAX, and V6.1 and later OpenVMS Alpha.  (I've tested
   it on various OpenVMS versions, but don't have access to a wide
   variety of releases.)

$
$! SHOW10K.COM
$!
$! DCL procedure to build and run the SHOW10K.MAR program
$!
$! This procedure creates and runs a test program, and the test
$! program determines if the ALPLIBR05_070 (or later) or the
$! ALPLIBR05_070 (or later) 10Kday delta-time patch has been
$! applied to the local system...
$!
$
$ if f$int(f$getsyi("SID")) .eq. -2147483648
$ then
$   ! SID = %x80000000 if this is not a VAX...
$   macro_opt = "/MIGRATE"
$   link_opt = "/NOSYSEXE"
$   write sys$output "Building test for ALPLIBR05_070 (or later) patch..."
$   write sys$output "(For OpenVMS Alpha V6.1 or later)"
$ else
$   ! SID != %x80000000 if this is a VAX...
$   macro_opt = " "
$   link_opt = "/NOSYSSHR"
$   write sys$output "Building test for VAXLIBR05_070 (or later) patch..."
$   write sys$output "(For OpenVMS VAX V5.5-2 or later)"
$ endif
$
$ macro/object=sys$scratch:show10k.obj sys$input 'macro_opt'
	.TITLE	SHOW10K detects the presence of 10Kday patches
	.IDENT	/SHOW10K/
;
;****************************************************************************
;*                                                                          *
;*  COPYRIGHT (c) 1997 BY                                                   *
;*  DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS.                  *
;*  ALL RIGHTS RESERVED.                                                    *
;*                                                                          *
;*  THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED   *
;*  ONLY IN  ACCORDANCE WITH  THE  TERMS  OF  SUCH  LICENSE  AND WITH THE   *
;*  INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR  ANY  OTHER   *
;*  COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY   *
;*  OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE IS  HEREBY   *
;*  TRANSFERRED.                                                            *
;*                                                                          *
;*  THE INFORMATION IN THIS SOFTWARE IS  SUBJECT TO CHANGE WITHOUT NOTICE   *
;*  AND  SHOULD  NOT  BE  CONSTRUED AS  A COMMITMENT BY DIGITAL EQUIPMENT   *
;*  CORPORATION.                                                            *
;*                                                                          *
;*  DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE  OR  RELIABILITY OF ITS   *
;*  SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.                 *
;*                                                                          *
;*                                                                          *
;****************************************************************************
;
;++
; FACILITY:
;	OpenVMS
;      
; 
; FUNCTIONAL DESCRIPTION:
; 
;	This code probes for the presence of the 10Kdays patches;
;	the ALPLIBR05_070 and VAXLIBR05_070 (or later) patches. 
;
;       Please see the documentation associated with the patches
;       for details, see URL http://www.service.digital.com/, or
;       contact your local DIGITAL customer support center.
;
;	This code is deliberately linked against the STARLET.OLB
;	object library, to check for the existence of the LIB$
;	10K-Days-related patches in the object library.  (Both
;	STARLET.OLB and RTL shareable image changes are involved
;	in the ALPLIBR05_070 and VAXLIBR05_070, and later patches.)
;
;
; ENVIRONMENT: VAX or Alpha, user mode
; 
; AUTHOR: Stephen Hoffman, CREATION-DATE: 28-Feb-1997
;         Digital Equipment Corporation
;
; MODIFIED BY: 
;         Stephen Hoffman, 17-Mar-1997
;         Added conditional for V5.5-2 PR$_SID_TYP_NOTAVAX
;         behaviour, added the DCL build "wrapper"...
; 
; CONSTRUCTION:
;
;   Specification of the OpenVMS VAX /NOSYSSHR or the OpenVMS Alpha
;   /NOSYSEXE qualifier is required for proper operation of the test.
;
;   OpenVMS VAX:
;	$ MACRO SHOW10K
;	$ LINK SHOW10K/NOSYSSHR
;	$ RUN SHOW10K
;
;   OpenVMS Alpha:
;	$ MACRO/MIGRATE SHOW10K
;	$ LINK SHOW10K/NOSYSEXE
;	$ RUN SHOW10K
;--
;
        .LIBRARY        /SYS$LIBRARY:LIB/
        $LIBDEF
        $LIB$ROUTINESDEF
        $PRDEF
        $SSDEF
        $SYIDEF


;
; the following block of print directives is suppressed, as the
; %AMAC-I-GENINFO messages these produce under OpenVMS Alpha
; MACRO/MIGRATE might trouble some users...
;
;	.print 0;Building tool to check for the *LIBR05_070 patch...
;	.print 0;...on OpenVMS VAX, use LINK/NOSYSSHR SHOW10K
;	.print 0;...on OpenVMS Alpha, use LINK/NOSYSEXE SHOW10K
;	.print 0;Then RUN SHOW10K

	.psect	$DATA,WRT,NOSHR,NOEXE,LONG

tenk:		.long	10000
deltatime:	.quad	0
opcode:		.long	LIB$K_DELTA_DAYS
PatchHeader:	.ascid	/Checking the need for the *LIBR05_070 patch.../
PatchLoaded:	.ascid	/...Patch has been applied, or is not required./
PatchAlpha:	.ascid	/...Patch ALPLIBR05_070 (or later) is required./
PatchVAX:	.ascid	/...Patch VAXLIBR05_070 (or later) is required./

	.PSECT	$CODE,NOWRT,SHR,EXE,LONG

	; if the PR$_SID_TYP_NOTAVAX symbol is not currently
	; available, create a local version of it now...  And
	; also assume that this is probably an older OpenVMS
	; VAX release, which means that the CALL_ENTRY macro
	; isn't around and that we should use .entry instead.
	
; SHOW10K main entry point...

        .IF NDF PR$_SID_TYP_NOTAVAX
        PR$_SID_TYP_NOTAVAX=128

	.ENTRY	show10k,^M<R9,R10,R11>
	.IF_FALSE
	.CALL_ENTRY	label=show10k, -
			preserve=<R9,R10,R11>, -
			max_args=0, -
			home_args=false
        .ENDC

	pushaq	PatchHeader		; output the "intro" message
	calls	#1,g^lib$put_output	; Introduce ourself...
	BLBC	R0,10$			; skip on error
	;
	pushaq	deltatime		; see if we can convert 10Kday...
	pushal	tenk			; ...interval to internal time.
	pushal	opcode			;
	calls	#3,g^lib$cvt_to_internal_time
	blbc	R0,20$			; branch on error
	;
	pushaq	deltatime		; see if we can convert 10Kday...
	pushal	tenk			; ...interval from internal time.
	pushal	opcode			;
	calls	#3,g^lib$cvt_from_internal_time
	blbc	R0,20$			; branch on error
	;
	pushaq	PatchLoaded		; output the "safe" message...
	calls	#1,g^lib$put_output	; ...no patch is required.
	BLBC	R0,10$			; skip on error
	movl	#SS$_NORMAL,R0		; force success
10$:	ret				; "leaving, what a good idea..."
20$:	;
	; decide which patch message -- VAX or Alpha -- is needed...
	;
	; Use a run-time $getsyi check to avoid the need for
	; ARCH_DEFS.MAR during the MACRO[/MIGRATE] operation.
	;
	clrl	-(SP)			; Create the buffer
	movl	SP,R11			; save address
	clrq	-(SP)			; null itemlist terminator
        clrl	-(SP)			; return length
        pushl	R11			; buffer address
        pushl	#<SYI$_CPU@16!4>	; Item code and buffer length
        movl    SP, R10                 ; Save the itemlist address.
 	clrq	-(SP)			; create an IOSB
	movl	SP,R9			; save address
        $GETSYIW_S -			; Get the CPU code
		ITMLST=(R10), -         ;   via system service
		IOSB=(R9)		;   at run-time
	blbc	R0,50$			; exit on error
	;
	cmpl	#PR$_SID_TYP_NOTAVAX,-  ; VAX CPU < 128; Alpha
 		(R11)			; (NOTAVAX) CPU = 128.
	beql	30$			; branch if Not A VAX
	pushaq	PatchVAX		; VAX patch needed...
	brb	40$			; branch to common code
30$:	pushaq	PatchAlpha		; Alpha patch needed...
40$:	calls	#1,g^lib$put_output	; display the message
	blbc	R0,50$			; exit on error
	movl	#SS$_NORMAL,R0		; force success
50$:	ret				; return to caller
	.END	show10k			;
$
$ link/execut=sys$scratch:show10k.exe sys$scratch:show10k.obj 'link_opt'
$ delete sys$scratch:show10k.obj;*
$ run sys$scratch:show10k
$ delete sys$scratch:show10k.exe;*
$
$ exit

    Edgar,
    
    for the moment, don't install this patch on V5.5-2. VSG is working on
    this problem and they will provide and document a solution ...
    
    Whenever you come across a crash, which you believe is caused by the
    installation of VAXLIBR05_070, please obtain the CLUE file and send it
    to the CANASTA Mail Server using the following command:
    
    $ MAIL clue-file XOCOMP::CAN_SERVER -
    	/SUBJ="DIAGNOSE CASE=log-number CUSTOMER=VAXLIBR05_070"
    
    If you don't have a log-number, just omit the 'CASE=log-number' string.
    This will EASILY allow us to collect ALL POSSIBLE FOOTPRINTS in
    CANASTA.
    
    If you don't have access to CLUE.EXE for OpenVMS VAX V5.5-2, you can copy
    it from HAN::USERDISK5:[HALLE.PUBLIC]CLUE.EXE.
    
    Volker.

Hmm - I tried your command procedure in .46 on an Alpha 6.2 system on which I
had installed the ALPLIB04 patch, and the procedure told me I needed LIB05.
I had thought LIB04 fixed the same problem...

				Steve

:Hmm - I tried your command procedure in .46 on an Alpha 6.2 system on which I
:had installed the ALPLIB04 patch, and the procedure told me I needed LIB05.
:I had thought LIB04 fixed the same problem...

   Nope, the test program is specifically coded to detect this (uh, well,
   it's specifically coded not to detect this), and to tell you to install
   the LIB05 (or later) kit.

   LIB04 fixed the RTLs.  LIB05 fixes STARLET.OLB, the RTLs, etc.

RE: .47

The procedure in .46 tests the object library, but not the
shareable image (which would affect most people) on VAX.
It does test the shareable image (LIBRTL) on Alpha systems,
but not the object library.


RE: .48.  The CSC sequence number you refer to does not cover
crash issues.  It is about the new patch not allowing for
the display of a 5 digit day field for delta times.  i.e.

	write sys$output f$cvtime("10000-","delta")

fails before and after the patch is applied.

Since you know Rob Hansen is working the case with your
customer (or at least Citibank), you may wish to keep
in contact with him and not such unofficial means
as this notes file.  

  re: "Delta-time Restriction fix";
	VAXAXP::VMSNOTES 340.0;
	CSC32::D_BROWN "Dave Brown CSC-VSG/INTDRV" 

:    	Regarding the delta-time restriction issue corrected by the
:    xxxLIBR05_070 ECO, do we at all have a fix for VAX V5.4-2 or are these
:    customers "on their own"?
:    
:    	The Bank of New York is asking. They have allot of V5.4-2 systems
:    running Allin1 and communicating with UNIX systems. They do not
:    necessarily want to upgrade just for this issue.

   The most recent Q & A explicitly covers this topic -- V5.5-2 is the oldest
   supported version and the oldest release that will have a readily available
   fix for this -- DIGITAL can be contracted to back-port these fixes to certain
   older releases, for a fee.

   But please read through the Q & A before you decide that you actually need
   these fixes -- DECthreads was what broke, and it does not exist in V5.4-2.
   And application code can fail, regardless of the presence of the fixes.
   (Exact application behaviour on 19-May-1997 depends on how the application
   was coded, and on how it was LINKed.  See the Q & A.)

.52:The procedure in .46 tests the object library, but not the
.52:shareable image (which would affect most people) on VAX.

   LIB05 includes both fixes -- if STARLET.OLB is fixed, so are
   the RTLs.

  re .47: Steve

  I've tried your procedure on a few systems - here are the results:

VAX		Unpatched	Patched
  V5.5-2H4	OK		(on hold)
  V6.1		OK		OK
  V6.2		OK		OK
  V7.0		OK		OK

Alpha
  V6.1				OK
  V6.2		OK		OK

  Sorry, I don't have an unpatched Alpha V6.1 to test on. 

  I've got a small herd of vax clusters here specifically for checking things
  on different versions. Let me know if you ever need this type of test in
  future. (maybe some day I'll scrounge enough Alphas to do the same thing).

						John Gillings, Sydney CSC

    What happened to the .C saveset for VAXLIB05??
    
    It seems not to be present on the www or ftp sites mentioned in the
    letter and there are reports on info-vax that it IS required.
    
    

>  re: "Delta-time Restriction fix";
>	VAXAXP::VMSNOTES 340.0;
>	CSC32::D_BROWN "Dave Brown CSC-VSG/INTDRV" 
>
>:    	Regarding the delta-time restriction issue corrected by the
>:    xxxLIBR05_070 ECO, do we at all have a fix for VAX V5.4-2 or are these
>:    customers "on their own"?
>:    
>:    	The Bank of New York is asking. They have allot of V5.4-2 systems
>:    running Allin1 and communicating with UNIX systems. They do not
>:    necessarily want to upgrade just for this issue.
>
>   The most recent Q & A explicitly covers this topic -- V5.5-2 is the oldest
>   supported version and the oldest release that will have a readily available
>   fix for this -- DIGITAL can be contracted to back-port these fixes to certain
>   older releases, for a fee.

Not only does the most recent Q&A address this, this problem was also 
escalated via the CLD/IPMT system (aka Marc Michaud's group) and they 
provided an answer (same as Steve's, above) last week.



>It is about the new patch not allowing for
>the display of a 5 digit day field for delta times.  i.e.
>
>	write sys$output f$cvtime("10000-","delta")
>
>fails before and after the patch is applied.
>
>Since you know Rob Hansen is working the case with your
>customer (or at least Citibank), you may wish to keep
>in contact with him and not such unofficial means
>as this notes file.  

As well, this problem was also escaled via the CLD/IPMT system (aka Marc 
Michaud's group).  My group was asked to provide an answer (last week), 
which again, was already covered elsewhere (in this case, the blitz).  



Mary

:    It seems not to be present on the www or ftp sites mentioned in the
:    letter and there are reports on info-vax that it IS required.

   I suspect that's the V5.5-x "subkit", and the V5.5-2 component is on
   engineering hold, pending resolution of some system crashes that subkit
   appears to provoke.  (I am unaware of any crashes provoked by any other
   subkits -- the patch kit should be installed on all systems other than
   those running V5.5-x.)

    Customers can access the test program, the 10K customer letter, and
    the (attached) 10K FAQ Q&A at the URL http://www.openvms.digital.com/.

--


                          OpenVMS Delta Time Limit Q&A

                 (OpenVMS RTL Library Routines Time Restriction)

              March 1997

              Q1: I've heard that certain OpenVMS RTL Library (LIB$)
              routines (described in the Delta-Time Limit customer
              notification letter) have a documented time restriction
              that can cause errors in some applications. Can you tell me
              more about this?

              A: The OpenVMS operating system RTL Library routines have a
              documented limit of ten thousand (10,000) days, and any
              software that uses these OpenVMS RTL Library routines
              to measure a time interval of 10,000 or more days will
              encounter run-time errors upon reaching this limit.

              The date 19-May-1997 is 10,000 days from the UNIX and C
              base date of 1-Jan-1970. Applications using the OpenVMS RTL
              Library routines with the time restrictions in conjunction
              with the UNIX or C base date will encounter problems with
              the conversion of the 19-May-1997 date and later dates.
              These dates exceed 10,000 days, and exceed the documented
              four-digit limit of the delta-time field. Other base dates
              will encounter this ten-thousand day limit at other times.

              DIGITAL has removed the 10,000 day limit in the OpenVMS
              RTL Library routines and SYS$NUMTIM in OpenVMS Version 7.1.
              Engineering Change Orders (ECOs) are available that remove
              this same limit in earlier versions of OpenVMS.

              Q2: What are the OpenVMS operating system RTL Library
              routines that have the 10,000 day restriction?

              A: The following OpenVMS RTL Library routines have the
              documented 10,000 day restriction. The ECOs remove this
              restriction.

              LIB$CVT_TO_INTERNAL_TIME      LIB$ADD_TIMES
              LIB$CVT_FROM_INTERNAL_TIME    LIB$SUB_TIMES
              LIB$CVTF_TO_INTERNAL_TIME     LIB$MULT_DELTA_TIME
              LIB$CVTF_FROM_INTERNAL_TIME   LIB$MULTF_DELTA_TIME
              LIB$CVT_VECTIM                LIB$CONVERT_DATE_STRING

              If your application calls the OpenVMS RTL Library (LIB$)
              routines listed above or the SYS$NUMTIM system service,
              you may encounter the 10,000 day restriction. Programs
              that might call the above routines, and that have followed
              the previously documented 10,000 day restriction will not
              encounter any problems.

              Applications that are written in DEC C and contain portable
              code that calls only ANSI time functions are not impacted.
              This is because the DEC C Run Time Library calculates time
              locally and does not call OpenVMS RTL Library (LIB$) time
              routines. These ANSI time functions are as follows:

              ctime            ftime
              mktime           strftime
              fstat            gmtime
              stat             time

              The one exception to this list is the ANSI time function
              sleep. The DEC C Run Time Library continues to enforce the
              9999 day delta-time limit on sleep.

              Q3: What applications are impacted by the OpenVMS RTL
              Library time restriction?

              A: The following OpenVMS components and software products
              are known to be affected by the RTL Library time
              restriction. The ECOs correct the problems observed in
              these products.

              ___________________________________________________________
              Product______________________________OpenVMS_Version_______

              OpenVMS SECURITY Server              OpenVMS Alpha V7.0 only

              DECwindows Motif for OpenVMS         OpenVMS Alpha V7.0 only

              Distributed Computing Environment    OpenVMS Alpha V6.2 only
              (DCE) for OpenVMS                    

              OpenVMS DECthreads                   OpenVMS Alpha and
                                                   OpenVMS VAX V5.5
                                                   through V7.0

              (OSU) DECthreads HTTP Server         OpenVMS Alpha and
              (freeware provided with the OpenVMS  OpenVMS VAX V5.5
              Internet_Product_Suite)______________through_V7.0__________

              Other software products running on OpenVMS might also
              experience errors stemming from the documented time
              restriction in the OpenVMS RTL Library routines. Contact
              the appropriate software vendor for more information.

              Q4: Which versions of the operating system are affected and
              who needs to install the ECO?

              A: DIGITAL strongly recommends that all customers running
              the following versions of the OpenVMS operating system
              install the appropriate ECO:

              o  OpenVMS Alpha Version 6.1 through Version 7.0
                 (inclusive):

                 OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2, V6.2, V6.2-1H1,
                 V6.2-1H2 V6.2-1H3, V7.0

              o  OpenVMS VAX Version 5.5 through Version 7.0 (inclusive):

                 OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2HW, V5.5-2H4,
                 V5.5-2HF, OpenVMS VAX V6.0, OpenVMS VAX V6.1, OpenVMS
                 VAX V6.2, OpenVMS VAX V7.0

              Systems running OpenVMS Alpha Version 7.1 and OpenVMS VAX
              Version 7.1 are not affected and do not need to install the
              ECO.

              Q5: Are these ECOs available for versions prior to OpenVMS
              VAX V5.5, or prior to OpenVMS Alpha V6.1?

              A: The VAXLIBR05_070 and ALPLIBR05_070 ECOs apply to
              OpenVMS VAX V5.5 through V7.0, and to OpenVMS Alpha 
              V6.1 through V7.0, inclusive. The ECO is not required
              for Version 7.1 and later. For customers running earlier
              versions, DIGITAL believes that it is unlikely that
              any OpenVMS-specific problems will be encountered as a
              result of the delta-time restriction, because the OpenVMS
              component most affected by this ECO, DECthreads, is
              available only on OpenVMS VAX Version 5.5 and later and
              on OpenVMS Alpha Version 6.1 and later.

              Regardless of the OpenVMS version and regardless of the
              installation of the ECO, application developers need to
              investigate and potentially repair, recompile and relink
              any local or third-party code that contains any instances
              of calls that might exceed the 10,000 day delta-time
              limits. Care is needed to relink those applications that
              are explicitly linked against OpenVMS object libraries and
              not against shareable images, because these applications
              will require this relink to incorporate the changes made by
              the ECO kit.

              Q6: What are the symptoms on systems running OpenVMS Alpha
              V7.0 without this ECO?

              A: On OpenVMS Alpha Version 7.0 systems, the following
              error may be displayed on the console which will cause the
              security server to hang.

           %CMA-F-EXCCOPLOS, exception raised: some information lost
           -CMA-F-BADPARAM, parameter to DECthreads operation is invalid
           %ADA-I-TASTERUNH, Task with ID %TASK 9 of type
           Verify_Dependant_Tasks_type has terminated due to unhandled exception

              The above messages stem from the SECURITY_SERVER. Service
              is not denied, but security event messages are not
              recorded.

              DECWindows Motif running on OpenVMS Alpha V7.0 systems
              will cease to function on or around 19-MAY-1997. This will
              prohibit users from logging into their workstations or from
              starting any new applications.

              Q7: Why is the OpenVMS SECURITY server impacted?

              A: The security server is affected only on OpenVMS Alpha
              V7.0. An error can occur when the OpenVMS Alpha SECURITY_
              SERVER attempts to log a message on the console. The
              date/time is handled as part of an exception that is
              initially managed by the DEC ADA Run-Time Library and is
              subsequently passed to DECthreads. DECthreads converts UNIX
              time to OpenVMS time by calling LIB$CVT_TO_INTERNAL_TIME,
              specifying the 10,000 day delta time. LIB$CVT_TO_INTERNAL_
              TIME returns an error to DECthreads on dates beginning on
              or around 19-MAY-1997 which results in the console errors.

              Q8: What symptoms will be seen on systems running OpenVMS
              Version 6.2 without the ECO?

              A: The OpenVMS DCE RPC Daemon (DCE$RPCD) fails to start on
              systems with the 10,000 day time restriction. In the files
              DCE$RPCD.ERR and DCE$RPCD.OUT, the DCE$RPCD process logs
              the following error:

              %CMA-F-BADPARAM, parameter to DECthreads operation is invalid

              This error is identical to the console scenario seen
              by OpenVMS Alpha V7.0 systems. There may be additional
              products or scenarios that yield this same result for the
              10,000 day time restriction.

              Q9: What is the impact on threaded applications?

              A: The 10,000 day issue only arises in cases where a
              UNIX time is converted to an OpenVMS time. The original
              implementation of the DECthreads interface did not involve
              any UNIX time specifications on OpenVMS. These were
              introduced with the implementation of the draft POSIX
              interface, which was layered on top of the original,
              proprietary (CMA) interface. Therefore, prior to Version
              7.0, only software that uses the draft POSIX interface (and
              which makes use of timed waits) is affected.

              In OpenVMS Version 7.0 DECthreads provided an
              implementation of the newly accepted POSIX standard
              interface for threading services. The POSIX standard
              interface became the core interface and the other
              interfaces were reimplemented on top of it. Beginning in
              OpenVMS Version 7.0, all software that uses timed thread
              waits may encounter the 10,000 day time errors.

              DECthreads source code is identical for OpenVMS VAX Version
              7.0 and OpenVMS Alpha Version 7.0.

              Q10: Do the ECOs affect the general delta-time system
              behavior?

              A: No, the basic user interface behavior and restrictions
              still apply except in SYS$NUMTIM and the OpenVMS RTL
              Library routines listed in Question 2. Delta-time
              specification strings still retain their 4-digit (dddd)
              field format for compatibility.

              Q11: If my application uses delta-time, what changes do I
              need to make in my code as a result of these ECOs?

              A: None. The ECO extends a current restriction in very
              specific areas that previously would have generated an
              error.

              Q12: Why do I still see a maximum of 10,000 days when I use
              F$CVTIME in my command files? I thought this restriction
              had been removed.

              A: Routines that use ASCII delta-time strings will see
              no change in their behavior or documented maximums.
              Specifically, $ASCTIM, $BINTIM, and F$CVTIME retain their
              current maximum sizes; only the parameter inputs to the
              affected LIBRTL routines will allow values greater than
              10,000 days.

              Q13: How does a customer obtain the ECO?

              A: Digital has provided the following ECOs (Engineering
              Change Orders) that remove the time limit and resolve all
              known instances of the error in OpenVMS:

                 For OpenVMS Alpha: ALPLIBR05_070
                 OpenVMS VAX: VAXLIBR05_070

              The ECOs can be obtained from the following locations:

              o  DIGITAL Electronic Service Delivery Tools (such as
                 DSNlink, Web Information and Support Service (WIS),
                 and DIGITAL Dial- In Access (DIA))

              o  the World Wide Web at:

                 http://www.service.digital.com/html/patch_main.html

                 To download the Alpha ECO, access the following URL:

                 http://www.service.digital.com:8031/?categories=
                 All_Databases&query_string=ALPLIBR05_070

                 To download the VAX ECO, access the following URL:

                 http://www.service.digital.com:8031/?categories=
                 All_Databases&query_string=VAXLIBR05_070

              o  the following FTP address:

                 ftp://ftp.service.digital.com/public/vms/

              Q14: What should a customer do if they cannot access the
              ECO from the electronic mechanisms?

              A: The customer should contact their normal support
              channels.

              Q15: If I am not sure if I will be affected by this Delta
              Time limit problem, should I still install the ECO?

              A: Yes, Digital strongly recommends that all customers
              running OpenVMS Alpha Version 6.1 through Version 7.0 and
              OpenVMS VAX Version 5.5 through Version 7.0 install the
              ECO.

              Q16: Does the customer have to do anything after the ECO
              has been applied?

              A: After the ECO has been applied, the system must be
              rebooted. If you have other nodes in your OpenVMS Cluster,
              they should also be rebooted.

              Application programs that LINK against the OpenVMS
              shareable images and the OpenVMS shareable image library
              will pick up the ECO when the program is next run, and
              should not need to be recompiled nor relinked.

              Applications that explicitly LINK with the STARLET.OLB
              object library, and that explicitly omit the OpenVMS
              shareable during the LINK, must be explicitly relinked
              in order to pick up the ECO.

              Q17: Do I need to reapply this ECO once I have applied it?

              A: Yes, this ECO will need to be reapplied immediately
              after each OpenVMS upgrade or update to any OpenVMS release
              prior to OpenVMS V7.1.

              This ECO should not be installed on OpenVMS V7.1 and later.

              This ECO does not need to be applied to any intermediate
              OpenVMS releases that might be involved during a sequential
              series of OpenVMS upgrades. It should only be applied to
              the final (pre-V7.1) OpenVMS release in the series.

              Q18: How will customers be notified?

              A: The OpenVMS Delta Time Limit Notification Cover Letter
              (which describes the documented time limits in the RTL
              Library routines and the required correction) has been
              included in the March 1997 OpenVMS SPL (Software Product
              Library) update kit. The letter will also be mailed to
              all OpenVMS MDDS (Media and Documentation Update Service)
              customers in March 1997.

              The Delta Time Limit Notification Cover Letter is
              also available on the WWW OpenVMS Homepage (http:/
              /www.openvms.digital.com) along with this Q&A.

              Q19: How can the system manager tell if the ECO has been
              applied?

              A: A DCL command procedure is available on the OpenVMS
              Homepage that you can run on each system to determine 
              if the ECO is applied.

Unfortunately, the FAQ 

	1) Is not sent to customers in the Notification Letter.
	2) Is not mentioned in the Notification Letter.
	3) Is not available with the patches kit.
	4) Is not pointed to by the patches kit.

<< Crossposted in VMSNOTES and VMS_PARTNERS >>

Folks, let me try to illustrate the problem I'm having out here in the
field.  Maybe a humorous, fictional story will work better:

Setting:	SomeCityBank's CIO's office
Attendance:	Digital Sales Rap, Digital Sales Support peon, customer CIO


CIO:	We installed this 10K patch and it crashed our VAX 5.5-2 systems,
	which is the version running on all our production machines.  You say
	you have a fix for this fix coming out soon?

Rap:	Yes, it should be out later this week or early next week.  We're
	testing it thoroughly to make sure there are no more surprises.

CIO:	Let me get this straight... You want us to install this patch on all
	our VAX systems globally?  In eight weeks or less?

Rap:	Yes, that would be best.

CIO:	Ok, it's gonna take a lot of time, effort, and pain.  We have over
	three hundred VAXes and Alpha all over the world.  And some we don't
	even know about.  Most of these machines are running mission critical
	financial and banking applications 24X365.  This is gonna be tough.
        We appreciate your proactiveness in sending out letters and putting
	this out on the net and newsgroups... but ... Why didn't you let us
	know sooner?  Eight weeks is hardly enough time.

Rap:	We understand your concern and we'll do everything we can to help you
	with this patch.

CIO:	And I understand we don't need to recompile our applications, right?

Rap:	Right.

Peon:	Umm... well... after the patch is installed, you need to determine
	whether you need to relink any applications.  Let me explain.  The
	patch fixes some library routines... blah blah... and if your
	applications people built the application using a shareable blah blah
	(as any good programmer eating twinkies would do) you won't have a
	problem, but if they linked with a private copy of the library... 
	blah blah...

CIO:	<after one minute of silence>
	Let me get this straight... not only do you want me to install this
	patch on all my systems globally, you also want me to search all my
	applications worldwide, determine if they're using an affected
	library call, figure out if my stupid programmers linked their image
	shareable, and if not, have them relink their applications and put
	them back into production???  And all this in eight weeks or less???
	Do you know how many thousands of applications we have???  And what
	about our DCL scripts using lexical functions?

Rap:	Only a small subset of your applications may even be affected.  The
	DCL lexicals won't be modified.

CIO:	Let me get this straight, with my DCL scripts, the maximum delta time
	returned is 10,000?  Even if the actual delta time, let's say, is
	10,234???

Rap:	Yes, that's the documented behavior.  At least the system won't crash
	though and you won't get an error message.

CIO:	Can I have your CEO's phone number please?

Peon:	That would be John Wiesniewski.  He's in Dallas.  You can probably
	reach him at his home though.  As we speak, he's probably installing
	this patch on all those microvaxes he's taken home.  It won't take
	him long though, he has two darling little girls to help him install
	the patch.

CIO:	We have extended warranty service don't we?

Rap:	Yes, you have our Gold premium, Platinum level, mission critical,
	24X365, 2 minute response time blah blah blah service.

CIO:	<starts pounding away on an Excel spreadsheet on his PC, prints out
	 a piece of paper and hands it to the rap> 
	Well then all this is covered, right?  Please present this bill to
	your CEO...

---------------------------------------------------------------------------
Patch installation	3 hrs. X 300 systems	900 hrs @ $30/	  $27,000

Search, modify,
relink, etc.		5 hrs. X 10K apps	50K hrs @ $30/	  $1.5M

Testing time		to be billed separately

Punitive damage							  $1M

Credit for being proactive					- $500K
								-----------
								$2,027,000
----------------------------------------------------------------------------

Folks, this story was meant to be funny and I hope no one gets offended,  but
the message behind it is serious.  Please understand that to our customers,
especially our huge installed bases, this is pretty serious stuff, and I'm the
one who's gotta go down there and face these people.  So don't ask me about
IPMTs and CLDs and blah blah blah...  I'm not following a specific case.
But I have a ton of customers who want me to answer their concerns.  I've
already been asked to go down to Banker's Trust to do a presentation on this.
The news is spreading like wildfire among the banks.  These people talk to
each other and most of the banks are already aware of what happened at
Citibank.  I need help in giving the customers the right messages and the
warm and fuzzies.  Thanks.
    

   Various of the "right" folks here in OpenVMS engineering and in product
   management are aware of where (at least some of) various associated
   management, development, testing, and communications problems are now
   known to exist, as a result of this 10K patch "adventure".

   Several of the engineers -- myself included -- view this as "just
   a warm-up" for Y2K.  (The Y2K managers have been following this
   situation, too -- we've learned about VMS V5.4 sites, etc...)

   As for the bugs in the applications, we have told folks they should
   not use values over 9999 in a delta-time conversion for many years.
   (I remember seeing this shortly after I started programming on VMS.)
   (And yes, we engineered some code that contained this conversion
   error -- which is at the core of the whole 10K patch effort...)

   The original patches for post V6 versions have been available for
   quite some time -- the 10K effort got started around late December
   1997...

   And no, I won't say we won't repeat these problem(s) next time.  :-(

   Please congradulate John on his promotion.  :-)

    
>    The original patches for post V6 versions have been available for
>       quite some time -- the 10K effort got started around late December
>       1997...
        ^^^^
    
    Jumping ahead ?? ;)

re .61;

If I remember what BT does for a global synch., your cost estimates are way 
too low! BT should be simply thrilled about this...

\dave
(who'd be facing similar abuse at NYMEX if the system were in production)

--------------------------------------------------------------------------------
    re:  238.58
       
    >I suspect that's the V5.5-x "subkit", and the V5.5-2 component is on
    >engineering hold, pending resolution of some system crashes that subkit
    >appears to provoke.  (I am unaware of any crashes provoked by any
    >other...
    
    Is there a clear ETA established yet for the remedial/replacements for
    the v5.5-* installations?
    
    As you've seen in previous notes...this is causing more than just a bit
    of a customer(s) problem.....folks need help quickly :^)
    
    rich
    
    
    

   Rich, I know you have direct (non-NOTES) contacts in engineering.

   I am not aware of an announced ETA -- other than "as soon as we can
   get this problem resolved, tested, and out the door"...

    re .61
    
    Having installed the patch myself a few weekends ago, it took only
    around 20 minutes (including "messing around"). The requirement for a
    reboot (what a bitch!) could however make this much higher in some
    environments.
    
    Distributing the patch could itself be a significant cost (time and
    money) if you have many sites.
    
    Considering that you are talking about mission critical systems, they
    all have staging machines, right? If so, don't forget to set the time
    forward on the staging machines and verify the correct functioning of
    the applications once the patch is installed.

    
    I have a manufacturing site running VMS V5.5-2 that will need this
    patch also. This is a 24*7 environment. The downtime is tentatively
    scheduled for April 6th (in 12 business days!). Besides monitoring this
    note, is there something I could be doing to expediate the fix for
    VMS V5.5-2?
    
    brian
    CCS - Whatever It Takes!

    >OpenVMS engineering is well aware this is a hot issue
    
    At the CSC we are becoming inundated with calls asking when the 5.5-2 
    fix will be available.
    
    Can you say what timescales we are looking at before it is available ? 
    A week, two weeks, a month ?
    
    I assume it will be included in a new version of the VAXLIBR kit.
    
    Thanks for any further info on this.
    
    Regards            
    
    Royston
    UK CSC

        We have a system running VMS V5.3-1 and an upgrade at this point is
        considered a last resort option. I understand Digital's policy with
        respect to support of earlier versions but I would like to know if this
        version is prone to the same 10K day delta time limitation. If this
        version is in fact affected, then is it even possible to create a
        patch? If cost is the issue then the BU is willing to negotiate due
        to the fact that a mission critical application is running on this
        system.
    
        Jeremy Bard
        CCS Canada 621-4746

re: 238.72  OTOOA::BARD
            -< VMS Delta Time For Non Supported VMS Versions >-

    The underlying 10Kday problem -- as should become clear if folks
    would please read through the Q&A -- is a direct result of the
    overflowing a documented day-one limitation on the total length
    of the day field in the text delta-time format used by OpenVMS.

    DECthreads mis-used the delta-time format for a conversion, and
    this will cause certain routines in the DECthreads RTL and certain
    callers of the DECthreads RTL to fail on or about 19-May-1997.

    Application and third-party code that is not cogniscent of the
    delta-time text format will fail whenever the delta-time conversion
    exceeds 10,000 days.  If the code assumes the UNIX/C base date of
    1-Jan-1970 as part of the conversion, the code will fail on or
    about 19-May-1997.

    The patch kit raises this limit in LIBRTL, allowing a longer day
    field in the delta-time text format string.

    Following the evaluation steps described in the Q&A, one can
    determine if the customer or third-party code needs to be
    recoded, or needs to have the patch applied.  (There are
    cases -- also mentioned in the Q&A -- where OpenVMS itself
    needs the patch applied.  Salient example: the OpenVMS Alpha
    V7.0 release.)

    If the customer would like to negotiate a back-port of the
    patch, or would like assistance in determining of the site's
    local code is affected, should contact DIGITAL MCS.

    OpenVMS V7.1 is the current release, and this release does
    not require the patch.

    Can someone who is familiar with Distributed Computer Enviroment (DCE)
    help me put this customer's mind at ease. He insist the cover letter is
    in error and DCE other than just 6.2 is in danger of failing because
    DCE uses DECthreads and DECthreads 5.5 thru 7.0 are affected.
    
    Thanks in advance.
    
    
	Jim,

	Here is my question (C970319-6036):

	The information included below, supplied by Digital, suggests that the
	delta-time limit would not affect DCE except on OpenVMS Alpha, V6.2.

	I think DCE could be affected on any VMS system where DECthreads are
	affected, because I think DCE uses DECthreads. Perhaps the author of
	the information overlooked that possibility. If I am right, DCE would
	be affected on OpenVMS VAX and OpenVMS Alpha, V5.5 thru 7.0.

	Only someone in DCE engineering would be able to answer this question
	in a definitive manner. Please submit the question to the DCE 
    	engineering group.

	Thank you,
	Erik Basilier, Motorola

*OpenVMS] VAXLIBR06_070 VAX V5.5 - V7.0 LIBRTL ECO Summary


COPYRIGHT (c) 1988, 1993 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.

Copyright (c) Digital Equipment Corporation 1996, 1997.  All rights reserved.

INSTALLATION NOTES:  If your system is running OpenVMS VAX V5.5-2* *AND*
                     you installed VAXLIBR05_070 on that system, in order
                     to avoid possible system crashes, you *MUST* install 
                     this kit, VAXLIBR06_070, on your system.

                     If your system is running OpenVMS VAX V5.5, V5.5-1,
                     V6.0, V6.1, V6.2 or V7.0 and VAXLIBR05_070 has been
                     installed on your system, you *DO NOT* need to install 
                     this kit, VAXLIBR06_070.

                     If your system is running OpenVMS VAX V5.5, V5.5-1,
                     V5.5-2*, V6.0, V6.1, V6,2, or V7.0 and VAXLIBR05_070
                     has not been installed on your system, you *MUST*
                     install this kit, VAXLIBR06_070, on your system.

OP/SYS:      OpenVMS VAX

COMPONENTS:  For OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF
                             and V6.0:

                LIBRTL.EXE
                LIBRTL2.EXE  
                MESSAGE_ROUTINES.EXE
                STARLET.OLB - Updated with LIB$DATE_ARITHMETIC and 
                              LIB$DATE_CVT

             For OpenVMS VAX V6.1, V6.2, and V7.0:                

                LIBRTL.EXE
                LIBRTL2.EXE  
                LIBRTL_INSTRUMENTED.EXE
                MESSAGE_ROUTINES.EXE
                STARLET.OLB - Updated with LIB$DATE_ARITHMETIC and 
                              LIB$DATE_CVT

             For OpenVMS VAX V5.5 through V7.0:

                LIBRTL$ECO_DROP.COM (If desired, this command file
                                     may be used to remove the ECO
                                     and restore the original
                                     files and libraries.  If this
                                     file is used to remove the kit
                                     from the system, the system 
                                     needs to be rebooted after the
                                     successful removal of the kit.)

SOURCE:      Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXLIBR06_070
     ECO Kits Superseded by This ECO Kit:  VAXLIBR05_070
                                           VAXLIBR02_070
                                           VAXLIBR01_070
                                           VAXLIBR02_062
                                           VAXLIBR01_062
     ECO Kit Approximate Size:  4770 Blocks
                   Saveset A -   126 Blocks
                   Saveset B -   378 Blocks
                   Saveset C -   396 Blocks
                   Saveset D -   414 Blocks
                   Saveset E -  1134 Blocks
                   Saveset F -  1152 Blocks
                   Saveset G -  1170 Blocks

     Kit Applies To:  OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, 
                                  V6.0, V6.1, V6.2, V7.0
     System/Cluster Reboot Necessary:  Yes

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

     NOTE:  In order to receive the full fixes listed in this kit,
            the following remedial kits also need to be installed:

            None

ECO KIT SUMMARY:

An ECO kit exists for the LIBRTL routines on OpenVMS VAX V5.5 through
V7.0.  

Problems addressed in the VAXLIBR06_070 kit for OpenVMS VAX V5.5-2,
  V5.5-2H4, and V5.5-2HF *ONLY*:

  o  The VAXLIBR05_070 remedial kit contains a fix that causes a
     Kernel Stack Not Valid Bugcheck which resulted in a system
     reboot.  This appears to happen under two circumstances:

     +  The system has at least one secondary pagefile installed and 
        AUTOGEN is run with preserve feedback (i.e., AGEN$FEEDBACK.EXE 
        is run).

     +  The Polycenter DECps product is installed and run on the
        system, specifically the Data Collection portion DECps-DC.

        If either of the above are run after the VAXLIBR05_070 kit has
        been installed on V5.5-2*, the system will crash.

        NOTE:  This is only a problem for customers running V5.5-2*.  If
               you are running a version other than V5.5-2* and have
               installed the VAXLIBR05_070 remedial kit, you do not need 
               to install the VAXLIBR06_070 kit.

  o  Possible memory leak when calling lib$get_vm.

  o  The message length field in the message sent to the queue
     manager can get corrupted when the buffer size exceeds 64K and
     the user process can obtain 64K of P1 space.

  o  Sometimes, during a heavy system load, a process may lose the
     response to a queuing request and the command will hang
     indefinitely.

  o  In order to correct a problem where the batch/print queue
     manager can lose a connection to one of its client nodes
     (after a failover), the $SNDJBC system service has added the
     new status return code QMAN$_RETRYLINK.  This informs the
     queue manager to attempt to re-establish its link to this
     client node.

     The new status is returned when the client node detects that
     the queue manager is attempting to link, but context for a
     previous link still exists.

     However, in order to correct the lost connection problem, you
     must be running a version of the queue manager which
     recognizes the new QMAN$_RETYRLINK status code.

     Queue manager versions beginning with OpenVMS VAX V6.0 contain
     the update which recognizes the new status code.  The update
     is also available in the remedial kit VAXQMAN03_070.   

     If you are experiencing the lost connection problem (a very low
     probability event), and have installed the VAXLIBR06_070 kit,
     you may see OPCOM messages similar to the following (on the
     operator console or in the operator log file):

        %%%%%%%%%%%  OPCOM   6-AUG-1992 15:06:00.26  %%%%%%%%%%%
        Message from user QUEUE_MANAGE on SUMNODE
        %QMAN-E-COMMERROR, unexpected error #5 in communicating
        with node CSID 0008000B

        %%%%%%%%%%%  OPCOM   6-AUG-1992 15:06:00.28  %%%%%%%%%%%
        Message from user QUEUE_MANAGE on SUMNODE
        -QMAN-W-NOMSG, Message number 04FE8678

  o  Allow lower case months to be entered to the $BINTIM system
     service.


Problems addressed in the VAXLIBR05_070 kit for OpenVMS VAX V5.5, V5.5-1,
  V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1, V6.2 and V7.0:  

  o  The OpenVMS operating system has a documented delta-time
     restriction that may cause an error in some applications and
     OpenVMS components beginning on or around 19-MAY-1997.  This ECO
     corrects this potential problem by removing the delta-time limit. 

     Applications and OpenVMS components most likely to experience
     errors are those that pass delta-time arguments with values
     exceeding 9999 days on system-supplied date routines.  The most
     likely date that these errors will occur is 19-MAY-1997:00:00,
     which is 10,000 days after the common UNIX time origin of
     1-JAN-1970. 

     This problem is fixed in OpenVMS VAX V7.1.
  

Problems addressed in the VAXLIBR02_070 kit for OpenVMS VAX V6.1, V6.2,
  and V7.0:

  o  Heaps that are removed from the heap pending list are only
     merged with the most recently returned heap.  This can lead to
     heap fragmentation (LIB$VM_REALLOC fragmentation).


Problems addressed in the VAXLIBR01_070 kit for OpenVMS VAX V6.1, V6.2,
  and V7.0:

  o  LIB$FID_TO_NAME has been modified to ensure that the use of
     very deep directory trees do not result in the call stack
     being corrupted.

  o  The 10,000 day limit in LIB$CVT_TO_INTERNAL_TIME causes
     problems for DECthreads since it is using this routine to
     convert UNIX times to VAX time.  It will fail to work on
     19-May-1997.


Problems addressed in the VAXLIBR02_062 kit for OpenVMS V6.1 and V6.2:

  o  When setting host into a DECnet PhaseV system, the logical name
     SYS$REM_NODE is incorrectly set.  When the code was originally
     written there was no support for node synonyms.  The value for
     SYS$REM_NODE is currently coming from a NET$K_TAG_COMPRESSEDNAME
     request but needs to be set from a NET$K_TAG_NODESYNONYM request.


Problems addressed in the VAXLIBR01_062 kit for OpenVMS V6.2:

  o  Due to an integer overflow, LIB$CVT_DX_DX returns a status of            
     00158334 (LIB$_INTOVF) when converting '-2147483648' to quadword.        
                                                                              


RELATED ARTICLES:

Detailed articles describing the problems listed above may exist in the
OPENVMS database.  To view these articles, open the appropriate product
database and perform a query using either of the following search
strings: 'VAXLIBR06_070' or 'VAXLIBR'.


ECO KIT ORDERING INSTRUCTIONS:

If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool.  If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:

  [AES] How To Electronically Request ECO Kits Using Service Tools


INSTALLATION NOTES:

In order for the corrections in this kit to take effect, the system
must be rebooted.  If the system is a member of a VMScluster, the
entire cluster should be rebooted.

NOTE:  If you are not running version 5.5-2* and have already installed
       the VAXLIBR05_070 remedial kit, you do NOT need to install
       VAXLIBR06_070.

Hi,


We have customers that do not have STARLET.OLB on their runtime systems.
Trying to install LIBR05 patch on those systems fails.
What is the supported workaround to install this patch on runtime only systems?


Thanks,


Haim G.

  Haim,
    You don't say what the error message is (or version, or architecture),
  and I haven't reproduced the problem or tried my proposed workaround. But,
  if it's just a "file not found" then the customer may be able to
  successfully install the patch after:

    $ LIBRARY/CREATE/OBJECT SYS$COMMON:[SYSLIB]STARLET.OLB

  Then delete the library it after the patch has been installed. Obviously
  if the customer doesn't have STARLET at the moment, they won't care what
  its contents are.
						John Gillings, Sydney CSC

    re .72,.73..74
    
    re .72
    
    Noone at Digital knows whether your customer needs the patch. Not that
    you get official answers from notes conferences but if we officially
    stated that your customer does not and it turned out that your customer
    does then we get in deep sh%t. Without a detailed knowledge of your
    customer's site, Digital is not going to take that risk (and without
    reward i.e. $$$ it makes no sense to take that risk anyway).
    
    Your customer perhaps needs to make a cost/benefit/risk analysis. They
    could wave the right number of dollars at Digital to create a patch for
    V5.3-1. (I am not aware of any technical reason why this cannot be
    done.) Those dollars might be wasted but it might save the cost of
    trying to find out whether they are wasted - depending on the number of
    applications and their complexity.
    
    Then there is the issue of applications that directly link with
    STARLET.OLB and contain the same coding error as DECthreads did, if any,
    that would not magically get fixed by applying the patch i.e. relink of
    application needed.
    
    And of course a really bizarre application might manage to contain
    errors in its own right - that could be hard to find and would have to
    be fixed by the owner of the application.
    
    Can I suggest that perhaps the customer should use their staging system
    to set the time forward and actually *test* all the applications that are
    mission critical. Even if a highly-qualified person gives an
    application the all-clear it does not seem sensible not to test.
    
    re .73
    
    There seem to be valuable lessons for Y2K here. A certain percentage of
    people are not going to read the cover letters or Q&A and even of those
    who read them, they are not going to understand them. We can improve the
    percentages by trying to increase relevance, by making the information
    available via different media (e.g. web + interactive).
    
    re .74
    
    I would suggest asking DCE Engineering. There seem to be some separate
    notes conferences for DCE which is where I would try.

:We have customers that do not have STARLET.OLB on their runtime systems.
:Trying to install LIBR05 patch on those systems fails.
:What is the supported workaround to install this patch on runtime only systems?

   That file is a standard part of OpenVMS.  If that file does not exist,
   then it was either erroneously deleted, or it was tailored off.  If
   it was tailored off, it will have to be tailored on, the patch applied,
   then tailored off (if appropriate).  And if that "tailor set" is ever
   added back on, they will have to reapply the patch.

              <<< NOTED::NOTES$7:[NOTES$LIBRARY]HACKERS.NOTE;1 >>>
                               -< ** Hackers ** >-
================================================================================
Note 464.6                    Image file comparator                       6 of 8
CUJO::SAMPSON                                        13 lines  23-MAR-1997 21:50
                     -< something else needed for Alpha? >-
--------------------------------------------------------------------------------
    How about OpenVMS Alpha image files?  Are the same methods
    (DIFFERENCES and CHECKSUM) supposed to work?  A customer
    says that he sees differences scattered throughout the
    Alpha images that are linked against two different GSMATCH
    versions of a shareable image.  I haven't been able to
    check this out on my own, though.  He wants to use this as
    his method of determining whether he needs to relink any
    application images after installing the ALPLIBR patch
    intended to fix the "10,000 days after 1970" (May 19, 1997)
    problem.
    
    Thanks for any advice,
    Bob Sampson
--
              <<< NOTED::NOTES$7:[NOTES$LIBRARY]HACKERS.NOTE;1 >>>
                               -< ** Hackers ** >-
================================================================================
Note 464.8                    Image file comparator                       8 of 8
XDELTA::HOFFMAN "Steve, OpenVMS Engineering"         29 lines  24-MAR-1997 21:26
                            -< See VMSNOTES 238.* >-
--------------------------------------------------------------------------------

   A 10Kday issue over here?  Ugh.  There's a large discussion going on
   over in VMSNOTES 238.*.  (I'd prefer to keep all the 10Kday issues
   together, as we're trying to address all these issues together.)

   There's an investigative procedure being developed here in OpenVMS,
   and it explicitly covers how to evaluate ones code and ones image(s)
   for the problem.  I'd expect to post it (or a pointer) over in 238.*.

   If the customer can see LIBRTL in the image(s) and does not have
   a "private" LIBRTL, then the customer will pick up the ECO fixes
   automatically.

   If the customer cannot see the LIBRTL in the image(s) and if the
   customer did not link the image(s) against STARLET.OLB, then
   there is likely no 10Kday problem.  (One has to go out of one's
   way with LINKER qualifiers to LINK against STARLET.OLB and not
   against the shareable images such as LIBRTL.)

   If the customer did link against STARLET.OLB, then the only way
   to tell if there is a problem is to look at the source code, or
   search through the image(s) looking for the footprint of the three
   object modules that could have been retrieved from STARLET.OLB.
   (Or to relink, which will pick up the fixed object modules.)

   Both you and the customer will want to read through the Q&A -- this
   will help the customer understand the problem -- and then start to
   look at local programming practices, and at the necessity of the ECO.

    I've been hearing first hand and from other DIGITAL people how
    customers are not exactly happy about having to patch their systems in
    such a short timescale.
    
    The more I hear, the more puzzled I get.
    
    A question, then.
    
    Why did we choose to 'enhance' the run-time library, rather than *fix*
    DECthreads?
    
    For all we know, DECthreads might be the only software on VMS to use
    this technique. The 10K day limit is a documented restriction full
    stop. If we had fixed DECthreads we would have been sqeaky clean *and*
    we could still have enhanced the rtl for customers to apply if they
    thought any of their own or third party code had used the broken
    technique.
    
    Graham

:    Why did we choose to 'enhance' the run-time library, rather than *fix*
:    DECthreads?

   Your question presumes it was only DECthreads that contains code that
   effectively violated a (documented) OpenVMS day-one restriction.  This
   may not be the case -- the underlying error may (does?) exist both in
   customer code, and in one or two other DIGITAL layered products.

   LIBRTL was updated because it was arguably the easiest and most contained
   and consistent thing we could fix, across a variety of OpenVMS releases. 

   In addition to the LIBRTL fix, we would have had to create and implement
   and test a fix for the DECthreads time calculation and for any other
   application(s) or products that contained this error, where now we are
   permitting an extra character into the existing time calculation.

re .81
    
    Can you elaborate on your question?
    
    How would fixing DECthreads rather than changing LIBRTL make any
    difference to the short timescale? I too find it somewhat concerning
    that the BLITZ was sent out only shortly before the deadline but it is
    not clear to me what determines that timing.
    
    How would fixing DECthreads rather than changing LIBRTL benefit our
    customers or make them happier?

    
.83>    I too find it somewhat concerning
.83>    that the BLITZ was sent out only shortly before the deadline but it is
.83>    not clear to me what determines that timing.
  
    I would imagine the biggest reason for that being no, patch being
    available earlier. That in turn would seem to be because noone 
    realized early enough the full consequences of the problem.
    
.83>  How would fixing DECthreads rather than changing LIBRTL make any
    
    The way I see it, the magnitude of the problem is due to DECthreads.
    
    The underlying problem IMHO is the deltatime semantics, enforced by
    LIBRTL. I'm happy this is finally being addressed. It was bothering
    me for some 4999 days now, and I'm pretty sure I expressed that back
    in 1983, but can not find that back anymore. 
    
    The first reference to this UNIX+DELTA problem ( = 'least common 
    denominator problem'!?) I found was Jan'96, topic 192 in VMSnotes V12. 
    The DECthreads problem was first mentioned publically mentioned just 
    over a year ago in topic 946 in the RTL conference. Unfortunatly, the 
    full ramification where not realized at that time. While that's unfor-
    tunate it does not bother me quite as much as the fact that apparently
    no one seriously tried to verify the year 2000 issues !?
    
    For some time now (more than a year is it not?), I've seen folks popping 
    the will VMS work in 2000 question and the answer I remember most is:
    "No problem for VMS, but we can to vouch for yor application, so why 
    don't you just set your clock forward some weekend and give it a spin"
    So did no-one ever bother to seriously try this? Please correct me if 
    I'm wrong, but surely this would have made the security server problem
    show up big time no? This makes me feel very uncomfortable for Y2K!
    All those commitees formed, words written, but no serious try huh?
    
    Now why is/was that 9999 day limit there in the first place?I have not
    seen too many serious explanations for that. Sure, there is the output
    formatting dillema as in 'what do you do if the ascii output field is
    not big enough to hold the result'. That one is readily solveable.
    My guess is that the limit was put in place in a noble attempt to
    sanity check both ascii and binary delta time inputs. A little like 
    the address-0 access violations it was meant to stop 'obviously' wrong
    values to be used in programs. Bzzzz. Wrong, Thanks for playing.
    
    I'll finish by including some old notes and replies (of mine) on the topic.
    (Notice Webb's rather appropriate (IMHO) personal name at that time :^)
    
    2�,
    	Hein.

            <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]RTL.NOTE;1 >>>
                        -< OpenVMS Run-Time Libraries >-
================================================================================
Note 946.0    LIB$CVT_TO_INTERNAL_TIME - 10,000 days is not enough!    3 replies
WTFN::SCALES "Despair is appropriate and inevitable" 27 lines  22-MAR-1996 18:12
--------------------------------------------------------------------------------
Hi,

Can someone here can explain why LIB$CVT_TO_INTERNAL_TIME's delta time argument
is restricted to 10,000 days?

We are trying to convert Unix times, which are expressed in seconds since
1-Jan-1970, into VMS quadword time values.  The problem is that next May (that
is, 19-May-1997), the Unix Epoch will be 10,000 days old.  So, any requests to
our functions for a timeout after that date result in an error.

Clearly, it's easy enough to work around this problem.  (We're gonna throw
LIB$CVT_TO_INTERNAL_TIME over in favor of a call to LIB$EMUL and a call to
LIB$ADDX.)  But, it's frustrating to have to do this when we see no obvious
reason for the 10,000 day limit.  I'm hoping that there is a good reason (other
than "the VMS delta time is defined to be 'dddd hh:mm:ss.cc'"), when it seems
like there is ample overhead in the binary formats (i.e., I think we can support
at least twice that).

I'm also concerned in that what we're doing probably isn't that unusual, and I'm
afraid that anyone else in the same position of converting Unix times to VMS
times is likely to hit the same unpleasant surprise.  So, if there's no good
reason against it, I'd like to see the 10,000 day limit raised.


			Thanks,

				Webb

================================================================================
Note 946.1    LIB$CVT_TO_INTERNAL_TIME - 10,000 days is not enough!       1 of 3
EPS::VANDENHEUVEL "Don't fix it,if it ain't baroque" 78 lines  23-MAR-1996 00:31
                        -< IMHO it doesn't make sense. >-
--------------------------------------------------------------------------------

>Can someone here can explain why LIB$CVT_TO_INTERNAL_TIME's delta time argument
>is restricted to 10,000 days?
    
    Simple really! VMS knows what is good for you! 
    Trust us, we are just helping you ignorant low lives out there.
    Bent over and take it li... 
    
    Ok, so that's a bit sarcastic. Let's rephrase that.
    
    IMHO this is one of the many well meant but in reality obnoxious
    and misplaced checks that vms offers to its users community.
    
We are trying to convert Unix times, which are expressed in seconds since
1-Jan-1970, into VMS quadword time values.  The problem is that next May (that
is, 19-May-1997), the Unix Epoch will be 10,000 days old.  So, any requests to
our functions for a timeout after that date result in an error.
    
    Just roll your own like the rest of us?!
    
Clearly, it's easy enough to work around this problem.  (We're gonna throw
LIB$CVT_TO_INTERNAL_TIME over in favor of a call to LIB$EMUL and a call to
LIB$ADDX.)
    
    Exactly!
    
>  But, it's frustrating to have to do this when we see no obvious
>reason for the 10,000 day limit.  I'm hoping that there is a good reason (other
>than "the VMS delta time is defined to be 'dddd hh:mm:ss.cc'"), 
                                 
    I'm sure that the reason you'll get for this not being changed
    in the foreseeable future ith that some application out there
    will be relying on this. :-(. Not true ofcourse, but that'll
    be the reason.
    
    Did I make enough enemies yet? No? then let let me predict the
    next reply: someone is going to point out the you should really 
    post this entry in VMSnotes because it is not the LIB$ folks 
    that made this choice but VMS proper. Over there in the VMS 
    conference the very same 12 active readers will then reread the
    topic and one will reply there that you really should submit a QAR.
    
    It _would_ seem trivial ofcourse to simply accept more than 4 chars 
    for days on input and output **** to undersized output conversions.
    
> when it seems
>like there is ample overhead in the binary formats (i.e., I think we can support
>at least twice that).                                          
    	
    Oh yeah, plenty of room. The absolute <-> delta distinction is simply
    the sign bit ie bit number 63 in the quadword. Just for grins here 
    are approximate ranges:
    
    	FFFF xxxx xxxx xxxx ->      1 year
    	FFFx xxxx xxxx xxxx ->   5000 days
    	FFE1 xxxx xxxx xxxx ->   9999 days 
    	FFxx xxxx xxxx xxxx ->  80000 days or well over 200 years.
    	2327 3D27 xxxx xxxx ->  31-DEC-9999
    So even if VMS is right in trying to help you detect 'clearly'
    bogus time values through immediate error handling versus just
    letting the application burp on strange subsequent outputs, they
    could still do it by insisting on the whole upper byte having
    all bits set for an acceptable delta time value and get the 200
    year range without seriously impacting the absolute date range.
    
>   <<< Note 946.0 by WTFN::SCALES "Despair is appropriate and inevitable." >>>

    Hey Webb, did you pick this personal name just for this topic?
    I'm afraid it will be soooo true.
    I'll be delighted to be proven wrong!
    Maybe I'll just go drink a beer now and relax some...
    Cheers,
    		Hein.
    
                                                                  
    	
    
    

            <<< VAXAXP::NOTES$:[NOTES$ARCHIVE]VMSNOTES_V12.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 192.0                Maximum value for delta time                 3 replies
CSC32::V_HAVER                                        5 lines  30-JAN-1996 15:23
--------------------------------------------------------------------------------
What is the reason behind the limit of 10000 days for delta time?  Was it
an arbitary choice, or because the delta time format is dddd hh:mm:ss.cc?
Should we ever expect this limit to be increased?

Thanks

            <<< VAXAXP::NOTES$:[NOTES$ARCHIVE]VMSNOTES_V12.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 192.1                Maximum value for delta time                    1 of 3
JEEM::KAUFFMAN                                       13 lines  31-JAN-1996 12:02
                           -< Restricted by $BINTIM >-
--------------------------------------------------------------------------------
    I couldn't find a fundamental technical reason why the hard limit was
    9999, other than the definition of the delta time format.  The services
    and routines that pick up the ASCII format use $BINTIM to parse the
    string.  That explicitly validates up to 9999, so it was intentional -
    whatever the original thinking was.  Theoretically, $BINTIM can hold up
    to a word's worth of binary value, so the size could get larger. 
    
    At this point, though, there are no plans to extend the delta string
    format.  For delta time patterns, 27+ years has always seemed
    sufficient; and there are enough compatability concerns to keep from
    doing it gratuitously.  
    
    Do you have a particular reason for upping the range?

            <<< VAXAXP::NOTES$:[NOTES$ARCHIVE]VMSNOTES_V12.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 192.2                Maximum value for delta time                    2 of 3
CSC32::V_HAVER                                       18 lines  31-JAN-1996 19:29
                       -< Customer's application issue >-
--------------------------------------------------------------------------------
Thanks for the reply.  A customer's application is using the
CVT_TO_INTERNAL_TIME to convert a field that is the time
since January 1970.  This routine is used in numerous areas of code. 
Since the maximum delta time is 9999 days, this funtion will no longer
work for them by approximately April/May 1997.  They wanted to know
if delta time could be modified to a larger number.

We gave them some suggestions to work around the limitation, and 
possible alternate coding possibilites.  However, they wanted to
know if the value would ever be changed before recoding.

Our concern about changing the value is compatibility, as well.  
There are most likely numerous customer applications out there
depending on the limit being less than 10000 days.

No need to pursue this as your reply should answer their question.

Vicky

            <<< VAXAXP::NOTES$:[NOTES$ARCHIVE]VMSNOTES_V12.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 192.3                Maximum value for delta time                    3 of 3
XDELTA::HOFFMAN "Steve; VMS Engineering"              9 lines   1-FEB-1996 11:38
                          -< UTC Or Absolute Time... >-
--------------------------------------------------------------------------------

    C programs are going to see the same problem around 2037 when the
    longword overflows, and I suspect this particular customer has a
    C/UNIX background -- that date is often used as the base date for
    C programs.  Move to the UTC format time: UTC is supported on most
    UNIX platforms, and under OpenVMS -- more work, more flexible, more
    portable.  Or move to the OpenVMS absolute time quadword -- less work,
    less portable.


            <<< VAXAXP::NOTES$:[NOTES$ARCHIVE]VMSNOTES_V6.NOTE;1 >>>
             -< VAX/VMS and more!  *** FOR INTERNAL USE ONLY ***. >-
================================================================================
Note 899.1                Any opinions on SYS$ASCTIM???                   1 of 4
CASEE::VANDENHEUVEL "Merci Beaucoup"                 35 lines  24-MAR-1989 05:58
              -< Invalid binary Time? Yes. Date? No-such-thing. >-
--------------------------------------------------------------------------------
    Opinion? Sure.
    The last word? No.
    
    There is no such thing as an invalid date. You know, it is just the
    number of clunks since the beginning of time and goes on 'forever'.
    Well, not quit forever, but above the year 9999. Such large years
    can not be formatted using 4 digits, so, like documented for $FAO,
    the year field is filled with asterisks "****" to indicate that the 
    input date can not be printed with the chosen format... but it is
    still considered a valid date.
    
    Also, all the service is supposed to do is "convert to an ASCII string"
    It did so succesfully, but not as you planned, and there is no way back.
    
    It would seem to be a reasonable suggestion to have ASCTIM return 
    failure when a (valid!) date with year > 9999. 
    Changing this now might break existing programs though, so a better 
    suggestion is to return an 'informational' status as result.
    
    Gentler, Kinder software could perhaps be expected to recognize
    the obvious ASCII garbage as input but not VMS because it would
    only solve part of the problem and would cost some futur date space.
    
    The problem of not being able to detect an 'obviously' invalid date.
    is there because there is only 1 bit of meta-data in the 64 bit time
    standard. When (If?) the new 128 bits date-time format comes along,
    more constraints on valid dates could be defined. In fact, I seem to
    recall that some code is supposed to tell a new date from an old date
    by looking for a non-zero upper byte in the binary date which would
    then limit currently valid binary dates to "20-MAR-2087". Consequently
    one might already want to put an informational status in place for
    any date beyond that !
    
    Regards,
    		Hein.

    
              <<< STAR::NOTESD$:[NOTES$LIBRARY]SYSNOTES.NOTE;7 >>>
             -< VMS Development Notes - DIGITAL INTERNAL USE ONLY >-
================================================================================
Note 1915.10             SIR # 3 Time Arithmetic for DCL                10 of 10
EPS::VANDENHEUVEL "Don't fix it,if it ain't baroque" 56 lines  26-MAR-1996 15:07
     -< Proposal for Unix style seconds since epoch (1-Jan-1970) to help >-
--------------------------------------------------------------------------------
    
    Well, It is a couple of years later and date/time arithmetic in DCL
    is still frequently requested judging by 
    	- entries in the comp.vms.os newsgroup
    	- entries in the command_procedures note file.
    	- probably a bunch of support calls to Colorado (not verified)
    
    I understand NT affinity stuff has everyone nicely tight up, but
    perhaps there is room for a real simple solution that will solve
    98% of the requests. Yeah, I know it is very un-VMS like to not
    solve 100% but allow me...
    
    Proposal is to add a new output_time_format for F$CVTIME to return 
    an (unsigned!) integer with the number of seconds since 1-Jan-1970.
    As simple as possible, but no simpler.
    
    Call it whatever you like: SECONDS_SINCE_EPOCH, TO_UNIX_SECONDS, 
    DELTA_SECONDS, HACK, TIME_T or my preference: just plain "SECONDS"
    
    Yes, it allows for the most requested function: Absolute date subtraction. 
    Yes, it will run out in 137 years (49711 days in 32 bits worth of seconds) 
    Yes, signed/unsigned goof ups may cause it to break as early as 20-JAN-2038
    Yes, it would be nice to have a way back to delta times too, but I'll take 
    _anything_ now instead of vms style, perfect, solution in several years.
    No I do not like 'seconds since 1-Jan-1970' myself but if it is good 
    enough  for a millions of unixs hackers out there, it must have some merit.
    No it won't do centi-seconds. 
    
    Gotcha... DCL must NOT use LIB$CVT_FOR_INTERNAL_TIME or SYS$BINTIM in
    this process but revert to LIB$SUBX and LIB$EDIV just like the PASCAL
    and C RTL already do. This is  because VMS style delta times are currently
    (artificially!?) limited to 9999 days which added to 1-Jan-1970 will 
    expire next year: 19-MAY-1997 (see CLT::RTL topic 946.0. Do not see 946.1)
    
    Ofcourse is would help if LIB$CVT_TO/FROM_INTERNAL_TIME would get 
    a SECOND_OF_EPOCH operation such that dcl could call that in turn. 
    If fact... It would be really simple/tempting to have DCL support 
    all FROM x_OF_y date_time operation that LIB$ offers as long as 
    that would hold up getting those absolute seconds out soonsest!
    
    Makes sense? Consider it done? Submit that qar?
    						   Hein
    
    Ps, Optionally, a return trip from seconds_since to date would be nice.
    Coding that currently in DCL would not be hard, but somewhat tedious:
    
    $ time    = (60*60*24*3)+8000  ! For example
    $
    $ days    =  time / (24*60*60)
    $ hours   = (time -   days*24*60*60) / (60*60)
    $ minutes = (time -  (days*24 + hours)*60*60) / 60
    $ seconds =  time - ((days*24 + hours)*60 + minutes)*60
    $ delta = f$fao("!UL- !2ZL:!2ZL:!2ZL.00", days, hours, minutes, seconds)
    DELTA = "3- 02:13:20.00"

    re .83
    
    I realise there is a bit of hindsight here, and I'm not particularly
    criticising DECthreads engineers.
    
    If DECthreads and any other DIGITAL product had been fixed, including
    patches for previous versions at the time the problem was discovered,
    and this was obviously over a year ago, we would not have induced the
    same panic and anger that we are now seeing - and I don't even work in
    a CSC!
    
    We would (as I mentioned in my earlier reply) have been able to present
    this problem in a better way - "DIGITAL has fixed it's code, but have
    also provided an enhancement to the RTL"
    
    Also, there might be only one person, ever, who used this technique.
    
    We are creating panic and anger, where it might not be necessary.
    
    
    A true story.
    
    Some years ago in the UK there was a rumour that there was going to be
    shortage of sugar.
    
    Sure enough, there was a shortage of sugar and supermarkets were rationing
    sugar to one bag per person.
    
    The reason for the shortage ? 
    
    People heard that there was going to be a shortage of sugar so went out
    and stocked up.
    
    
    Graham

.12 states that the customer letter is scheduled for 12-mar-1997, but I've
talked to two major customers in Norway today and they have NOT received any
customer letter on this issue from Digital. One of them have received letters
from Oracle and their application vendor.
I know Norway is far away, but 2 weeks for a letter......

Is this customer letter send directly to the customer or through the local
logistics?

\�ge

   re: 238.86

   The customer letter definitely shipped here in the US -- it went to
   all media distribution customers, and was shipped out of the US SSB.

   I do not know about the European mailing status.

    Has anyone successfully applied the VAXLIBR06 patch to a V5.5-2
    system? My customer prefers to not be the first.

re: .88

I've been running what should be the equivalent of VAXLIBR06 for a week 
now (VAXLIBR05 plus the new LIBRTL that's in VAXLIBR06).

My V5.5-2 cluster exhibited the DECps-DC crash under VAXLIBR05, but has
been working fine with the new LIBRTL. 

Ray

:    Has anyone successfully applied the VAXLIBR06 patch to a V5.5-2
:    system? My customer prefers to not be the first.

   Your customer is not the first.

  re: .88
    Yes, I installed it on my V5.5-2 system last Saturday. No problems found
  with the installation. Seems to be running OK (2 node cluster of 3100s).

  re: Customer letter

    Our logistics people tried in vein for 3 weeks to get *any* response
  from corporate on what they were supposed to do about the customer letter.
  They hadn't received any instructions or text, but they heard about the
  issue on the "grape vine".

    Eventually I had to take the text from the net, adjust it slightly for
  local conditions, format it nicely and present it to our cost centre
  manager for signing. It should be being mailed about now. 

    Perhaps it's the same in other geographies? Maybe it's up to CSC
  personnel to take the initiative?

  Digital really *must* get its act together over patches!

						John Gillings, Sydney CSC

re .91
    
>    Our logistics people tried in vein
    
    Resorting to drugs, huh? (-:

    Hi,
    
    Install VAXlibr06_070 on 5.5-1, but the files is not copy to the
    directory as expected. 5.5-2 OK. Any reason why ?
    
    The install procedure doesn't give any error.
    
    Thanks
    Parry

    Re: .79
    
    STARLET.OLB is part of the "PROG" subset of OpenVMS.  For systems that
    are run-only, it is not unreasonable that the PROG subset would be
    tailored off.
    
    				Steve

:  re: Customer letter
:
:    Our logistics people tried in vein for 3 weeks to get *any* response
:  from corporate on what they were supposed to do about the customer letter.
:  They hadn't received any instructions or text, but they heard about the
:  issue on the "grape vine".

    I'll forward this note through to the product manager.

:  Digital really *must* get its act together over patches!

   I've started taking some runs at this particular "windmill" from here
   at the engineering end of the process.  (And there are a number of
   "blades" -- issues -- on this windmill.)  We've gotten some tentative
   approval to make some basic changes to the current process, and have
   started a test run of a wholely new engineering patch process.

    I've read .13 (BLITZ), .59 (FAQ) and .75 (ECO) and I still can't find
    an exact definition of the delta-time related behaviour changes introduced 
    by this ECO (ignoring the fact that the ECO also introduces a fair number 
    of other changes not related to delta-times at all).
    
    Is it that all the listed routines will now both accept AND produce time
    values representing periods larger than 10K days? How does this apply,
    for example, to LIB$CONVERT_DATE_STRING, which seems to deal solely
    with absolute times (at least according to the V6.1 docs I referenced)?
    
    Also, given the list of affected components, can someone explain:
    
    "	If OpenVMS components hang with a message on the console (DEC-
    	netPlus Phase V, OSI, and DTSS are most likely to hang), you
    	must set the time ahead. To do so, enter the following commands:"
    
    Is DECNET/OSI affected or not? I mean come on, "If", "most likely" ?!?
    
    Another area: 
    
    Since this introduces an new LIBRTL, is it's GSMATCH value the same
    as what it replaces? ie Will this affect portability of images linked
    against an updated RTL across VMS versions (or to unpatched systems)?
    
    I've got other questions as well, but this will do as a start...
    
    Dave

:    I've read .13 (BLITZ), .59 (FAQ) and .75 (ECO) and I still can't find
:    an exact definition of the delta-time related behaviour changes introduced 
:    by this ECO 

   Old Delta Time Day Field d Format: NNNN
   New Delta Time Day Field Format:   NNNNN

:     (ignoring the fact that the ECO also introduces a fair number 
:    of other changes not related to delta-times at all).

   That issue is being discussed.

:    Is it that all the listed routines will now both accept AND produce time
:    values representing periods larger than 10K days? How does this apply,
:    for example, to LIB$CONVERT_DATE_STRING, which seems to deal solely
:    with absolute times (at least according to the V6.1 docs I referenced)?

   I don't have the specifics on the individual routines, but will get
   this information added to the Q&A.
    
:    Also, given the list of affected components, can someone explain:
:    
:    "	If OpenVMS components hang with a message on the console (DEC-
:    	netPlus Phase V, OSI, and DTSS are most likely to hang), you
:    	must set the time ahead. To do so, enter the following commands:"
:    
:    Is DECNET/OSI affected or not? I mean come on, "If", "most likely" ?!?

   This is a result of the phrasing of the time change.  Some components
   have been reported affected by large time changes on a running system.
   There was an old DECnet Phase IV problem -- long since fixed -- and
   there is/was a communications driver that is/was known to misbehave
   on large system time changes.

   I'd (personnally) avoid making large SET TIME time changes "live", in
   favor of a reboot with the timepromptwait SYSGEN parameter set to prompt
   during bootstrap.  (I've provided the folks working on the Q&A with a
   sequence that includes always prompting via timepromptwait, and not
   changing the time via SET TIME.)
    
:    Since this introduces an new LIBRTL, is it's GSMATCH value the same
:    as what it replaces? ie Will this affect portability of images linked
:    against an updated RTL across VMS versions (or to unpatched systems)?

   You could have answered this yourself by pulling apart a kit.
   (I don't know the answer, and would have to pull the kit apart
   to answer the question.)

Re: Customer letter

     A message has been sent to SSB to find out what happened in
    the AP and Europe geographies with the letter. The early word
    from Europe was that the letters ended up going out last week! 
    As we find out more details we'll post them here. 
     
RE:  Digital really *must* get its act together over patches!
    
    Yes, this is painfully clear and as Steve mentioned in an
    earlier note the process is under review.

RE: Testing and finding out the scope of 10k and Y2K

     The earlier noter who replied with the statement that "we did
    not understand the scope of the problem a year ago" is correct.
    Until the Jan/Feb timeframe this thought to be only a DECthreads 
    problem.  As you can see from all of the information in the FAQ's
    letters ect.this restriction impacts effects more than DECthreads. 
    DEcthreads is just the most obvious place where it causes a problem
    and if it happens here with a Digital product where else might
    it happened? That question can not be answered due to the large
    unknown in the application implication practices of digital and 
    the 3rd party providers, thus the RTL enhancement to remove the 
    restriction where it will resolve and issues for most applications.

     I'd like to point out that this was discovered as part of the Year 
    2000 testing. The failure of the security server is not obvious.
    When you boot a 7.0 Alpha machine without the patch applied the
    security server blasts two quick messages during startup. 
    So you've really got to watch it during boot up. The security 
    server does not "die" or halt until you issues a start or stop
    server command or start playing with proxies. So the problem  
    is something that generic IVP testing would normally cause to fail.
    The Year 2000 team is very involved in this 10k problem and they
    are making sure that all the lessons learned here will be taken
    into account when addressing Y2K issues. (If they are needed!)

                                          - Leo

    Thanks for the replies Steve...
    
>   Old Delta Time Day Field d Format: NNNN
>   New Delta Time Day Field Format:   NNNNN
    
    As far as I can tell, the only routine which *might* have a 'digit
    extension' is LIB$CONVERT_DATE_STRING; the other routines are all
    dealing with binary values of one form or another. (Or are you saying
    that the range tests are now checking for 100K days rather than 10K?)
    I'm not sure about LIB$CONVERT_DATE_STRING, as I can't find a specific
    definition as to what a "relative date string" is in the VMS docs; is
    this equivalent to a DCL "combination time string"?
    
>:    Is DECNET/OSI affected or not? I mean come on, "If", "most likely"?!?
>
>   This is a result of the phrasing of the time change.  Some components
>   have been reported affected by large time changes on a running system.
    
    The statement I quoted was from the BLITZ, as the first statement in
    section 7 "RESOLUTION" which then goes on to provide directions about
    setting date to the 20th, and then says to install the ECO and reboot.
    It isn't under "SYMPTOMS" or "DESCRIPTION" or "SOLUTION"; it isn't in
    the section about affected components, nor is it under a non-existant
    'try setting the system time ahead to see if you are affected, and here
    is how we recommend you do it' topic. It simply says what I quoted,
    ie 'you might experience hangs, and DECNET/OSI is "most likely"'...
    
>:    Since this introduces an new LIBRTL, is it's GSMATCH value the same
>:    as what it replaces? ie Will this affect portability of images linked
>:    against an updated RTL across VMS versions (or to unpatched systems)?
>
>   You could have answered this yourself by pulling apart a kit.
    
    Don't 'the powers that be' think this type of information is of importance 
    to the customer base/third parties/internal engineering so that they can 
    evaluate the impact of the ECO on applications/products/operations/etc?
    
    I'm not trying to flame you Steve, but I've been tasked with evaluating
    what this ECO means for the products I'm responsible for, and the lack
    of specific, detailed, information is not helping (and if I feel this
    way as a employee, what must customers be feeling?).
    
    Thanks,
    	Dave

>:    I've read .13 (BLITZ), .59 (FAQ) and .75 (ECO) and I still can't find
>:    an exact definition of the delta-time related behaviour changes introduced 
>:    by this ECO 
>
>   Old Delta Time Day Field d Format: NNNN
>   New Delta Time Day Field Format:   NNNNN
    
    Is that:
    	99999-::
    	32767-::
    	65535-::
    or something else?
    
    Assuming that it's 99999-::, then why such a tiny jump in capability?
    Given the effort that must have gone into coding and testing this,
    surely we could have allowed for a bigger delta time field? A seven
    digit delta time would have allowed for a time-span of 27000 years,
    which is somewhere near the maximum you can do with quadword delta
    times anyway (I think ... I ran out of envelope here :-).
    
    And while I'm designing away, what about SYS$ASCTIM_TNG and
    SYS$NUMTIM_TNG to allow five digit years and seven digit delta times?
    
    Antonio

:    Install VAXlibr06_070 on 5.5-1, but the files is not copy to the
:    directory as expected. 5.5-2 OK. Any reason why ?
:    The install procedure doesn't give any error.

   I'm checking on the points raised by MARVIN::CARLINI in 238.100.
   (I want to confirm the answers before posting -- and I need to get
   the answers added to the FAQ.

:    And while I'm designing away, what about SYS$ASCTIM_TNG and
:    SYS$NUMTIM_TNG to allow five digit years and seven digit delta times?

   Wanna help with the 10K patches and with the Y2K and 2038 work?

 
               HOLD YOUR HORSES!!

  Somebody is digging this hole deeper and deeper and
  we are sinking faster and faster.

  *****   THERE ARE NO (repeat NO) CHANGES TO THE   *****
  *****   ASCII REPRESENTATION OF DELTA-TIME        *****
          ~~~~~

       It is 4 digits.
       It always has been.
       It always will be!

  The delta-time changes to LIBRTL and $NUMTIM only affect
  the BINARY REPRESENTATION of delta time.
      ~~~~~~~~~~~~~~~~~~~~~

  This is a COMPLETE LIST of changed system services:

      $NUMTIM      converts from quadword-time to 7-word array
                   no longer returns SS$_IVTIME if input
                   delta time is > 10,000 days.

  This is a COMPLETE LIST of changed LIBRTL routines:

      LIB$ADD_TIMES                Do delta time arithmentic.
      LIB$SUB_TIMES                No longer return LIB$_IVTIME
      LIB$MULT_DELTA_TIME          for delta_times > 10,000 days.
      LIB$MULTF_DELTA_TIME

      LIB$CVT_TO_INTERNAL_TIME     Convert from one binary
      LIB$CVT_FROM_INTERNAL_TIME   representation of delta time
      LIB$CVTF_TO_INTERNAL_TIME    to another.  No longer return
      LIB$CVTF_FROM_INTERNAL_TIME  LIB$_IVTIME for delta_times > 10,000 
      LIB$CVT_VECTIM               days.

  In general there is now NO LIMIT to delta time, however some of the
  above binary representations have their own limits due to field
  sizes.

    You may have seen LIB$CONVERT_DATE_STRING included in the list,
    this was because it uses $NUMTIM.  This is in error.  It has not
    changed.  All restrictions still apply.

  Paul Hider
  OpenVMS LIBRTL/DEBUG

    Thanks for the clarification Paul, including the correction wrt
    LIB$CONVERT_DATE_STRING; I really couldn't figure out why it was
    in the list, since I was under the impression that the changes
    were solely to binary delta-time values, not the string forms.
    
    On the topic of binary values...
    
    Is it correct to assume that $NUMTIM will still return an error if the 
    delta-time input can't be represented in the unsigned 16 bit output 
    field? Similarly, what (if any) error is returned when the CVT_FROM_
    INTERNAL_TIME routine is requested to convert a large delta-time to a 
    type that won't fit in the unsigned 32 bit output field [hmmm: does
    seconds since 1970 'break' in 2038 or 2106?] And will the CVTF_FROM_
    INTERNAL_TIME routine return an error if the integer part of a time
    won't fit in the mantissa (24 bits?) of the floating point output?
    
    Oh, and can you comment on the GSMATCH question?
    
    Thanks,
    	Dave

    Whilst we wait for Paul/Steve to respond to .104, my next questions:
    
    From the FAQ:
    
              A: The 10,000 day issue only arises in cases where a
              UNIX time is converted to an OpenVMS time. The original
              implementation of the DECthreads interface did not involve
              any UNIX time specifications on OpenVMS. These were
              introduced with the implementation of the draft POSIX
              interface, which was layered on top of the original,
              proprietary (CMA) interface. Therefore, prior to Version
              7.0, only software that uses the draft POSIX interface (and
              which makes use of timed waits) is affected.
    
    My reading of the above is that code that uses ANY 'proprietary cma
    interface' routine (prior to OpenVMS V7.0) will NOT be affected by 
    the cma bug. Is this correct?
    
    Is there a list of routines (complete if possible) from the 'draft
    POSIX interface' which are affected by the 10k bug (prior to V7.0)?
    
              In OpenVMS Version 7.0 DECthreads provided an
              implementation of the newly accepted POSIX standard
              interface for threading services. The POSIX standard
              interface became the core interface and the other
              interfaces were reimplemented on top of it. Beginning in
              OpenVMS Version 7.0, all software that uses timed thread
              waits may encounter the 10,000 day time errors.
    
    My reading of the above is that on Open VMS V7.0, ONLY code that uses 
    'timed thread waits', regardless of the interface used (proprietary
    or POSIX) will be affected by the cma bug, Is this correct?
    
    Is there a list of routines (complete if possible) from the various
    CMA interfaces (proprietary, POSIX, etc) affected by the bug?
    
    Thanks,
    	Dave

>>    From the FAQ:
>>    
>>              A: The 10,000 day issue only arises in cases where a
>>              UNIX time is converted to an OpenVMS time. The original
>>              implementation of the DECthreads interface did not involve
>>              any UNIX time specifications on OpenVMS. These were
>>              introduced with the implementation of the draft POSIX
>>              interface, which was layered on top of the original,
>>              proprietary (CMA) interface. Therefore, prior to Version
>>              7.0, only software that uses the draft POSIX interface (and
>>              which makes use of timed waits) is affected.
>>    
>>    My reading of the above is that code that uses ANY 'proprietary cma
>>    interface' routine (prior to OpenVMS V7.0) will NOT be affected by 
>>    the cma bug. Is this correct?

	That is correct.  Prior to V7.0, use of the CMA interface with time
	values will NOT exhibit the problem.  Times are still maintained
	within threads as VMS time formats, not UNIX.


>>    Is there a list of routines (complete if possible) from the 'draft
>>    POSIX interface' which are affected by the 10k bug (prior to V7.0)?

	Any routine starting with "pthread" and uses time is potentially
	at risk.

>>              In OpenVMS Version 7.0 DECthreads provided an
>>              implementation of the newly accepted POSIX standard
>>              interface for threading services. The POSIX standard
>>              interface became the core interface and the other
>>              interfaces were reimplemented on top of it. Beginning in
>>              OpenVMS Version 7.0, all software that uses timed thread
>>              waits may encounter the 10,000 day time errors.
>>    
>>    My reading of the above is that on Open VMS V7.0, ONLY code that uses 
>>    'timed thread waits', regardless of the interface used (proprietary
>>    or POSIX) will be affected by the cma bug, Is this correct?

	Any routine, not matter what it is, if it uses time, is susceptible.
	The most common area is timed waits.  Again, only pertinent to V7.0+.

    
>>    Is there a list of routines (complete if possible) from the various
>>    CMA interfaces (proprietary, POSIX, etc) affected by the bug?

	As of V7.0, *every* routine that ustilizes time is susceptible.



Grahame

    Grahame,
    
    re: pre-V7, thanks for the info.
    
    re: V7, you seem to be saying that the bug has a much broader
    	scope/impact than what is stated in the FAQ. Please confirm?
    
    Thanks,
    	Dave

Dave,

I can see how you would think there is something broader, and perhaps there is. 
But I don't think of it that way.

In V7.0+, the "core" of threads is implemented using pthreads (posix) and thus
has the UNIX time at the core.  Older interfaces, still present for
compatibility, are just that, interfaces.  The code that implements the older
interfaces is NOT the same.  Now, CMA* calls pthread*.  So, even CMA calls are
susceptible.

So, it's broader with respect to consumers of threads.  How much?  I don't know
how to answer that question.  It ain't zero.

Grahame

    re: .108
    
    >$ LINK FOO,SYS$INPUT/OPTIONS
    >SYS$SHARE:LIBRTL.EXE/SHARE
    >
    >FOO will have an access violation.
    
    Why would this happen?

 
  In general the LIBRTL routines return LIB$_IVTIME when a delta time
  conversion cannot be completed correctly due to overflow conditions.

  One thing to note is that LIB$CVT_FROM_INTERNAL_TIME uses $NUMTIM
  internally which has a 65K day limit (LIB$_IVTIME is returned).
  Note also, that the output longword imposes its own limit if converting
  to seconds (24,855 days).

  LIB$CVTF_FROM_INTERNAL_TIME also has limits due to its internal workings
  and I will see what we can do to come up with a list of actual limits.

  To answer the GSMATCH question.  There is no change.  It only would need
  to change if there were a change in the interface that was not backwards
  compatible.  And we are very careful not to do that!

  To be honest, we were not expecting this level of interest in thes LIBRTL
  routines.  The original intention of making these changes was to help
  DECthreads out of their 19-May-1997 tight spot.  We will, most likely,
  take a closer look at these limits for the next release.

  Paul Hider
  LIBRTL/DEBUG

My blunder.  I hadn't established my test environment correctly.

Both ALPHA and VAX appear to be fine with respect to GSMATCH and linking
LIBRTL.EXE directly into the image.

Grahame

    re: .111 - Thanks for the answers Paul.
    
    re: .109 - OK Grahame, let me try again...
    
    I'd like to be in a position to issue some searches against source
    areas for "problem" routine names. For example, I've searched the
    source area for ONE product for "pthread" (none) and "cma_" (lots).
    
    The FAQ would seem to indicate that only a specific subset of the
    pthread routines ("timed thread waits") are problematic pre-V7, and
    on V7, "timed thread waits" are problematic regardless of interface.
    
    Your reply seems to indicate that prior to V7, a larger subset of 
    pthread calls are at risk (ie "Any routine starting with "pthread" 
    and uses time is potentially at risk.") and that on V7 this extends
    across all the cma/posix interfaces (ie "As of V7.0, *every* routine 
    that utilizes time is susceptible.").
    
    A cursory examination of my search results shows a few routines calls
    whose names seem to fall under the catagory "timed thread waits".
    ie  cma_cond_timed_wait (occurs once) cma_delay (occurs ~10 times)
    Conversly, additional calls have names that seem to fall into the
    broader catagory you define, for example cma_time_get_expiration
    
    It would be extremely helpful to know what routines are problematic
    (particularly given this wonderful little questionaire that was sent
    out to the layered products groups that requires a response by 3/31)
    in order to evaluate our products' vulnerability (if any).
    
    [I bet customers using any of these interfaces in their apps would too]
    
    Regards,
    	Dave

    re .101,
     Any outcome on why installed on 5.5-1 didn't copy files to the
    directory ?
    
    Regards
    Parry

    
    Just to speed up installing ALPLIBR050_070, I have a customer that has
    a network with more than 80 Alphas running OVMS 6.1, all of them with
    the same configuration. Is it possible to install the patch in just one
    of them and then copy the updated files?. In particular:
    
    STARTLET.OLB
    LIBRLT.EXE
    MESSAGE_ROUTINES.EXE
    
    It seems obvious but I would like to know in advance what I am doing.
    
    Thank you,
    
    Pedro, NSIS SPAIN
    

    

:     Any outcome on why installed on 5.5-1 didn't copy files to the
:    directory ?

    Bug.  Pull over a new kit.  The date on the saveset should
    indicate a more recent creation date than you have -- this
    fix is either out, or should be out very shortly.  No, there
    is no way to determine which V5.5-1 saveset you have without
    looking at the date.

  Pedro,

>  Is it possible to install the patch in just one
>    of them and then copy the updated files?   

    This is NOT advisable. It's probably quicker, and definitely safer to
  install the patch on each node. On a DEC 3000-500 running OpenVMS/Alpha V6.1
  it takes just over 40 seconds to install the patch from the kit. Newer,
  faster alphas will probably take less time. It may help to create a
  VMSINSTAL answer file, that way you can pretty much automate everything.
  Just create a file called ALPLIBR05_070.ANS in SYS$UPDATE:

$ CREATE SYS$COMMON:[SYSUPD]ALPLIBR05_070.ANS
* Will you allow a system shutdown after this product is installed? [YES]: \NO
^Z 

  Change the \NO to \YES if you want the systems to reboot at the end of
  the installation. Now invoke VMSINSTAL with the "I" (supress initial
  prompts) and "A" (use answer file) options:

$ @SYS$UPDATE:VMSINSTAL ALPLIBR05_070 DKA100:[PATCHES] OPTIONS I,A

  Remember that the source location can be a network address, so you should
  be able to cook up a simple command procedure which can be executed across
  the network. Indeed, assuming the patch kit is on node "SOURCE", something
  like the following should work:

INSTALL_ALPLIBR05_070.COM
$ CREATE SYS$COMMON:[SYSUPD]ALPLIBR05_070.ANS
* Will you allow a system shutdown after this product is installed? [YES]: \NO
$ @SYS$UPDATE:VMSINSTAL ALPLIBR05_070 SOURCE::DKA100:[PATCHES] OPTIONS I,A
$ EXIT

  Now, from any node in your network, you should be able to type:

$ @SOURCE::DKA100:[PATCHES]INSTALL_ALPLIBR05_070

  So, if you *really* want to do this fast, and you have common passwords
  on all your SYSTEM accounts, you could do all nodes in one hit by typing
  a nice long SET ENVIRONMENT/NODE command in SYSMAN and then DO the above
  command.
						John Gillings, Sydney CSC

re .96
    
>    "	If OpenVMS components hang with a message on the console (DEC-
>    	netPlus Phase V, OSI, and DTSS are most likely to hang), you
>    	must set the time ahead. To do so, enter the following commands:"
    
    Is anyone fixing this? (Steve?) i.e. if it has not been sent to all
    customers already or if it is available online.
    
    It is fairly confusing, coming right out of the blue as it does.
    
re .113
    
    Yes, it would seem to be slightly broader than as stated in the BLITZ.
    
    The bottom line is that since LIBRTL was changed rather than DECthreads
    fixed, it may be that noone knows the full set of DECthreads routines
    that rely on the change to LIBRTL, particularly as one pthread routine
    may call another. Even if someone gave you a definitive list of
    affected pthread routines (any version?) or affected pthread and cma
    routines (V7 and later?), you wouldn't bet your life on it, would you?
    
    If you use DECthreads at all, it would be prudent to install the
    enhanced LIBRTL.
    
re .115
    
    The words "do so at your own risk" come to mind.
    
    If you examine the kit and VMSINSTAL.COM, you should find anything
    extra that you might have to do. It should be possible to do what you
    propose but given that you have to reboot the system anyway, the time
    to do the install itself is probably not worth saving given the risks
    involved. I have seen so many crying users because a file was copied to
    SYS$SPECIFIC rather than SYS$COMMON, or with the wrong security
    attributes, or ...

    Lacking a list of vulnerable routines, and not having a V7 system handy
    to test it, can someone tell me if cma_delay is subject to the 10K issue?
    
    Thanks,
    	Dave

    
:>    "	If OpenVMS components hang with a message on the console (DEC-
:>    	netPlus Phase V, OSI, and DTSS are most likely to hang), you
:>    	must set the time ahead. To do so, enter the following commands:"
:    
:    Is anyone fixing this? (Steve?) i.e. if it has not been sent to all
:    customers already or if it is available online.

    There is another version of the FAQ in the works, and I've passed
    my comments on reworking this whole sequence and removing the
    warnings along as part of the review process.

:    The words "do so at your own risk" come to mind.
:    
:    If you examine the kit and VMSINSTAL.COM, you should find anything
:    extra that you might have to do. 

    I'd strongly advise against rolling one's own version of the patch
    kit -- if this patch is messed up, problems (for the customer, for
    the creator of the patch kit, and for DIGITAL) can ensue.

    If space or copy time is a constraint, one could conceivably copy
    just the .A and the .n savesets needed for the target OpenVMS
    version.   (No, I don't have the mapping of the savesets.)

re .116,
    This is the list of patch which didn't copy files  to directory only
    at 5.5-1, but OK for 5.5-2 . It this kit old ?
    
Directory ZPOVC::$1$DUA27:[FAL$SERVER]

VAXLIBR06_070.A;1       126/128     21-MAR-1997 09:36:18.00
VAXLIBR06_070.B;1       378/380     21-MAR-1997 09:36:18.00
VAXLIBR06_070.C;1       396/396     21-MAR-1997 09:36:19.00
VAXLIBR06_070.D;1       414/416     21-MAR-1997 09:36:19.00
VAXLIBR06_070.E;1      1134/1136    21-MAR-1997 09:36:20.00
VAXLIBR06_070.F;1      1152/1152    21-MAR-1997 09:36:21.00
VAXLIBR06_070.G;1      1170/1172    21-MAR-1997 09:36:21.00

Total of 7 files, 4770/4780 blocks.

:    This is the list of patch which didn't copy files  to directory only
:    at 5.5-1, but OK for 5.5-2 . It this kit old ?

    Unfortunately, empirical evidence indicates this kit is an old one.

    I'd recommend upgrading OpenVMS to something more current...

    Here's the OpenVMS VAX saveset mapping (one can locate this
    by looking inside KITINSTAL.COM in the first .A saveset)...

$       released_versions = "55 #551#552#60 #61 #62 #70 #"
$       file_version      = "55 #551#552#60 #61 #62 #70 #"
$       saveset_table    =  " B # B # C # D # E # F # G #"

    In this case, the dates indicate the fix went into the .A
    saveset, and the date associated with that saveset at the
    website is presently circa 27-MAR-1997 16:10:48.22.

Dave,

Sorry for the delay.

On VMS V7.0+, cma_delay is vulnerable.  This is because cma_delay is implemented
using the pthread interface (pthread_delay_np I believe).

Grahame

    OK, thanks... I was hoping that given the floating point seconds input
    to the routine, the lower layers wouldn't be concerned with computing
    any delta times against the Unix epoch in order to perform the wait.
    (ie that it wouldn't involve computing the time since 1-jan-1970 in
    order to perform a 'wait until x.y seconds from now'). [It appears as
    though this is the _only_ exposure in one particular product, sigh]
    
    Dave

    Hallo,
    
    We have here some companies which run frozen VMS 4.6 Systems
    which regulates the power distribution for the city of MUNICH.
    
    They don't can upgrade their systems easily, because of some security
    aspects, the same with some power plants!
    
    Any ideas, how earlier systems are affected?
    
    regards
    
    Volker

re .125
    
>    Any ideas, how earlier systems are affected?
    
    If the system is important enough to freeze then it should be important
    enough to do a *proper* investigation. Earlier notes talk about what to
    look for e.g. what erroneous calls to routines can exist.
    
    In the absence of any site specific information then I will say that it
    is probably not affected but don't blame when Munich is in darkness!

    
    The VAXLIBR06_070.A that I have copied to a customers system differs 
    from the kit now in our TIMA$TOOLS: directory with a new KITINSTAL.COM.
    I don't know VMSINSTAL but should the set ver (line 99) be there?
    
    $ diff kitinstal.com;2 kitinstal.com;1
    
    ************
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;2
       43   $       released_versions = "55 #551#552#60 #61 #62 #70 #"
       44   $       file_version      = "55 #551#552#60 #61 #62 #70 #"
       45   $       saveset_table    =  " B # B # C # D # E # F # G #"
       46   $!
    ******
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;1
       43   $       released_versions = "55 #552#60 #61 #62 #70 #"
       44   $       file_version      = "55 #552#60 #61 #62 #70 #"
       45   $       saveset_table    =  " B # C # D # E # F # G #"
       46   $!
    ************
    ************
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;2
       91   $!
       92   $  if  ((vms$major_id .eqs. "5") .and. (vms$minor_id .eqs. "5")
    -
    ******
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;1
       91   !
       92   $  if  ((vms$major_id .eqs. "5") .and. (vms$minor_id .eqs. "5")
    -
    ************
    ************
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;2
       99   $set verify
      100   $  else
    ******
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;1
       99   $  else
    ************
    ************
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;2
      164   $!      released_versions =  "55 #551#552#60 #61 #62 #70 #"
      165   $!       saveset_table     = " B # B # C # D # E # F # G #"
      166   $! tmp = f$extract(1,99,vms_version)
    ******
    File SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;1
      163   $!      released_versions =  "55 #552#60 #61 #62 #70 #"
      164   $!       saveset_table     = " B # C # D # E # F # G #"
      165   $! tmp = f$extract(1,99,vms_version)
    ************
    
    Number of difference sections found: 4
    Number of difference records found: 7
    
    DIFFERENCES /IGNORE=()/MERGED=1-
        SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;2-
        SYS$SYSDEVICE:[DECENG]KITINSTAL.COM;1
    
    
    Also is there a replacement ALPLIBR05_070.A to correct the
    LIBRTL$ECO_DROP.COM typo. I have opened the kit edited the file and
    backed it up again. But I am worried I may have done something wrong
    and do not have a system to test it on.
    
    I'm sorry if this sounds picky but I have made available these kits
    internally on a customer site for everyone to copy. Which includes
    probably around 700 VMS systems of various versions. Hence I would 
    like them to be right.
    
    Thanks,
    
    Dave Bono (On site software support) 

Hi,

I have a very carefull customer, the most important Technical University in
South America with a very large Alpha/VAX netwotk running applications that
uses most of the system services and RTL involved in this question.
Before to apply the delat-time patch, she is getting some informations about 
that, through Internet, with people who already applyed it. She received the 
two mails below and is very concern about that.

Do you have any information about both situations? Is that true?
What arguments I must to use with these type of customer?

A second question, that I wasn't able to respond: She has a system for
application development and plenty of systems where the applications run.
She wants to known if there is any risk in apply the patch in the
development system and run the applications created after the patch to
be executed in the production systems where the patch wasn't applyed?
    
Thanks, Mauro Aquino, MCS/CSC-Brazil.

First mail she received:
-----------------------

In article <[email protected]>, [email protected] 
(Michael W. Jenkins) wrote:
>At my clients' site, we have a 4-machine VAX cluster, and 2 standalone
>VAXserver 3100's.  The (2) 3100 's are at v6.2; the cluster
>(2-VAX4600's, 1 MicroVAX 3100, 1 VAX 4000 VLC) is at v6.2 with the
>exception of the MicorVAX 3100--it is at v5.5-2.
>
>On Saturday, March 22, 1997, we installed the ECO (VAXLIBR05_070).
>We did this under the System account on each machine.  All went OK.
>
>This particular installation does the accounting for the Sverdrup
>company in St. Louis.  The primary appllication that uses delta time
>is the BACKUP utility.  A STANDARD DEC product.  Works flawlessly, 
>at least until Tuesday when we found a problem.
>
>The staff does an incremental backup of the system disks daily.  The
>rest of the data is backed up in both incremental and full style,
>depending on the day and the owner of the data.  Payrolls and
>databases are full backups.
>
>The problem:  Incremental backups of the 4600's systems' disks should
>take no more than 90 minutes and use about half of a 4mm tape (no
>compression).  Since Monday, these backups have run 13 hours and used
>4 full tapes.  The "incremental" backups have been backing up the
>entire disk, as though it were a FULL backup.  EVERY night.  
>
>Unfortunately, there are only 12 hours to do backups.  Prior to this
>upgrade, the backups would be done at 0800 every day.  
>
>We haven't finished a backup, yet.
>
>The customer is REAL unhappy.  I'm unhappy.  This is making DEC look
>bad.  
>
>HELP.  What's going on?  This is the ONLY software that has been
>changed on all of the applicable systems.  The backup routine on the
>MicroVAX 3100 hasn't changed--it still works fine BUT then it NEVER
>had the ECO applied to it.  The VLC doesn't do backups.  No problem
>there.  The 4600's are the workhorses of the department--and they
>can't finish a simple incremental in the normal time.
>
>Mike Jenkins
>VAX System Manager
>Analytix of Greater St. Louis
>[email protected]
>
This is almost certainly due to the post-ECO cleanup command file that sets
the "NOMOVE" attribute on most of the system directory tree.  This causes the
revision dates of the directories to change and thus causes BACKUP to save
**EVERYTHING**.  What's worse, on a clustered system disk with multiple roots, 
BACKUP will save everything N+1 times (N+2 times if you have installed S/A 
BACKUP on the disk), if you don't use the BACKUP/NOALIAS qualifier.  This can 
really kill a backup!!

The cure is quite easy.  1) Do an image backup of the disk with /RECORD,
or 2) Backup all the directories  (Not the files, just the directories) with
/RECORD.  Method 2 is much faster,  (less than a minute in all the cases
I've done it), but has a slight chance that if you do certain strange patterns
of cross-directory renaming, your subsequent incremental backups
won't catch that those files have moved and if you later do a restore, might 
restore those files to the wrong directories.  It is very unlikely you are 
doing this kind of thing on a system disk.  To use method 2), give a backup 
command like:

$ BACKUP/RECORD DU0:[000000...]*.DIR;1 NLA0:DUMMY.BCK/SAVE/GROUP=0

(Check this to be sure it works; I'm typing from memory.)  Yup, to the null
device works just fine, the point is to update the backup dates on all the
directory files, not to actually save anything.  The [000000...] bit is to 
make sure the root directory, [0,0]000000.DIR;1, gets caught.

This situation has little directly to do with the LIBRTL patch.  In what is
probably an overly-defensive reaction to disk defraggers, DEC has
taken to setting the "NOMOVE" attribute on everything in sight in any
ECO that modifies anything that has the NOMOVE attribute.  This
includes all the files that **ALREADY** have NOMOVE set.  (I.e. it
doesn't check 1st and only set the bit when needed.)  This causes
the revision date to change on all the affected files, which triggers
incremental backup.  This effect combines with a relatively recent
change to backup (since VMS V6.2?), that causes BACKUP/SINCE=BACKUP
(i.e. the standard incremental backup), to include not only files
that have their own revision date more recent than their backup
date, but also files in any **DIRECTORY** (or sub-directory of a
directory) that has been modified since it was last backed up.

All this NOMOVE mucking occurs because the ECO kit installation
calls a DCL command file, SYS$SYSTEM:SETNOMOVE.COM,
which does all the dirty work;  you can edit this file with any text
editor to comment out the lines where it hits [VMS$COMMON...]*.DIR,
etc., which not only eliminates the problem, but also makes ECO
installations much faster.

I won't go into here the arguement over whether there is any
reason at all to set NOMOVE on any file other than SYS.EXE.

John Santos.


Second mail she received:
------------------------

John Santos wrote:

>This situation has little directly to do with the LIBRTL patch.  In what is
>probably an overly-defensive reaction to disk defraggers, DEC has
>taken to setting the "NOMOVE" attribute on everything in sight in any
>ECO that modifies anything that has the NOMOVE attribute.  This
>includes all the files that **ALREADY** have NOMOVE set.  (I.e. it
>doesn't check 1st and only set the bit when needed.)  This causes
>the revision date to change on all the affected files, which triggers
>incremental backup.  This effect combines with a relatively recent
>change to backup (since VMS V6.2?), that causes BACKUP/SINCE=BACKUP
>(i.e. the standard incremental backup), to include not only files
>that have their own revision date more recent than their backup
>date, but also files in any **DIRECTORY** (or sub-directory of a
>directory) that has been modified since it was last backed up.
>
>All this NOMOVE mucking occurs because the ECO kit installation
>calls a DCL command file, SYS$SYSTEM:SETNOMOVE.COM,
>which does all the dirty work;  you can edit this file with any text
>editor to comment out the lines where it hits [VMS$COMMON...]*.DIR,
>etc., which not only eliminates the problem, but also makes ECO
>installations much faster.
>
>I won't go into here the arguement over whether there is any
>reason at all to set NOMOVE on any file other than SYS.EXE.

AHA!  Now THAT'S interesting!  I installed the ECO on March 5, and it 
gave me a fatal bugcheck at the end, during the IVP.  The image which 
was running at the time of the crash was SETFILENOMOVE.EXE.  I called 
Digital about it, and they had "no idea" why SETFILENOMOVE should be 
running.  Maybe I'll call them back now.  (Incidentally, I'm running 
VMS V6.2.)  
  
      	   Hank Skelton - Meharry Medical College
  	     Nashville TN 37208   615/327-6231
 	               [email protected] 
 	   "That's my opinion - oughtta be yours"
  
    
                                                            

   There was a conscious decision made by the folks that create this
   kit not to create VAXLIBR07_070, and to replace the .A saveset of
   VAXLIBR06_070 with a new version -- this new version repairs a
   problem specific to V5.5-1 (only), and was discussed earluer in
   this string.

   The kit at the website has the latest .A saveset.

:    Also is there a replacement ALPLIBR05_070.A to correct the
:    LIBRTL$ECO_DROP.COM typo. I have opened the kit edited the file and
:    backed it up again. But I am worried I may have done something wrong
:    and do not have a system to test it on.

   I'd rather see that procedure pulled -- please don't use it.
   I haven't taken a look at the latest .A to see if the typo has
   been fixed.

   238.128:

   The first question is already answered in what you posted from comp.os.vms.
   The kit takes precautions to avoid having /NOMOVE files set /MOVE.

   If the customer wishes to shorten the BACKUP cycle, re-run a full /RECORD
   BACKUP, and also look at what /NOALIAS can do for the operation...

   The second, the bugcheck will need to be investigated through DIGITAL's
   support channels -- there is not enough information here to even begin to
   address this question....  (I'd suspect there is something site-specific at
   the college -- we have seen a few site-specific problems after installing the
   ECO... The most recent I've heard about was due to a horrendously-fragmented
   system disk -- in other words, not really related to the ECO kit at all...)

In the last Q&A draft I saw (3/28/97):

Q30: I ran across the following problem with the
     LIBRTL$ECO_DROP.COM contained in the ALPLIBR05_070 ECO.
     What is the problem and how can it be resolved?


$ !
$ LIBRARY/REPLACE/OBJECT SYS$COMMON:[SYSLIB]STARLET.OLB [SYSLIB]LIBRTL_OLD.OBJ
! Replace the objects (except message object)
%LIBRAR-W-OPENIN, error opening DSVE_PAA_ROOT:[SYSLIB]LIBRTL_OLD.OBJ; as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
$ !
$ !     Cleanup
$ !
$ DELETE TSYS$COMMON:[SYSLIB]LIBRTL_OLD.OBJ;0
%DELETE-W-SEARCHFAIL, error searching for TSYS$COMMON:[SYSLIB]LIBRTL_OLD.OBJ;0
-RMS-F-DEV, error in device name or inappropriate device type for operation

              A: Run the following command procedure to correct
              LIBRTL$ECO_DROP.COM in ALPLIBR05_070:

              $  File  :=  SYS$UPDATE:LIBRTL$ECO_DROP.COM
              $  Edit  :=  Edit
              $  Edit/Edt 'File'
              s/ [SYSLIB]/ SYS$COMMON:[SYSLIB]/ ALL ' [SYSLIB]'
              s/TSYS$COMMON/SYS$COMMON/ ALL 'TSYS$COMMON'
              Exit
              $  Exit

Dave,

I guess the issue becomes one of real vs. practical exposure.

For instance, if current time is 18-MAY-1997 23:59:58.00 and you specify
10 seconds as the wait time, the result is 19-MAY-1997 00:00:08.00.  In
this one instance your application is exposed.  It's minor, but there.

Grahame

PS  You still working on MAILBUS stuff?  If so, say hello to Riza for me.

    
    
    Can VAXLIBR06_070 be installed on OpenVMS VAX A5.5-2 (Old queue
    manager)?
    
    Thanks,
    
    Dave Bono.
    

re. .125

>    We have here some companies which run frozen VMS 4.6 Systems

The LIB routines did not exist before V5.0.
DECthreads did not exist before V5.5-2.

Your main concern, therefore, would be whether or not your applications
were misusing SYS$NUMTIM.

Mary

:    Can VAXLIBR06_070 be installed on OpenVMS VAX A5.5-2 (Old queue
:    manager)?

    Try it -- the only difference between A5.5-* and V5.5-* was in the
    queue manager, so there should be no image or object overlaps.  I
    don't believe there was any testing on A5.5-*, as it's too far back. 

    (I'd definitely look at moving forward to V5.5-2, and then toward a
    more current release, but that's another topic.)

    
    DCE seems to be affected b this problem already (due to Daylight Saving
    Time change). See note TUXEDO::DCE-PRODUCTS 2203
    
    Volker.

    The DCE fault has been confirmed, and is (another) manefestation of the
    10K delta-time fault -- see note 2203.13 in TUXEDO::DCE-PRODUCTS for the
    details.  Bottom line: apply the 10K patch.

           <<< TUXEDO::WORK$970:[NOTES$LIBRARY]DCE-PRODUCTS.NOTE;4 >>>
                          -< DCE Product Information >-
================================================================================
Note 2203.13        error at decw$dceresd:[dts.src]timers.c;1           13 of 13
WTFN::SCALES "Despair is appropriate and inevitable" 83 lines   4-APR-1997 12:20
         -< OK, now I'm satisfied that this IS a 10,000 day problem. >-
--------------------------------------------------------------------------------
.12> Looks like it simpy prints the line number and calls abort().

OK, there's the missing piece of data!  As I recall, the result of calling
abort() -is- the OPCCUS trap (which is REALLY gross, but there you are).

.10> For example, it will set a timer to adjust the time zone differential
.10> when daylight savings time expires.

Yes, this _would_ be subject to the 10,000 day problem, resulting in the call
to abort() above, and _would_ be fixed by applying the ECO.  So, I think we
are all squared away, now.


Nevertheless, I'd like to make clear my position on this situation.  I never
indicated that anyone should not apply the ECO now or in the future.  What I
said was (in the absence of knowing that DTSD was calling abort()) the
reported symptoms did not match the known symptoms of the problem which the
ECO addresses.  Thus, while applying the patch SEEMED to address the problem,
there was no sound basis for believing it fixed the problem.  Thus, it was
critical that we understood this and set our customer's expectations
accordingly:  that the patch would seem to provide a workaround for this
problem but that it was possible that other problems (data corruptions!)
might result.  If any such problems HAD cropped up after we claimed that the
ECO was a "fix" would have severly compromised Digital's credibility!!

Furthermore, without the patch, the problem seemed to be reasonably
reproducable.  That is, without the patch, it might have been possible for
Digital engineers to isolate the source of the apparent corruption.  Thus,
installing the ECO on -all- systems (internal as well as customers') would
have been a _disservice_ to our customers, because it might have made it
nearly impossible for Digital to locate and fix the real problem.

.10> I do not know of anyone with internals knowledge of DTS who could point to
.10> suspicious sections of code where your analysis may apply.  Why did the exact
.10> same DCE code not exhibit the problem last year.  I have heard this exact same
.10> analysis concerning other problems encountered with DCE's use of threads in the
.10> past. Excuse my skepticism, but this analysis has not rung true in many cases.  

*grin*  Just because the DCE code hasn't changed doesn't mean that nothing
else has changed.  Other shared images activated in the process might have
changed size.  This changes the virtual addresses at which allocations end
up, potentially changing the location and effects of a data corruption.  This
also changes code path lengths.  This could affect when certain events (such
as locking or unlocking a mutex) occur relative to events in other threads.
Changes in memory layout change the pagefault patterns (as do accesses to
sharable images from other processes on the system) which also affect timing. 
Finally, simple things like system and network load and I/O latencies alter
when a thread gets to run and when its timeslices occur.  Thus, if there are
*any* synchronization bugs ("race conditions") in your multithreaded code,
they could remain hidden throughout all of your testing and even long
stretches of deployment at multiple customer sites, but, when the right
factors line up, the race suddenly goes the other way and a data corruption
results (which can look like an ACCVIO, or an OPCDEC, or, yes, an OPCCUS,
depending on the exact nature of the corruption).

In multithreaded programming, you are subject to all of the same classes of
errors that you encounter in sequential programming and, in -addition- you're
subject to errors in synchronization in which timing is a factor.  In
sequential programming, it is possible to test all possible code paths;
however, in multithreaded programming (and other forms of asynchronous
programming) it is simply not possible to test the code completely, because
you cannot control the timing factor from outside the code.

Dave, I'm glad that you and no one that you know with internals knowledge of
DTS have experienced this class of problem.  That speaks highly of your code
(or your luck, but hopefully it's the former ;-).  Nevertheless, we on the
DECthreads team -do- encounter this sort of thing in our consumers' code from
time to time, and it's always a pain for us and for them.  For them because
it's very hard to find (it almost always has to be found via code-review),
and for us because they always say "well, the exact same code did not exhibit
the problem until we [changed something external to it]."


In closing, I'd like to apologise for having had to push back when this
problem did turn out to be a 10,000 day problem after all (everything would
have been clearer if abort() resulted in an SS$_ABORT instead of
SS$_OPCCUS!!).  Nevertheless, it would have been inappropriate for Digital to
claim that the ECO "fixed" the problem until we understood what the problem
actually was and how the ECO fixed it.  And, doing so would have been a
disservice to our customers and possibly damaging to Digital.


					Webb

   I have deleted my 238.137 and .138 notes, as these were indicating
   there was a pending investigation around the DCE bug mentioned in
   238.136 -- this bug has been confirmed as another symptom of the
   10K delta-time error.

Copyright (c) Digital Equipment Corporation 1997. All rights reserved.

PRODUCT:    Distributed Computing Environment (DCE) for OpenVMS versions  
	    V1.3A to V1.4

OP/SYS:     OpenVMS VAX versions  V5.5-2 to V7.0
	    OpenVMS Alpha version V6.1 to V7.0

COMPONENT:  N/A


SOURCE:     Digital Equipment Corporation


OVERVIEW:

OpenVMS Sustaining engineering strongly recommends the installation of
VAXLIBR06_070 and ALPLIBR05_070 patch kits prior to the daylight savings time
change on the weekend of April 5 and 6. 

After the daylight savings time change on the weekend of April 5 and 6, 
the DCE time service daemon, DCE$DTSD, may fail to start.  The following error
is written to the DCE$DTSD.OUT file: 

    "Fatal error at line 782 in file decw$dceresd:[dts.src]timers.c;1"


INFORMATION:

We believe this problem is caused by a pthread_cond_timedwait being set to
expire after 19-May-1997.  Refer to the "OpenVMS Delta-Time Restrictions and
19-May-1997" Blitz documentation for a description of the 19-May-1997 time
problem.  Additional information will be provided in future updates concerning
the OpenVMS Delta-Time Restrictions issue.


REFERENCE(S):

	Jan Rehbein - OpenVMS Sustaining Engineering
\
\
\ CONTRIBUTORS:
\
\      Technical:
\           Jim Morton (98192)
\	    David Sweeney - OpenVMS Sustaining Engineering
\      Editorial:
\           {edit_contributor_name} ({badge})

\ ---------------------------------------------------------------------------
\\ TYPE=TECH_TIPS TYPE=GENERAL_INFO

A customer in Malaysia had problems with INGRES V6.4 release 4 on VMS V5.5-2
after applying the VAXLIBR06_070 patch.  INGRES does not start successfully
and gives a SYSTEM-F-BADPARAMS VALUE message.

After rolling the patch out again INGRES starts successfully.

We are following this up with CA.

Has anyone else successfully run INGRES on a patched V5.5-2 system?  If so,
which INGRES version?

thanks & regards,
bill.

    Hi,
    
    What about AlphaVMS V1.5, is it affected ?
    
    I assume it is. Have there been any demand for such a build ?
    
    -Johan

    
    Hi,
    
        Hi,
    
        Alphaserver 2100 4/275   OpenVMS Alpha V6.1
        Watchdog Agent: SNSALPECO03022 (T2.2-09)
    
        Installing the SNSALPECO03022, then the IVP gives the error:
        ident mismatch with  shareable image
        CMA$RTL.EXE: CMA V2.11-441    (AXPCMAR01_061)
    
        SYSTEM-F-SHRIDMISMAT
    
    
    cross posted in NOTED::SNS 1023.0, but no answer there.
    
    Can you help?
    
    Regards
    Uli, MCS Germany
    

re: 238.144
    
:    What about AlphaVMS V1.5, is it affected ?

    Possibly yes.  Possibly no.

    Please read the Q&A for exactly what is involved here.  This
    is not a simple "yes or no", and the problem may or may not
    affect your particular installation or software configuration.
    And -- even with the patch -- the underlying bug can *still*
    lurk in specifically-linked application images.

    The customer will want to test their application, and will want
    to try the upgrade.

    The major component of OpenVMS that was affected by this is
    DECthreads -- the DECthreads RTL is usually found as component
    of an application or system-related image.

:    I assume it is. Have there been any demand for such a build ?

    Per the local product management staff, we (engineering) were
    informed that DIGITAL made a *concerted* effort to get customers
    off the versions of OpenVMS Alpha prior to V6.1.  In other words,
    I'd *strongly* recommend an upgrade to V6.1.

    I am aware of no other requests for OpenVMS Alpha V1.5 -- though
    there may certainly be some requests around I am unaware of.  If
    upgrading to a supported version of OpenVMS is out of the question,
    please contact me via e-mail with details, and I'll forward it
    through to the relevent OpenVMS product manager.

 re: Note 238.145 by TAGEIN::FRANKE

   SNS T2.2?  "T"?  Is that a "real" product release?  If so, you'll need
   to IPMT this with the folks responsible for the Watchdog agent.  If it
   is not a "real" release, you'll want to check this with a real release,
   and let us know if it fails.

   And in any case, we need to see exactly how the image was linked -- can
   you e-mail me a copy of the output from ANALYZE/IMAGE from the failing
   image(s)?

	I installed the new VAXLIBR06_070 on my VAX V6.1 machine
	and now it won't reboot !!!

	Here's what I get on rebooting the machine:


%SNAPSHOT-I-OPEN, opening the snapshot file
%SNAPSHOT-I VALIDATE, validating the snapshot file
%SNAPSHOT-W-BADIMAG,  file contains uncertified images - system may not reboot
%SNAPSHOT-I-READMAP, reading the snapshot file bitmaps
%SNAPSHOT-READ, reading the snapshot file
%SNAPSHOT-I-BUFFER, reading the I/O vector buffer
%SNAPSHOT-I-OVERWRITE, overwriting the boot structure
%SNAPSHOT-O-RESTART, restart to follow

The I get about three screens of %SNAPSHOT-I-HEXFID, & %SNAPSHOT-I-FILERR erros followed
by a memory dump along with system shutdown complete...


				Help !!!  I've applied the patch to other clusters
		but haven't done a reboot, maybe I'm hosing myself...


						Mike

Re .-1

Boot conversational, set BOOT_STYLE to 0, and Continue.
Then create a new snapshot file.

Jur.

Question concerning patches to address delta-time limit; VAXLIBR06_070 and
ALPLIBR05_070.  In the release notes it states in the installation instructions;

      The system MUST be rebooted after successful  installation  of  the
      kit.   If you have other nodes in your VMScluster, they should also
      be rebooted in order to make use of the new image(s).


Can one install the patch and schedule the reboot for 6 or more hours later
w/o any adverse affects or should you reboot immediately to prevent a system
hang/crash/etc.?
\
\thanks, David

You can do it later.

	Steve

    Re: 143
    
> Has anyone else successfully run INGRES on a patched V5.5-2 system?  If so,
> which INGRES version?
    
    Installed VAVLIBR06_070 31-Mar-1997 on a 5-node VMS V5.5-2 cluster with
    Ingres and all is working. An ANALYZE/IMAG of Ingres exe files reveals
    version "6.4/05/00" is being run.

re .144
    
>    What about AlphaVMS V1.5, is it affected ?
>    
>    I assume it is. Have there been any demand for such a build ?
    
    See also Topic 378 for a specific enquiry relating to this version.
    However please keep the discussion in this topic. We might get to 10000
    replies. (-:

    Hi,
    
    I have a system running 5.5-2 an I've already installed
    VAXLIBR05_070. I'd like to install VAXLIBR06_070. 
    My question is; can anyone tell me where I can pull the
    latest 06_070 save-sets from a VMS node?
    
    I read through this entire string but could'nt seem to
    find where to get the files.
    
    
    
    Thanks,
    Paul

Use a web browser (even a character-cell one like Lynx) and pull the patches
from the MCS web site.

				Steve

:    I read through this entire string but could'nt seem to
:    find where to get the files.

    The patch kits are not usually distributed via local directories,
    as they tend to change fairly regularly -- kits can be obtained
    via various means including the internet patch area, often via
    TIMA/COMET/STARS, and often via the CSC Patch area.

    The Q&A should have at least one pointer to the DIGITAL internet
    patch area -- the URL is http://www.service.digital.com.

    Get yourself a web browser -- there are several available for
    OpenVMS, including one (Mosaic) that ships with DECwindows, and
    (at least) one (Netscape Navigator) that ships with the OpenVMS
    distribution on the Internet Product Suite CD-ROM.  (Copies of
    the kit for Netscape Navigator for OpenVMS are also available
    at BULOVA::IPS$KITS:)

    CSC patch server:

	$ SET HOST CSCPT2
	Username: GETPATCH

    COMET support search engine:

	http://comet.alf.dec.com/

    See VAXAXP::VMSNOTES note 10.* for a *wealth* of available (and
    useful!) internal and external web sites...

   re: 378.3, availability of an ECO for the Alpha V1.5 release.
    
:    I just got a direct mail from a customer also concerned about 1.5

   I raised this issue at the onset of the delta-time work, and was
   informed (in no uncertain terms) that these pre-V6.1 Alpha releases
   were not to be touched nor considered, as we (OpenVMS) had "told"
   all sites running these releases to upgrade to at least V6.1.
   (Unlike the VAX sites where we have been "encouraging" upgrades.)

   This is outside the discussion of remedial contract support...

:    Perhaps OpenVMS Alpha 1.5 is sufficiently 'off' the beaten track
:    to warrant this specific topic 378. I think it does.

   Please keep the discussion to 238.*, as it makes it easier for
   the folks that are following this specific issue to keep track
   of this discussion.  (There are several folks involved with the
   OpenVMS 10K delta-time ECO that are explicitly following this
   238.* string *only*.)

:    Looking for a specific confirmation as 1.5 is not in the Q&A.

:	This should be added to the Q&A, as there

        A good suggestion.  I'll pass it along.

:    	-  There was no DECthreads on 1.5 and thus no thread?

	There are CMA libraries in the V1.5 results disk.

:    	-  No security server issue

	Correct.  That was due to Ada, which (on Alpha V7.0)
	was based on DECthreads, which contains the bug.

:    	-  No Time server issue

	Donno.

:    	-  Yes LIBRTL 9999 day artificial restrictions.

	Correct. The classic 10,0000 restriction applies.
   

From Note 378.3:
    
>    Anyway... Here is my concrete suggestion / question: what are the
>    chances to succesfully slap a fixed 6.1 RTL onto a 1.5 system.
>    Anyone have a system to try it on? Images linked against the RTL 
>    would supposedly keep on working (upward compatible). The RTL itself
>    may however refuse to install, being more recent than the rest, and
>    perhpas being linked against something (system?) creating a downward
>    compatibility conflict.

Well.. V6.1 had the LIBOTS major ident bump.  LIBRTL is one of the few
RTLs that doesn't link against the LIBOTS shareable, though.  But I'll
bet LIBRTL references some new system service.  Won't work..

-M

LIBRTL might work, but it has a dependency on the change to
SYS$NUMTIM in the execlet MESSAGE_ROUTINES.EXE.  This latter
image is V6.1+ specific and would not run on a V1.5 system.

However, from http://www.openvms.digital.com/openvms/delta_qa.html

Q6: Are these ECOs available for versions prior to OpenVMS VAX V5.5, or
         prior to OpenVMS Alpha V6.1? 

A: DIGITAL is presently working on backporting the present solution to
   earlier versions of OpenVMS (V5.0 thru V5.4). The VAXLIBR06_070 and
   ALPLIBR05_070 ECOs apply to OpenVMS VAX Versions 5.5 through 7.0,
   and to OpenVMS Alpha Versions 6.1 through 7.0, inclusive.
   (The ECO is not required for Version 7.1 and later.) Until the new ECO 
   is available, the solution for older releases is to upgrade
   to Version 5.5 and apply the ECO. 


So *someone* has commited to fixing this for prior releases.

This Q&A is a pretty nice piece of work! (even if it skips over
$NUMTIM's new restriction of 65535 days ;-)

re .159
    
>So *someone* has commited to fixing this for prior releases.
    
    I read the Q&A as saying that Digital is only working on the patch for 
    prior releases for *VAX*.

   re: Note 238.159

:So *someone* has commited to fixing this for prior releases.

   There was no V5.x series on OpenVMS Alpha -- the work
   mentioned in that question involves back-porting to the
   specified releases on OpenVMS VAX only.

   I am not aware of *any* plans to back-port to V1.0, V1.5,
   nor V1.5-1H1 of OpenVMS Alpha.  (As a way of explanation,
   we performed major work to the tools and to the OpenVMS
   build environment used for OpenVMS Alpha builds when we
   "went native".  While we can reverse this and back these
   changes out and start using the cross-tools, this is viewed
   as a large project, particularly for a set of releases we
   have been explicitly and actively discouraging the use of.)

:This Q&A is a pretty nice piece of work!

   Thanks -- there were a number of folks involved in the
   creation, and in the reviews and the updates...

: (even if it skips over $NUMTIM's new restriction of 65535 days ;-)

   I've asked that text with the explicit new limit be added
   to the Q&A.  (I do not happen to know if the limit is 64K,
   32K, or some other value.)

    re: VMSNOTES 452.0

:Just a quick one about the old Delta Time matter, see if anyone knows this,
:
:What's  the situation as regards VMS a 5.5-1, I've got someone who is trying
:to apply the eco (vaxlibr06_070) to this version, but all he's getting installed
:is the eco drop command procedure. He also tried the original vaxlibr05_070
:and this gave the same result.
:
:So...does the vax eco support a5.5-1? 

    Obviously not. 

    I'd upgrade the queue manager to the then-new queue manager,
    via the documented upgrade procedure.  (A5.5 contains the old
    queue manager, while the V5.5 and later releases use the current
    queue manager implementation.)

    If the customer insists on staying on A5.5-1 and the old queue
    manager -- the only reason I can see to do that is if I were
    running in a mixed-version VMScluster, with one or more systems
    running a pre-V5.5 version -- then log an IPMT.

    Given that there is likely no overlap of the files involved, 
    it might also be possible to relocate the files manually, and
    perform some basic testing.

RE: .161

   I am not aware of *any* plans to back-port to V1.0, V1.5,
   nor V1.5-1H1 of OpenVMS Alpha.  (As a way of explanation,


I suggest then that this be explicitly stated in the Q&A to
avoid questions on interpretation.

   And, for those that are interested in what can be involved
   in locating time-related problems, please see EVMS::Y2K, the
   OpenVMS Year-2000 conference.  10K is just the warm-up...

Customers have been calling support in large numbers to get details on what 
products require RELINKING or clarification on what circumstances will require 
relinking, if the delta time patch is installed.

Most of those customers can be pushed back on; and the recent release on the 
net of 
	Guide to the Open VMS Delta-Time Limit for System Managers and 
	    Application Providers

and the Q & A notes have been helpful.

This time a developer is looking for more detail and we the Support people on
the phones mostly can't begin to explain whehter 'their' application will need 
relinking or not.

Can someone in engineering look at this persons question and answer it or 
perhaps explain that what they are asking would require $200 an hour support 
from engineering?

Gary
===============================
From:   US3RMC::"[email protected]" "David E. Levenberg"
To:     OASS::MATTHEWS_G
CC:
Subj:   Delta-Time Limit

Gary Matthews
DEC Systems Support
[email protected]

Dear Gary:

Further to our conversation about the Delta-Time Limit, I have some
follow-up questions.

As a software developer I am trying to determine whether or not I need to
recompile & relink our software, and deliver this to our clients, or
whether the installation of the patch is sufficient.

I have read the $Guide to the Open VMS Delta-Time Limit for System Managers
and Application Providers,$ which I downloaded from DEC$s internet site,
and I need some clarification in a few areas.

1.  I have done an $ANALYZE/IMAGE$ on my .EXE file (I do not have suitable
.MAP files).  These .ANL files show $LIBRTL$ only in the sharable image
list.  Am I to understand that this means that the RTL functions are being
called at run-time, and therefore that I do not need to relink my software.

2.  I have searched my source code for the LIB$ routines that are listed in
section 6.1 of the $Guide to the Open VMS Delta-Time Limit for System
Managers and Application Providers.$  None of these are explicitly used in
my software (however, the function LIB$DATE_TIME is used).  Am I to
understand that this means that my software is in fact unaffected by the
Delta-Time Limit, and that I won$t need to relink and re-deliver my
software to my clients.

Thank you for your attention in this matter.
David Levenberg

David Levenberg, Product Manager
Midas-Kapiti International
45 Broadway NY, NY 10006
E-Mail : [email protected]

If an application is linked to the shareable image copy of LIBRTL, and was
not linked /NOSYSSHR, it does not need to be relinked.

				Steve

      Re: .155 and .156
    
     Steve and Steve, thanks for the pointers!
    
    
    
     Paul
    
    

re: 238.165

...
:As a software developer I am trying to determine whether or not I need to
:recompile & relink our software, and deliver this to our clients, or
:whether the installation of the patch is sufficient.

   If the software was not linked against STARLET.OLB -- it was not linked
   via the use of an explicit LINK/NOSYSLIB, or LINK/NOSYSEXE -- then the
   software should pick up the new shareable images automatically.

   Please use the documented testing procedures (and your application
   test suite) to ensure that your application(s) will not have any
   (catastrophic) problems at 19-May-1997.
   
:I have read the $Guide to the Open VMS Delta-Time Limit for System Managers
:and Application Providers,$ which I downloaded from DEC$s internet site,
:and I need some clarification in a few areas.

:1.  I have done an $ANALYZE/IMAGE$ on my .EXE file (I do not have suitable
:.MAP files).  These .ANL files show $LIBRTL$ only in the sharable image
:list.  Am I to understand that this means that the RTL functions are being
:called at run-time, and therefore that I do not need to relink my software.

   Without information from the LINK map on the executable image(s)
   and shareable image(s) involved or without examinination of the
   source code, it is difficult to determine if the application(s)
   will be affected by 19-May-1997, or not. 

   Use of the documented testing procedure is strongly recommended --
   both for 19-May-1997 testing, and for testing of the 31-Dec-1999
   through 1-Jan-2000 "millenium roll-over" dates.

   I (personally) expect that the vast majority of applications will
   not be affected by the delta-time limit, as most applications do
   not involve the UNIX delta-time base during any time conversion
   operations performed, and most do not involve delta-time conversions
   of over 9,999 days.

   Please use the documented testing procedures (and your application
   test suite) to ensure that your application(s) will not have any
   (catastrophic) problems at 19-May-1997.

:2.  I have searched my source code for the LIB$ routines that are listed in
:section 6.1 of the $Guide to the Open VMS Delta-Time Limit for System
:Managers and Application Providers.$  None of these are explicitly used in
:my software (however, the function LIB$DATE_TIME is used).  Am I to
:understand that this means that my software is in fact unaffected by the
:Delta-Time Limit, and that I won$t need to relink and re-deliver my
:software to my clients.

   Please use the documented testing procedures (and your application
   test suite) to ensure that your application(s) will not have any
   (catastrophic) problems at 19-May-1997.

   re: 465.0
    
:    we have a large international customer which supplies the
:    controlstations for power plants. These all have an operating system at
:    VMS4.6. Due to the Delta Time problem the customer is asking for a
:    possible solution. They are not able to upgrade the version since it is
:    frozen at that level. Therefore we can not suggest to upgrade to a
:    higher level as is recommended in the blitzes or customer information
:    letters. Can anyone help here?

    Please take a look at the Questions-and-Answers, and point the customer
    at the Q&A, and please ask the customer to follow the (documented) testing
    sequence, for both the rollover from 18-May-1997 to 19-May-1997, and from
    31-Dec-1999 to 1-Jan-2000.

    The Q&A covers this particular question -- we are not creating a fix for
    releases prior to V5.0.  (If the customer wants to pay for the fix, and
    we find that we are willing and able to rebuild V4.6 images -- that's over
    a decade back, after all...)

    If the customer is "frozen" at the V4.6 release, then they will have
    to localize the problem -- if it even exists at their site -- and
    work around it.  Or they will have to "unfreeze" and migrate forward.
    Or they will have to purchase the fix.  I'd recommend testing first,
    to determine if they *have* any problems with V4.6.

    Gosh, it makes you wonder how many service contracts could be sold to
    large international customers running V4.6?
    
    :-)
    
    Mark

All,

I have read through this topic and with what my customer, Digital's CSC and 
Orcale are saying, my customer wants to know what's required for Oracle 
applications?

My customer is happy with his knowledge of his own internally developed 
applications and knows what to do.

Oracle and Digital seem to be advising him to install the patch and 
then re-link all his Oracle based applications, is this the case?

The customer's application are 24 hour apps that are critical to the UK's 
electrcity supply. The customer doesn't think it will be possible to re-link, 
and test the all his applications before May 19th!

Any advise welcome.

Nigel

> The customer's application are 24 hour apps that are critical to the UK's 
> electrcity supply. The customer doesn't think it will be possible to re-link, 
> and test the all his applications before May 19th!

Maybe we can save ourselves all that pre-election hot-air since we now know that
whoever the new government is, they will have precisely eighteen days of power
... :-)

Antonio

Hi,

a big customer is striking us with a lot of information requests and 
I shoud like to verify what I'm going to tell them because they have
MANY critical production systems with different OpenVMS Vax and Alpha 
versions and a LOT of DEC and non-DEC products.
Furthermore, they are explicitly asking an official answer for ANY 
product they are running (Digital or not).

If I well understand all the 170 entries in this note, I suppose that
a general response like this could be correct (what I'm afraid is that
the following could be a too strong interpretation of the whole 
discussion; can someone give an explitic answer on this point?):

"Digital can ASSURE you that installing the patches for Alpha and VAX,
you will not see problems on ANY DEC layered product (they are very 
worried regarding for example Rdb, DTR, ...) because:
a) before VAX VMS 5.5 DEC layered products are not impacted by the 
   problem (DecThreads was introduced in 5.5). In any case, for your
   or 3-party applications you MUST ask to the developers AND, if you 
   want to be sure, follow the testing procedure for Y2000; 
b) moreover, the engineering is working on a patch for versions 5.0-5.5
   (I guess, to minimize the impact on customers applications that could 
   have not been coded with the 10000 days restriction, since I assume
   as TRUE that the problem doesn't affect VMS <5.5 and its LAYERED);
b) for OpenVMS VAX versions >5.5 and Alpha >6.0 the available patches 
   SOLVE the problem for ANY Digital product (because ALL of them use 
   the RTL libraries).
   Again, for applications you MUST ask to the developers AND, if you 
   want, follow the Y2000 testing procedure."

In any case, I wish to post here ASAP the products/VMS-versions mapping 
the customer will send to me, to ask if someone see any exception to 
the above statements for this customer configuration (if someone will
tell me that they are not true in ALL situations).

Thanks for your support and excuse me if I made redundant questions!
You can imagine who much stressing this situation is for this customer
(and hence for us...).

paolo
    

:I have read through this topic and with what my customer, Digital's CSC and 
:Orcale are saying, my customer wants to know what's required for Oracle 
:applications?

    You will need to direct your customer to Oracle with any Oracle-related
    applications, not DIGITAL.

:The customer's application are 24 hour apps that are critical to the UK's 
:electrcity supply. The customer doesn't think it will be possible to re-link, 
:and test the all his applications before May 19th!

    Use the documented testing procedures on a testing system, and find out
    if any of the code is even affected by the problem -- this is certainly
    the fastest way to determine if there is or is not a catastrophic problem.

    Ask the customer to follow the documented testing
    procedures, and see if there *are* any catastrophic
    problems.  (The customer may or may not see any local
    or vendor-specific problems -- this problem is not
    necessary going to cause a failure -- and testing is
    strongly encouraged.  See the existing documentation
    at the www.openvms.digital.com web site for information
    on products that are known to have problems, and for
    information on testing...)

:Furthermore, they are explicitly asking an official answer for ANY 
:product they are running (Digital or not).

    Official answers come from Product Managers. 

    *Not* from notes conferences.

:If I well understand all the 170 entries in this note, I suppose that
:a general response like this could be correct (what I'm afraid is that
:the following could be a too strong interpretation of the whole 
:discussion; can someone give an explitic answer on this point?):

    See the web site for the formal statements.  If you
    need more, you need to contact a product manager.
    (I will forward your note through to the product
    manager dealing with this issue.)

:Digital can ASSURE you that installing the patches for Alpha and VAX,
:you will not see problems on ANY DEC layered product (they are very 
:worried regarding for example Rdb, DTR, ...) because:

    See the list of products that are known to have problems.

    DIGITAL products that do not happen to use the LIBRTLs -- like
    any other application that uses STARLET.OLB directly -- will
    require a relink.
    
:a) before VAX VMS 5.5 DEC layered products are not impacted by the 
:   problem (DecThreads was introduced in 5.5). In any case, for your
:   or 3-party applications you MUST ask to the developers AND, if you 
:   want to be sure, follow the testing procedure for Y2000; 
:b) moreover, the engineering is working on a patch for versions 5.0-5.5
:   (I guess, to minimize the impact on customers applications that could 
:   have not been coded with the 10000 days restriction, since I assume
:   as TRUE that the problem doesn't affect VMS <5.5 and its LAYERED);

   Correct.

:b) for OpenVMS VAX versions >5.5 and Alpha >6.0 the available patches 
:   SOLVE the problem for ANY Digital product (because ALL of them use 
:   the RTL libraries).
:   Again, for applications you MUST ask to the developers AND, if you 
:   want, follow the Y2000 testing procedure."

    Correct, save for any DIGITAL products that do not use the RTLs.

:In any case, I wish to post here ASAP the products/VMS-versions mapping 
:the customer will send to me, to ask if someone see any exception to 
:the above statements for this customer configuration (if someone will
:tell me that they are not true in ALL situations).

    See the listing of the products that are known to have problems,
    and known to not have problems.  A more complete list is
    under development.

    Names removed to protect from frequent phone calls.  We have enough
    already.  No need to start a geometric progression.
    
    Grahame
    
From:	US2RMC::"D****@us.oracle.com" "Dan*** **** **." 15-APR-1997 22:01:47.46
To:	spseg::plaisted
CC:	
Subj:	Re: Your folks point to http://www.openvms.digital.com/ ?


--=_ORCL_27474736_0_11919704151942110
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"

	Our recommendation is to apply the patch and re-link, there are some 
easier routes for O7.1 and greater customers, but we choose the conservative 
path. I personally reviewed our support bulletin, and approved it. 
 
Since we use the RTL .OLB files when linking our Kernel - I see no other way 
to ensure we don't have any issues than to re-link. 
 
We realize the inconvience of this - believe me!! I'm in Melborne today (AUS) 
and won't be checking mail again till the 3rd of May. Further questions can be 
sent to: 
    		<names removed so that they're not inundated with calls>
 
Cheers, 
dan  

re .173
    
>"Digital can ASSURE you that installing the patches for Alpha and VAX,
>you will not see problems on ANY DEC layered product
    
    This is way too strong. Please do not expose Digital to this kind of
    risk. What reward is the customer offerring that could justify this risk?
    What risk assessment is Digital doing on this statement?
    
    Note also that this is the VMS conference. Each individual Digital
    layered product would have to speak for itself and officially that is
    through its product manager not through a notes conference. You need to
    get the list of all Digital supported products that the customer has,
    identify the product manager for the product and get an official
    statement.                              
    
>    (they are very worried regarding for example Rdb
    
    RDB is an Oracle product.
    
>b) for OpenVMS VAX versions >5.5 and Alpha >6.0 the available patches 
>   SOLVE the problem for ANY Digital product (because ALL of them use 
>   the RTL libraries).
    
    Since Digital has hundreds of layered products I would be skeptical
    that anyone could make the assertion that they all use the RTL. Also,
    what about all the dead or sold products? In any case the "because"
    part is not strictly correct. A layered product could in principle
    still have a 19-MAY bug due to its internal code even if it linked
    against the shareable RTL rather than the OLB.

> a) before VAX VMS 5.5 DEC layered products are not impacted by the 
>    problem (DecThreads was introduced in 5.5). In any case, for your
>    or 3-party applications you MUST ask to the developers AND, if you 
>    want to be sure, follow the testing procedure for Y2000; 

It is possible for layered products to be calling the impacted LIBRTL
routines directly with values greater than 9999 and prior to V5.5.  The
DECthreads problem does not exist prior to V5.5 therefore any layered
product that has the problem because of DECthreads will not have a problem
prior to V5.5.

> c) for OpenVMS VAX versions >5.5 and Alpha >6.0 the available patches 
>    SOLVE the problem for ANY Digital product (because ALL of them use 
>    the RTL libraries).
>    Again, for applications you MUST ask to the developers AND, if you 
>    want, follow the Y2000 testing procedure."

The patch solves the 10k problem for any digital product that uses
DECthreads or the impacted LIBRTL routines.  There is one exception to
this:  if the layered product uses the impacted LIBRTL routines with values
greater than 9999 and they have linked in LIBRTL through STARLET.OLB
(/nosysshr) then they will need to relink.
    
    note: Not all Digital products use the RTL libraries

    Today I asked 3 customers, whether they know about 10K-Day problem.
    Nobody knows. It looks like that the customer letter, that appears
    in this thread was not sent to customers, at least not here in 
    Germany. Is it 'expected behaviour' ? Should I inform customers that
    I meet, that there is a potencial problem here ? Or I should be
    silent and do not distribute internal iformation (until somewhere
    something will breaks) ?
    
    =Seva

I have seen .177, which refers to Oracle's recommendation to relink Oracle
Oracle applications. I also have seen the memo in which they recommended this.

I have some customers who would like to know if Oracle has a similar 
recommendation for Rdb. (They have asked the local Oracle rep, and so have I.
No answer so far.) Perhaps someone has the answer, and can post it here.

The same customer has applications that use Adabas. Another customer has
applications that use Ingres. 

I have referred the customers to the local representatives in each case, but 
technical support for these products is not great here. The customers asked 
me to try to get the information through our channels. They hope we have more 
clout with the software manufacturers than they do.

Has anyone heard anything about Rdb, Adabas or Ingres requiring a 
reinstallation, relink etc. ?

Thanks for any help.
Arthur

    There should be no reason to have to relink Oracle Rdb applications for
    the 10k date issue.
    
    Oracle does not believe that there will be any problems within Rdb in
    regards to Y2K or the 10K date problem.  Of course, applications and
    databases that use Rdb might have coded 2 digit years and things like
    that, and we do have several papers that deal with correcting these
    sorts of problems with minimal impacts.
    
    If you want an 'official' response to a question, please contact Oracle
    Rdb product management.
    
    	norm lastovica / oracle rdb engineering / colorado springs

   re: 238.180 by COL01::VSEMUSCHIN

   There is absolutely no problem with talking with customers about
   this problem.   (I'm not a PM, but this is being openly discussed
   externally.)  You will want to get copies of the customer letter
   and the 10K Q&A handy for your own edification, and to pass out
   to customers -- for copies, see http://www.openvms.digital.com.

:    Today I asked 3 customers, whether they know about 10K-Day problem.
:    Nobody knows. It looks like that the customer letter, that appears
:    in this thread was not sent to customers, at least not here in 
:    Germany. Is it 'expected behaviour' ? Should I inform customers that
:    I meet, that there is a potencial problem here ? Or I should be
:    silent and do not distribute internal iformation (until somewhere
:    something will breaks) ?

   Information has been widely available on the Internet and at
   DIGITAL's website, and has been sent via SSB to all customers.

   We had a previous report of a breakdown in the ESSB mailing,
   and that problem was being tracked down.  (SSB was requested to
   ship to all customers of record, worldwide.)  I'll forward this
   in again, as it appears [E]SSB still hasn't done the mailing.

  <<< Note 238.182 by ORAREP::LASTOVICA "Comparisons are as bad as cliches" >>>
                  -< Rdb should require no additional steps >-

>    There should be no reason to have to relink Oracle Rdb applications for
>    the 10k date issue.

    
 >   Oracle does not believe that there will be any problems within Rdb in
 >   regards to Y2K or the 10K date problem.  Of course, applications and
 >   databases that use Rdb might have coded 2 digit years and things like
 >   that, and we do have several papers that deal with correcting these
 >   sorts of problems with minimal impacts.
    
Can I clarify the position regarding oracle+rdb. I assume they are two seperate
products still.. (else this makes no sense).

There are 4 questions really, spell them out for clarity.

1. Is there a delta time problem in the oracle database product itself - ie
will all oracle customer have to install the patch even if in their code
there it no delta time problem/pthreads usage.
2. Is there a delta time problem in the rdb database product (from the above I 
think the answer is no)

3. Is oracle linked against the object library, ie customers who identify
a delta time problem in there code will need to relink because of the way 
that oracle is linked (think this is yes from an earlier note).
4. Same as 3 only for rdb.

Thanks dg.

> Can I clarify the position regarding oracle+rdb. I assume they are two
> seperate products still.. (else this makes no sense).

The confusion comes from the fact that Oracle Corporation sells two different
database systems: Oracle7 (soon to be Oracle8), and Oracle Rdb (which they
bought from DEC).  Norm's comments relate to Oracle Rdb only.

    RE: .-1, .-2
    
    Correct.  The 'traditional' Oracle RDMS is currently called Oracle7 and
    Oracle8 (released on NT I think).  Oracle Rdb (aka VAX Rdb, aka DEC
    Rdb, Aka Oracle Rdb7) is the code stream purchased from Digital.
    
    Personally, I can not speak for Oracle RDMS at all (don't know a whole
    lot about it; I work on Rdb); you should contact Oracle support
    directly for any questions of that nature.  In terms of Oracle Rdb, we
    know of no "delta time problem"s; no 10K day issues and no Y2K issues
    in the product itself (my comments about an application or database
    that are built on Oracle Rdb still stand).
    
    Rdb is, for the most part, linked with the VMS RTL sharable images. 
    There may be some small parts that we link in from .OLBs, but nothing
    of any substance.  We are not aware of any situations (assuming that
    you're running anything even close to a current release; there were
    some older versions that might require a relink after an Rdb upgrade,
    but these were spelled out in the release notes long ago) that would
    make an application have to relink after installing any VMS upgrade,
    VMS patch or Oracle Rdb upgrade (ie, you can build your application on
    Rdb V4.2 and then upgrade Rdb to V6.1, convert the database and restart
    the application; upgrade VMS a couple times and still the application
    requires no recompiles, relinks or anything).

My rememberance of Oracle Rdb (formerly DEC Rdb) is that re-link of applications
and/or the product itself is not generally necessary.  Note the word
"generally".  Rdb itself utilizes shareable images, not object libraries. 
However, as in the generic VMS case, ultimately if the customer linked the
end-user application using an object library MIGHT require re-linking.

OK, now live analysis...

Rdb (up through V6.0 at least) shipped an object library.  See logical
RDBVMS$LIB.  There is only ONE object module in this library and it relates
to conversions.  Unless you are coding directly to the COSI API, I wouldn't
worry about it.  A quick analysis of the object reveals that NO LIB$ date
routines are utilized, nor CMA for that matter.  It looks like this object is
only used for converting different floating point and decimal formats.

Rdb couteously supplied a link options file (see logical RDBVMS$OPTION). 
Nothing strange there.

I have also looked at ALL the Rdb images that I could find on VAX from V4.1
through V6.0.  The ONLY thing I can see is that LIBRTL shareable image is used
in all instances.  I can NOT tell if Rdb is using date routines.


BUT... since DATE is a valid datatype in Rdb (and CDD), then it's more than
probable that customer applications that use a date datatype are impacted and
ONLY need to install the ECO, NO RELINK.

Lastly, I have sent mail to the Oracle Rdb sustaining engineering manager. 
Waiting for response.

Grahame

    re: 488.0

:    According to the article entitled:
:    "[OpenVMS] Delta-Time Limits With Arguments Exceeding 9999 Days"
:    in the hidden text there is an unofficial patch for V5.4-3. My
:    customer is running 5.4. The kitinstal appears to be looking for
:    5.4-3 specifically. Are there any plans to create a kit for 5.4 or
:    will this patch work for 5.4 with a modification to kitinstal? Further
:    can this unofficial patch be sent to customers?
:
:    \ CSC NOTE - 08-APR-1997:
:    \
:
:    \ A new image for V5.4-3 from Engineering can be found in the directory
:    \ below:                                                                   
:    \                                                                          
:    \      CSC32::DOCROOT:[COMMON.INTDRV.ENG_IMAGES.HPAQA23C1]                 
:    \                                                                          
:    \ Directory DOCROOT:[COMMON.INTDRV.ENG_IMAGES.HPAQA23C1]                   
:    \                                                                          
:    \ VAXLIBRS1_U3_054.A;1  414  (RWED,RWED,RWE,RE)                            
:    \                                                                          
:    \ An official ECO for V5.4-3 is not yet available in TIMA.


   I would not send the patch to the customer prior to its full testing
   and formal release, unless there is some overriding requirement here.
   (We have had some problems with earlier versions of these ECO kits,
   and I'd prefer not to see us have any more unnecessary problems.)

   I would send a copy of the 10K Q&A -- the customer *probably* does not
   need the patch.  To determine if there are any catastrophic application
   failures due to the delta-time limit, have the customer perform the
   specified testing.  And when the ECO kit is ready, send it.

   Also see notes 238.*: .157, .159, .169, etc.

   I would stronly encourage an upgrade to a supported version, or to
   the current V7.1 version -- the 10K patch will be followed by an
   OpenVMS release and zero or more ECO kits for prior OpenVMS releases
   for any necessary Year-2000 changes.

> BUT... since DATE is a valid datatype in Rdb (and CDD), then it's more than
> probable that customer applications that use a date datatype are impacted and
> ONLY need to install the ECO, NO RELINK.

I doubt if Rdb (on VMS) ever converts dates into the form "days since
1-Jan-1970", so I doubt if it suffers from a 19-May-1997 problem.  And I would
expect customer applications to do this only if they're UNIX-centric in some
way.  On the other hand, if Rdb uses threads nowadays, it could well be
susceptible, since it certainly has timers within it.

re .189
    
>On the other hand, if Rdb uses threads nowadays, it could well be susceptible,
>since it certainly has timers within it.
    
    I would imagine that RDB, running in EXEC mode, would be obliged to
    implement its own multi-threading. That is, I doubt that DECthreads,
    CMA, pthreads or any other thread package would be supported at EXEC
    mode and probably wouldn't work anyway. The result is that probably RDB
    just uses ASTs for all its multi-threading. Even with thread support
    within VMS (aka kernel threads) I doubt that RDB could use DECthreads
    etc. for its multi-threading but stand to be enlightened.

    Rdb's threading has been around since long before DECthreads was a
    glimmer in someone's eye.  As far as we can tell, we won't be impacted
    by the 10k problem (any more than, say, the PASCAL compiler would be).

	Hi,

I read the different articles speaking about the delta time limit, and also this
notesfile.

A lot of our customers are asking us a status about various Digital products :
(will they have to reinstal, to relink, or to wait for a new kit etc ...).

I know that the official answer should be asked to product manager.

But can we imagine that each different CSC from each country asks individually for
each customer to each product manager a status for each DIGITAL product ?


It will be simplier and more efficient to have a more detailed list that the one
given till now.

.175

>    See the listing of the products that are known to have problems,
>    and known to not have problems.  A more complete list is
>    under development.

May we know when it will be available ?


Regards,

:A lot of our customers are asking us a status about various Digital products :
:(will they have to reinstal, to relink, or to wait for a new kit etc ...).
:I know that the official answer should be asked to product manager.

    Correct; ask the product manager for the specific product.

:>    See the listing of the products that are known to have problems,
:>    and known to not have problems.  A more complete list is
:>    under development.
:
:May we know when it will be available ?

    As soon as OpenVMS can collect this information.  I will ask that
    the folks collecting this information "publish" the current list
    here and via the Q&A, if it extends what is already in the Q&A.

   I am aware of no problems caused by the installation of the
   current ECO kits themselves, though there have been reports
   of system disks that have been too fragmented and have been
   rendered unbootable, and reports of other problems attributed
   to the patch -- such as this one -- that are actually a result
   of other problems.


re: Note 492.0 ALPLIBR05_070 > unbootable Alpha by UTRTSC::RVISSER

:           Possible boot problem after installing ALPLIBR05_070
:
:Customer installed ALPLIBR05_070 on an Alpha 2000 with OpenVMS V6.2.
:
:After succesfull installation of the patch the system was unbootable:
:
:%EXECinit-E-LoadERR,error loading MESSAGES_ROUTINES.EXE status=00000044
:
:(Status 00000044 >>> %SYSTEM-F-BADIMGHDR, bad image header)
:
:After booting the 6.2 OpenVMS CD we found that this file had the correct 
:checksum (CHECKSUM/IMAGE), it was NOT corrupt. 
:
:It appeared that both files installed with ALPLIBR05_070 
:(SYS$LOADABLE_IMAGES:MESSAGES_ROUTINES.EXE and SYS$SHARE:LIBRTL.EXE) 
:had a file-id greater than 65536 (third part of FID non-zero) and 
:this was the real problem:
:
:There is a know problem with the primitive file system used during 
:boot of OpenVMS Alpha where the primitive file system cannot  locate  
:files  whose file number is greater than 65536. This problem is solved 
:in several ALPAPB and ALPBOOT patches.
:
:The customer did not had this fix installed.
:
:We fixed the problem by copying MESSAGE_ROUTINES.EXE to a higher 
:version number. The new file had a file number < 65536. (after 
:the installation a purge was done). We tried a reboot but now the
:system crashed with a bugcheck PROCGONE. After copying LIBRTL.EXE
:to a higher version number the FID was < 65536. After this we
:could reboot without any problems !!!
:
:Summary:
:
:-1- Any patch that installs a new loadable image may result in an
:    unbootable system. This will happen if the new loadable image 
:    has a file number greater than 65536 and the "primitive file system" 
:    patch (e.g. ALPBOOT06_062) is not installled.
:
:-2- If the FID of MESSAGE_ROUTINES.EXE is greater than 65536 
:    the bootstrap will fail with:
:
:    %EXECinit-E-LoadERR,error loading MESSAGES_ROUTINES.EXE status=00000044
:
:-3- If the FID of LIBRTL.EXE is greater than 65536 the bootstrap will 
:    fail with:
:
:    PROCGONE bugcheck
:
:
:
:Regards,
:
:Rob Visser

    
    Another Question?
    
    Does the VAXLIBR06_070 kit apply to V5.5-2HW?
    The kitinstal procedure only checks for H4 and HF.
    
    Does the customer need to upgrade or hack the KITINSTAL procedure to
    get it to work?
    
    Thanks,
    Niguel Brooks
    CSC Sydney

    
    Excuse me,
    
    I'm looking for the patch kit for Openvms VAX V5.0-5.5, but I still can't
    find any pointer.
    
    Has it been released? (and, if not, when it will be? many customers are
    waiting for it...)
    
    Thanks,
    paolo
    

    
:    Does the VAXLIBR06_070 kit apply to V5.5-2HW?
:    The kitinstal procedure only checks for H4 and HF.

   V5.5-2HW was an early pre-release of V5.5-2.  Upgrade to V5.5-2.

:    I'm looking for the patch kit for Openvms VAX V5.0-5.5, but I still can't
:    find any pointer.

    The patch has not been released for these OpenVMS VAX versions
    prior to V5.5.

    I *strongly* suggest local testing, *before* assuming the patch
    is required.  (Particularly on pre-V5.5 releases.)  This testing
    will tend to identify any site-specific catastrophic failures.

    Be aware that the "blind" application of the patch will *NOT*
    *GUARANTEE* that all applications will operate as expected on or
    around the 19-Mar-1997 date -- see the Questions and Answers for
    details.  It is distinctly possible

    I *suspect* there will be relatively few problems found, and that
    there will be no need for the patch on versions prior to V5.5 at
    most sites -- what few problems that will surface during the
    testing are likely in applications ported (incorrectly) from
    UNIX systems.  And these may or may not be resolved by the
    application of the patch.

    Also see the Questions and Answers for the specific products and
    the specific OpenVMS releases that are known to have 10K delta-time
    releated problems.

    (This is a Y2K-class problem; DIGITAL cannot make blanket statements
    that all customer sites will, or will not, be affected by this class
    of problem -- the Y2K verification effort is a large one, and only
    covers specific DIGITAL products and specific versions.  You *will*
    want to strongly encourage your customer to start looking at any
    site-specific Y2K issues, and to start Y2K testing...)

    A customer has by accident applied the VAXLIBR05 kit to their
    VMS V5.5-2 cluster and experienced a couple of crashes. Can
    they invoke the procedure to remove the patch and defer the
    reboot to a later time? Or must they reboot immediately?

:    A customer has by accident applied the VAXLIBR05 kit to their
:    VMS V5.5-2 cluster and experienced a couple of crashes. Can
:    they invoke the procedure to remove the patch and defer the
:    reboot to a later time? Or must they reboot immediately?

    Install the VAXLIBR06_070 kit.

    The back-out procedure is broken, and requires a couple of
    manual steps to get it to work again.  And that procedure
    was not -- rather obviously -- heavily tested on that ECO
    release kit.

Steve,

we have some big technical OEM that develop industry applications 
that are sold in many foreign countries (not only in Europe, but 
also in oversea countries, like Arabia, Malaysia, ...).

Some of these customers do (did) an heavy use of the affected
LIB$CVT routines.

: I *strongly* suggest local testing, *before* assuming the patch
: is required

: Be aware that the "blind" application of the patch will *NOT*
: *GUARANTEE* that all applications will operate as expected on or
: around the 19-MAY-1997 date

Yes, I understand this; of course, if the customer application
was linked with .OLB in a "static" way, they will have to
relink it. The problem is that now they cannot be shure of what
they did in the past.
As you can imagine, it is not so easy to test all the applications they 
developed in so many years, running on many different versions on VMS 
and OpenVMS VAX and Alpha; in any case a migration to V7.1 (VAX or Alpha) 
is -obsviously- not possible at all.

This is why I'm trying to get the patches for V5.0-V5.5, even if we
are not shure if the customer systems will or will not be affected by 
the problem. Please consider that in case of problems, it is 
*possible* that we will have some production systems in the world that 
will not work correctly.

May be we could not avoid to *all* these customers to have *any* 
problems, but I think that it is important to do all we can to minimize 
the possibility of catastrophic situations.

Thanks a lot for you cooperation,
sincerely,
paolo 
    

Just using the LIB$ routines doesn't mean there's a problem - the May 17
issue arises only if the application uses these routines to compute delta
times with the UNIX 1970 "epoch" date as its base.

				Steve

    They do (did).
    
    paolo

re: 238.201.

    Let's try a different explanation of the 10K delta-time problem.

    Here's the short description: DECthreads will exceed a day-one
    documented limit in an OpenVMS delta-time routine on 19-May-1997.

    It was deemed simplest and easiest to raise the traditional OpenVMS
    limit than to update (fix) DECthreads.  In other words, there is no
    bug in OpenVMS, the bug is in DECthreads and any other application
    that might exceed the day-one OpenVMS limit, and implicitly, in
    applications dependent on other (broken) applications.

    If your application does not use DECthreads and does not exceed
    the day-one documented limit (in sys$numtim) and does not use some
    other component that needs the patch -- then there is no need for
    the patch.  (I'd still recommend installing the patch.)  The only
    OpenVMS version that gets into some trouble is OpenVMS Alpha V7.0,
    and the problem there is fairly subtle -- the SECURITY_SERVER gets
    into trouble, but only if it is stopped and then restarted.  And
    I'd expect few sites would be doing this with the SECURITY_SERVER.

    The limit is encountered 10,000 days after the delta-time conversion
    "base time".  When the UNIX base time is used, then 10,000 days is
    19-May-1997.  If the base time 1-Jan-1980 is used, the limit will
    be encountered circa May 2007.  If the base time is 1-Jan-1960, well,
    the limit has already passed, and you never even noticed.

:As you can imagine, it is not so easy to test all the applications they 
:developed in so many years, running on many different versions on VMS 
:and OpenVMS VAX and Alpha; in any case a migration to V7.1 (VAX or Alpha) 
:is -obsviously- not possible at all.

    You are primarily interested in catastrophic failures, and in
    a quite code review.

This is why I'm trying to get the patches for V5.0-V5.5, even if we
are not shure if the customer systems will or will not be affected by 
the problem. Please consider that in case of problems, it is 
*possible* that we will have some production systems in the world that 
will not work correctly.


:Some of these customers do (did) an heavy use of the affected
:LIB$CVT routines.

    The routines are not so much "affected" as "limited".  In other
    words, the routines do not break -- take a look at the code, and
    find out if it exceeds the limit.  Most software -- other than some
    code in DECthreads and the code based on DECthreads -- will not
    even notice the 19-May-1997 date.
    

:: I *strongly* suggest local testing, *before* assuming the patch
:: is required
:
:: Be aware that the "blind" application of the patch will *NOT*
:: *GUARANTEE* that all applications will operate as expected on or
:: around the 19-MAY-1997 date
:
:Yes, I understand this; of course, if the customer application
:was linked with .OLB in a "static" way, they will have to
:relink it. The problem is that now they cannot be shure of what
:they did in the past.

    There is more than just code linked against STARLET.OLB.
    There are other routines that are not being increased, and
    if the code exceeds those, it will (still) break,

:May be we could not avoid to *all* these customers to have *any* 
:problems, but I think that it is important to do all we can to minimize 
:the possibility of catastrophic situations.

    Testing, testing, testing, and testing.  Did I mention testing?

    Someone in our office has spoken with a software partner that received
    a call from a consultant selling Delta time services to customers.
    
    Mark Schafer
    SPE MRO
    297-3524

    re: 527.0 by ATZIS1::KARTNER_M.

    Please determine which VAXLIBR patch was installed, and please
    log an IPMT *now*.  (Suspected problems with this ECO _need_ to
    be reported immediately.)

    After the installation of the VAXLIBR patch, the node must be
    rebooted.  If you are trying to continue operations without a
    reboot, I'd expect a reasonable chance of some weird behaviour,
    given the modules being replaced.
    
:    I'got several customers reporting qmanager problems after/during
:    the installation of the VAXLIBR patch (at VAXVMS V6.1,..).
:    
:    Both customers had dual boot node environments that can both
:    run the queumanager. During rebooting one of the nodes
:    the queuemanager died,couldn't failover,...
:    
:    After a cluster reboot everything seems to be OK again
:    
:    Is this a known BUG, behaviour ?
:    Should someone stop the queuemanager before rebooting the
:    nodes one by one ?
:    We can't tell all customers to shutdown their whole cluster
:    at once
    

    I have some government agencies running V5.3 to V5.4 VMS. They also
    have Oracle (verion not known) running. The local Oracle office said
    that they MUST apply the delta-time patch. I would like to ask if this
    is really necessary and if so when will the patch for V5.0 - V5.5 be
    available?
    
    Regards,
    Mickwid.

    re .207
    
    How would Digital know whether Oracle software requires the patch? (Did
    you mean Oracle RDB or Oracle 7, for want of better names?) If Oracle
    says the patch is needed, it is not for us to say otherwise even if we
    suspect it.

:    I have some government agencies running V5.3 to V5.4 VMS. They also
:    have Oracle (verion not known) running. The local Oracle office said
:    that they MUST apply the delta-time patch. I would like to ask if this
:    is really necessary and if so when will the patch for V5.0 - V5.5 be
:    available?

   Follow the testing procedures -- see the previous discussions of
   the V5.0 through V5.4-* ECO.

   Please see previous discussions of Oracle products in this note.

   The V5.0 through V5.4-* ECO kit will be available when it has been
   fully tested and packaged.

   I *strongly* recommend these folks upgrade -- please point these
   folks forward at the Year-2000, and ask them how they expect to deal
   with this, if OpenVMS requires ECOs for it.  (Please see EVMS::Y2K
   notes 23.* and 67.*, among others -- we have no current plans to
   retrofit any Year-2000 changes as far back as pre-V6 releases.)

              <<< VAXAXP::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 527.2       VAXLIBR couses qmanager problems when rebooting          2 of 2
ATZIS1::KARTNER_M "HOUSTON, we have a problem"       15 lines  28-APR-1997 03:47
                      -< Seems to be a failover problem >-
--------------------------------------------------------------------------------
    Hi!
    
    	During the reboot of the cluster, no further problems appeared!
    	The installed Patch was the VAXLIB06_070.
    
    	I think the only way to run into this problem is rebooting
    	single nodes. If you reboot the node running the queuemanager
    	a queuemanager failover is initated which seems to fail if the
    	target node hasn't been rebooted before. But I've got this
    	information from my second customer only and afterwards no
    	further problems rose up at this site. I don't think this is
    	enough info for opening an IPMT
    
    								thanks
    								Michael
r

    re .209
    
    >   The V5.0 through V5.4-* ECO kit will be available when it has been
    >   fully tested and packaged.
    Will there be a rough time for the ECO so that we can answer the
    customer?
    
    >   I *strongly* recommend these folks upgrade -- please point these
    >   folks forward at the Year-2000, and ask them how they expect to deal
    >   with this, if OpenVMS requires ECOs for it.  (Please see EVMS::Y2K
    I wish I could force them. If so, they would have done it years ago.
    The Y2k still have some years and they have some years to go for it.
    But the 10K day is just some weeks ahead.
    
    re .208
    The local Oracle staff said that the delta time patch is required on
    the customer's system. I would just like to ask if someone out there
    has any experience on handling Oracle V7 (not Rdb) over VMS V5.3/V5.4.
    
    Regards,
    Mickwid.

:    >   The V5.0 through V5.4-* ECO kit will be available when it has been
:    >   fully tested and packaged.
:    Will there be a rough time for the ECO so that we can answer the
:    customer?

   Per information from the product manager, we expect the pre-V5.5 ECOs
   will become available within the next two weeks, starting with the more
   recent of the OpenVMS versions and working backward.   I would recommend
   an upgrade to V5.5-2, or to V6.2, or to V7.1.

   As mentioned elsewhere, I would assume -- unless proven otherwise
   through site-specific testing -- that the pre-V5.5 customers do *not*
   require the ECO kit.

:    >   I *strongly* recommend these folks upgrade -- please point these
:    >   folks forward at the Year-2000, and ask them how they expect to deal
:    >   with this, if OpenVMS requires ECOs for it.  (Please see EVMS::Y2K
:    I wish I could force them. If so, they would have done it years ago.
:    The Y2k still have some years and they have some years to go for it.
:    But the 10K day is just some weeks ahead.

   Unfortunately, Y2K is a far larger application problem -- all of
   the site's applications, and OpenVMS, will need to be checked, and
   any problems found resolved and upgrades performed, in less than
   three years.

   I STRONGLY RECOMMEND THESE FOLKS UPGRADE -- OPENVMS HAS NO CURRENT
   PLANS TO Y2K-ECO THE V5.3 and V5.4 RELEASES.

:    re .208
:    The local Oracle staff said that the delta time patch is required on
:    the customer's system. I would just like to ask if someone out there
:    has any experience on handling Oracle V7 (not Rdb) over VMS V5.3/V5.4.

   Contact Oracle directly, and ask them for technical details. 
   (There have been several discussions of why Oracle indicated the
   patch was required here.)

    Hi,
    
    Can I trust that if the LIB$CVT_TO_INTERNAL_TIME is listed as
    referenced by LIBRTL in the Symbol Cross Reference section then 
    this application does not require a relink ?
    
    I guess yes. 
    
    But, as I see STARLET.OLB referenced in the Object Module Synopsis
    below, I got this feeling and I wanted to sure about that part.
    
    
    
    OMN_STATISTIC   V3.7                 8291 OMN_STATISTIC.OBJ;1 
    OMN_API_GBLSEC  V1.0-002             2529 OMN_GWY_GBLSEC.OBJ;1        
    C$DSQRT_2       X_2                   492 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    MATH$SQRT_G     V1.0                  412 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    STR$MSGDEF      X-3                     0 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    CMA$TIS
    Thread-Independent Services          5152 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    DPML_FIND_CALLERS_PD_INIT
                    X-1                   220 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    MATH$EXCEPTION  V1.0                 3684 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    MATH$SQRT_G_TABLE
                    V1.0                 4128 SYS$COMMON:[SYSLIB]STARLET.OLB;3
    DECC$SHR        T06.2-05                0 SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1 
    LIBRTL          X01-001                 0 SYS$COMMON:[SYSLIB]LIBRTL.EXE;1
    
    
    What I really want to know is why MATH$EXCEPTION 'asks' for 
    STARLET.OLB and not a shareable 'variant' a la LIBRTL ?
    
    /Johan

   See what the LIB$CVT_TO_INTERNAL_TIME call is doing -- it *probably*
   isn't even being misused, and thus would be entirely insensitive to
   the increase in the delta-time limit provided by the ECO.  (Given
   that the call is referenced via LIBRTL, it shouldn't be a problem
   anyway...)

   I do not see anything in the posted portion of the map file that would
   indicate a relink is required.

	--

   As for your other question, you'll need to ask the DPML folks why
   STARLET.OLB was chosen in preference to the use of a shareable image.

>    CMA$TIS
>    Thread-Independent Services          5152 SYS$COMMON:[SYSLIB]STARLET.OLB;3

Uh Oh..  Is this your image?  If it's possible for this image to
be activated in a process where other applications are also active,
you should be linking against SYS$SHARE:CMA$TIS_SHR.EXE.  Having
more than one copy of TIS in a process is a _bad_ idea.

-Mary S.
 DECthreads

:  <<< Note 238.215 by PTHRED::MARYS "Mary Sullivan, DECthreads Engineering" >>>
:                    -< Oh - and you don't have to relink.. >-
:
:>    CMA$TIS
:>    Thread-Independent Services          5152 SYS$COMMON:[SYSLIB]STARLET.OLB;3
:
:Uh Oh..  Is this your image?  If it's possible for this image to
:be activated in a process where other applications are also active,
:you should be linking against SYS$SHARE:CMA$TIS_SHR.EXE.  Having
:more than one copy of TIS in a process is a _bad_ idea.

   The above issue, if it's not clear from Mary's note, has nothing to
   do with the 10K delta-time ECO -- you will want to research why these
   references to STARLET.OLB modules were generated, but you should not
   need to resolve these problems specifically for the delta-time ECO.

   For those of you with customers running early versions of OpenVMS, the
   following kits appeared in TIMA and DSNlink today:

[OpenVMS] VAXLIBR01_052 VAX V5.2 - V5.2-1 Delta Time (10,000 Day) ECO Summary
[OpenVMS] VAXLIBR01_053 VAX V5.3 - V5.3-2 Delta Time (10,000 Day) ECO Summary
[OpenVMS] VAXLIBR01_054 VAX V5.4 - V5.4-3 Delta Time (10,000 Day) ECO Summary

   
   Note that they are all "rating 3" ECOs. Here is an extract from the 
   release notes:
--------------------------------------------
                                *** Note ***                                  
                                                                              
     The  probability of experiencing the delta-time limit on earlier         
     versions of OpenVMS is significantly reduced because OpenVMS             
     DECthreads (both pthread and CMA interfaces) and the OpenVMS             
     SECURITY Server do not exist in versions of OpenVMS prior to             
     V5.5.                                                                    
                                                                              
     DIGITAL has created delta-time ECOs for OpenVMS Versions 5.0 -           
     5.4-3 for those customers possibly affected by the delta-time            
     limit or in the rare situation where a third-party or customer           
     application does not adhere to the delta-time limit.                     

...
     System/Cluster Reboot Necessary:  Yes                                    
                                                                              
     Installation Rating:   3 - To be installed on all systems running        
                                the listed versions of OpenVMS which          
                                are experiencing the problems described.      
--------------------------------------

     From the comments it appears we can expect ECOs for V5.1 and V5.0
     as well (but not for the customer who called me yesterday asking
     about V4.1 ;-)
						John Gillings, Sydney CSC

Well the US CSC received a call this weekend from a large steel producer to 
see if a 10K patch was going to be developed for their V3.4 system :*)

Jilly

   re: 559.0 by CSC32::E_VAETH

:A customer wants to know installing this ECO on his FT410 system running OpenVMS
:5.5-2 will be OK.  My initial thought is that there should not be a problem. 
:However, since the machine runs critical applications at a power plant, I
:thought I would check to make sure.

   IPMT this question, please.  I do not know if the FT410 and the
   fault-tolerate system services were tested in conjunction with this
   patch.

   I do not believe there will be a problem, but somebody needs to look
   at this combination and confirm it -- and that's what the IPMT is for.

   Pending an official answer, determine if the customer can perform the
   recommended testing on the BACKUP system, or on the primary when the
   system is accessable.  (Without having further evidence, there may be
   no need for this ECO on this version for this particular implementation.)

   Also, if you haven't already done so, please become familiar with the
   nature of the problem -- it may or may not affect any particular site.

:      <<< Note 238.218 by BSS::JILSON "WFH in the Chemung River Valley" >>>
:                 -< Another customer seeking a silver bullet >-
:
:Well the US CSC received a call this weekend from a large steel producer to 
:see if a 10K patch was going to be developed for their V3.4 system :*)

   Test the system.  I would expect few sites would have 10K-related
   problem(s) on OpenVMS versions prior to V5.5.

   (I view the release of these pre-V5.5 patches as a mistake -- they're
   not likely necessary save for any application-specific errors, they
   tend to imply the problem is in OpenVMS and not in a higher-level RTL
   or application, and they set entirely the wrong precident for Y2K.)

re .220
    
>   (I view the release of these pre-V5.5 patches as a mistake --
>    and they set entirely the wrong precedent for Y2K.)
    
    But on the other hand they provide a useful pointer for Y2K. The
    customer is always right. The same issue will arise with Y2K. We can
    be ready with the patches even if we don't think the customer needs
    them or we can scramble to create those patches in the face of an
    avalanche of nervous and underprepared customers.
    
    Regardless of whether the problem is in VMS, specifically an RTL, or a
    layered product, the customer will perceive the problem as having been
    created by *Digital*. Why would the customer care which particular
    component had a design or coding failure?

>   (I view the release of these pre-V5.5 patches as a mistake -- they're
>   not likely necessary save for any application-specific errors, they
>   tend to imply the problem is in OpenVMS and not in a higher-level RTL
>   or application, and they set entirely the wrong precident for Y2K.)

I figure the main reason behind the creation of pre-V5.5 patches is public
relations/damage control.  I'm also nervous about what this implies for
Y2K, though.  We don't have the resources to backport Y2K fixes to per-V5.5
releases.

-M

P.S. So where do you draw the line between what you call "OpenVMS" and the
     non-"OpenVMS" components that ship in the OpenVMS base kit?

>   <<< Note 238.222 by PTHRED::MARYS "Mary Sullivan, DECthreads Engineering" >>>
> 
> >   (I view the release of these pre-V5.5 patches as a mistake -- they're
> >   not likely necessary save for any application-specific errors, they
> >   tend to imply the problem is in OpenVMS and not in a higher-level RTL
> >   or application, and they set entirely the wrong precident for Y2K.)
> 
> I figure the main reason behind the creation of pre-V5.5 patches is public
> relations/damage control.  I'm also nervous about what this implies for
> Y2K, though.  We don't have the resources to backport Y2K fixes to per-V5.5
> releases.

The fact that components shipping on the VMS kit were affected proves
to some customers that making a D10K application mistake is "easy".
Other customers are convinced that it proves there was no need for
binary-to-binary delta time routines to be limited in the first place,
particularly in view of inadequate documentation for those not doing
ASCII conversions (see DECUServe discussion).  But the bottom line
is that DEC did "the right thing" to help all VMS customers deal with
this in a cost-efficient manner.

For Y2K I doubt there will even be an opportunity for DEC to invest
in some blanket fix since there will likely be no single common error
which can be fixed at the RTL level.

    I also view the release of the pre-V5.5 patches as a mistake. Many
    sites have made changes to VMS images along the way - this has
    traditionally been very easy to do on VAXes, given the microfiche kit
    and the PATCH utility. Over the years, these changes have been
    forgotten and even if the images were analyzed, the likelihood is that
    on any given site, no-one remembers *why* the patch was made, or *what*
    bug it fixed.
    
    Now along comes this D10K fix. Everyone panics and applies it, and
    maybe an existing patch gets lost along the way. The likely damage and
    problems resulting from this removal of an existing patch that the
    customer's application, even livelihood, depends on, far outweighs the
    likelihood of the D10K problem affecting said customer. 
    
    We are sacrificing common sense and rational thought to the god of
    panic, and to the rantings of people who have heard about the problem
    and assume it affects them, yet don't really understand it.
    
    For once, I'm going to say that I really don't think the customer is
    right. Pre-V5.5, the only sites affected by D10K are those that already
    had UNIX involved in their application and chose to use the UNIX epoch
    as the base date for their application, converting this to VMS as a
    delta time. But back then, there was very little portability between
    VMS and UNIX and very few applications shared between the two operating
    systems.
    
    Certainly, the artificial D10K limit, even though documented, will
    begin to give trouble when applications that have been around for 27
    years or more calculate delta times between events. But that's not a
    May 19th 1997 issue. It's an issue that has to be dealt with in its own
    right. BUT NOT IN PANIC MODE DURING THE NEXT 304� HOURS! PLEASE!
    
    - Richard.
    
    � Give or take a timezone.

    This is surely a subjective/religious issue.  Everybody is
    right and everybody is wrong.  Let not get carried away (we
    aren't yet, but I smell fresh meat... ).  
    
    Personally as an ex-customer, I'm glad that we issued the 
    pre-V5.5 patches.
    
    Lets look at the Intel floating problem (the last one, not the brand
    new one).  It was a problem that most people wouldn't see unless you
    knew just where to look (just like D10K on pre-V5.5), but the logical
    discussion soon gave way to emotion.  Once it became an emotional
    argument, logic wasn't relevant anymore.  It didn't quiet down until
    Intel (and the downstream vendors) had to just eat the cost of the chip
    swaps to get it behind them.
    
    This is just another case of a logical issue about to become
    an emotional one.
    
    				-John

    But in the Intel case there was no down-side to taking the fix. Here,
    there is a potential problem in doing so that may be worse than not
    taking the fix.
    
    fwiw
    
    - Richard

Re: Note 238.217 

>>>   For those of you with customers running early versions of OpenVMS, the
>>>   following kits appeared in TIMA and DSNlink today:
>>>   
>>>[OpenVMS] VAXLIBR01_052 VAX V5.2 - V5.2-1 Delta Time (10,000 Day) ECO Summary
>>>[OpenVMS] VAXLIBR01_053 VAX V5.3 - V5.3-2 Delta Time (10,000 Day) ECO Summary
>>>[OpenVMS] VAXLIBR01_054 VAX V5.4 - V5.4-3 Delta Time (10,000 Day) ECO Summary

    How about a location for internal customers?  Anybody have decnet 
    location for the above files.

    Much appreciated...

    Graham

:    How about a location for internal customers?  Anybody have decnet 
:    location for the above files.

   Via CSCPT2 or http://www.service.digital.com/html/patch_public.html.

   For the former, SET HOST CSCPT2, and log in under username GETPATCH.

   For the latter, use any web browser to pull down the current kits.

   And in general, I would *strongly* recommend getting IP configured,
   and a web browser running.  This can -- and should -- be done on
   OpenVMS, on NT, or on most any other platform currently available.

   Internal distribution directories are not commonly used, as they tend
   to get stale as new kits released, and kits are revised over time.

Greetings!

  Dumb question (for the paranoid):

  How should I use the VAXLIBR06_070.CHKSUM;1 file I just pulled from the 
external web site?

  Per that file:

vaxlibr06_070.a-dcx_vaxexe 527096731
vaxlibr06_070.b-dcx_vaxexe 1003325923
vaxlibr06_070.c-dcx_vaxexe 1785739664
vaxlibr06_070.d-dcx_vaxexe 2310443272
vaxlibr06_070.e-dcx_vaxexe 187212713
vaxlibr06_070.f-dcx_vaxexe 1744081472
vaxlibr06_070.g-dcx_vaxexe 3572792192

  But upon the following attempts to use this information:

AMCUCS> checksum VAXLIBR06_070.A-DCX_VAXEXE
AMCUCS> sh sym check*
  CHECKSUM$CHECKSUM = "3212069370"

  - no match!, so... -

AMCUCS> checksum/imag VAXLIBR06_070.A-DCX_VAXEXE
file AXPBIZ$DKA100:[DELTA]VAXLIBR06_070.A-DCX_VAXEXE;1
image section %D'1' checksum is %X'3A692931'
image section %D'2' checksum is %X'D07C0C0B'
image section %D'3' checksum is %X'11E7FBA1'
image section %D'4' checksum is %X'0A0254EA'
image header checksum is %X'52546C95'
checksum of all image sections is %X'F1F08A71'
AMCUCS>

  Nothing here looks like the number in that VAXLIBR06_070.CHKSUM;1 file.

  Am I using the "CHECKSUM" command incorrectly?  

  Is that VAXLIBR06_070.CHKSUM;1 file for a different OS/version? (I'm running 
  on an OpenVMS VAX V6.1 system).

  Is that VAXLIBR06_070.CHKSUM;1 file incorrect?

  Or (horrors!) is the VAXLIBR06_070.A-DCX_VAXEXE file been corrupted in some
  way?

  FWIW, the VAXLIBR06_070.A-DCX_VAXEXE file did decompress okay.  The resulting
VAXLIBR06_070.A;1 file is a real saveset that BACKUP could unpack okay.  The
final file size (126 blocks) jives with the size noted in one of the other text
files about the delta-time patch.  None of the other *.%-DCX_VAXEXE faired any
better and I'm just a little paranoid about pulling the wrong/broken savesets
before I install them, cheers...



						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"

   re: 238.229

   There's no clear documentation on what that checksum value is, nor
   how it is calculated, nor how to verify it -- I'd send a comment to
   the webmaster for the service site: [email protected].

   I've been looking around for this same information myself, and it's
   definitely lacking.

:  Dumb question (for the paranoid):

   If you're truely paranoid, get the CD-ROM distribution.

:None of the other *.%-DCX_VAXEXE faired any
:better and I'm just a little paranoid about pulling the wrong/broken savesets
:before I install them, cheers...

   The image activator and the SPOOL decompression code will produce a
   BACKUP saveset, and -- assuming the decompression code does not find
   any problems -- BACKUP is pretty good at flagging corrupted savesets.

Try the checksum on the uncompressed file.

		Steve

                                   Tensor Utility

                      Search Your Application for RTL LIB$ Time
                    Conversion Modules Linked Against STARLET.OLB


          May 1997




          Overview

          The Tensor utility can help identify customer applications that
          may need to be relinked in order to pick up the delta-time limit
          ECO. Tensor can be run on OpenVMS VAX V5.0 and later or OpenVMS
          Alpha V6.1 and later.

          After you have installed the delta-time limit ECO, use the
          Tensor utility to search image (.EXE) files for modules that
          contain the OpenVMS RTL LIB$ time conversion routines and that
          have been linked against STARLET.OLB to resolve references to
          system functions. Note that if Tensor finds a match, that image
          will not necessarily have a problem. An image containing the
          modules may not be invoking the changed routines. A problem
          will occur only if an affected RTL LIB$ routine is called with a
          delta-time value exceeding 9999 days.

          If sources are available, those sources should be searched and
          the routines identified and checked. In cases where sources are
          not available, relinking the image is the safest course.

          See the Guide to the OpenVMS Delta-Time Limit for detailed
          information about the impact caused by the method you use to
          link your application.

                                        NOTE

             If you are running OpenVMS Version 7.1, you do not have to
             install the ECO. However, you can use Tensor to determine
             how your pre-V7.1 applications running on Version 7.1
             were linked. (Applications linked under pre-V7.1 versions
             of OpenVMS that pull in modules from STARLET.OLB must
             be relinked. Applications with the 10,000 day problem
             that were linked under pre-V7.1 versions of OpenVMS and
             that pull in modules from STARLET.OLB must be relinked on
             either a pre-V7.1 system containing the ECO or on a V7.1
             system.)

          Description

          Normally, invocations of LIBRTL routines such as LIB$CVT_TO_
          INTERNAL_TIME are implemented as calls into the LIBRTL.EXE
          shareable image. However, it is possible to cause a copy of
          an object module containing a set of routines to be inserted
          directly into your image at link time. For example, the LINK

                                                                         1

 






          /NOSYSSHR option can be used so that a call to a LIB$ routine is
          resolved by copying the object code module from the STARLET.OLB
          object library into the resulting image. The LIBRTL routines
          that have been modified to eliminate the 10,000 day delta-
          time limit all reside in two object modules: LIB$DATE_CVT and
          LIB$DATE_ARITHMETIC.

          The Tensor utility allows you to find instances of the LIB$DATE_
          CVT and LIB$DATE_ARITHMETIC modules embedded in an image. Tensor
          searches image (.EXE) files for all released VAX and Alpha
          versions of these routines.

          Note the following:

          o  Tensor does not locate all uses of the affected RTL LIB$ time
             conversion routines. It does not locate routines that have
             been linked against the LIBRTL.EXE shareable image.

          o  Tensor cannot identify calls to individual routines within
             the modules, so it is possible that an image containing the
             modules may not be invoking the changed routines. That is,
             the image may use the modules in a "safe" way. Tensor merely
             helps locate images that require further attention. Without
             further investigation, the safest action is to relink images
             containing these modules.

          How to Use the Tensor Utility

          To use Tensor, the following files are required:

             tensor.cld
             tensor_vax.exe (for running on VAX)
             tensor_alpha.exe (for running on Alpha)

	  The files can be found here:

        	BULOVA::SYS$PUBLIC:

	        TENSOR.CLD;3               1  25-APR-1997 12:15:34.00
	        TENSOR_ALPHA.EXE;1        78   2-MAY-1997 12:54:32.00
	        TENSOR_VAX.EXE;1         520   2-MAY-1997 12:53:15.00

	        Total of 3 files, 599 blocks.

          Once these files have been copied to a directory such as
          DISK$:[TENSOR], the following OpenVMS commands are required
          to define the TENSOR command line:

             $ SET COMMAND DISK$:[TENSOR]TENSOR.CLD
             $ DEFINE TENSOR DISK$:[TENSOR]TENSOR_VAX.EXE  (or TENSOR_ALPHA.EXE)

          These commands are for a one-time use of the Tensor utility.

          A simple TENSOR command line has the following form:

             $ TENSOR filename [,filename...]

          Filename is a standard OpenVMS filename, which may include wild-
          card characters, logical names, or remote node names. The de-
          fault file extension used by tensor is .EXE. Tensor searches the
          files specified by the filename list for instances of LIB$DATE_
          CVT and LIB$DATE_ARITHMETIC. For each file searched, Tensor
          displays a message of the form:

             Searching <filename>

          When a match is found, Tensor reports it with a message of the
          form:

             Found <architecture> <module>

          2

 






          For example:

             Found VAX LIB$CVT_ARITHMETIC

          Two command qualifiers are allowed. The /NOLOG qualifier pre-
          vents Tensor from reporting which files are being searched,
          unless a match is actually found. The /OUTPUT=<filename> quali-
          fier allows Tensor output to be directed to the specified file
          rather than the terminal.

          What follows is a sample of Tensor usage and output.

             $ TENSOR CURR_RESD$:[UTIL.OBJ],SYS$LIBRARY:LIBRTL;*

             Searching RES_DISK$:[UTIL.OBJ]CREATE.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]DYNSWITCH.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]QUEMAN.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]RENAME.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]RUNDET.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]SET.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]SETP0.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]SETWATCH.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]SHOW.EXE;1

                     Found VAX LIB$DATE_ARITHMETIC

             Searching RES_DISK$:[UTIL.OBJ]SHWCLSTR.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]SUBMIT.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]TYPE.EXE;1

                     Found VAX LIB$DATE_CVT

             Searching RES_DISK$:[UTIL.OBJ]UNLOCK.EXE;1
             Searching RES_DISK$:[UTIL.OBJ]UTIL$SHARE.EXE;1

             Searching SYS$COMMON:[SYSLIB]LIBRTL.EXE;2
             Searching SYS$COMMON:[SYSLIB]LIBRTL.EXE;1

                     Found VAX LIB$DATE_CVT
                     Found VAX LIB$DATE_ARITHMETIC

          Note that for the LIBRTL search, a wildcard version number was
          specified on the command line, so all versions were searched.
          Normally the SYS$LIBRARY:LIBRTL.EXE image will always contain
          these modules. However, in this case, version ;2 includes the
          latest versions with the "10K Day" fix, so Tensor does not
          report a match.

          Below is an example of using Tensor with a remote node on the
          network.

             $ TENSOR NODE7"system randompswd"::WORK$:[PUBLIC.*]

             Searching NODE7"system password"::WORK213:[PUBLIC.BUILD]CREATE.EXE;3
             Searching NODE7"system password"::WORK213:[PUBLIC.BUILD]MOVE.EXE;1
                     .
                     .
             Searching NODE7"system password"::WORK213:[PUBLIC.TOOLS]LEXORA.EXE;6
             Searching NODE7"system password"::WORK213:[PUBLIC.TOOLS]SAMP.EXE;7

                     Found Alpha LIB$DATE_CVT
                     Found Alpha LIB$DATE_ARITHMETIC

                                                                         3

 






             Searching NODE7"system password"::WORK213:[PUBLIC.TOOLS]TRIAL.EXE;1
                     .
                     .




















































          4

Greetings!

  Re: .231

>Try the checksum on the uncompressed file.
>
>		Steve

  First thing I tried - no joy.  I'll send mail to the web site address, 
cheers...

						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"

Just taken a call from a customer who claimed that after installing the Delta
time patch, one of his applications fell over with IVTIME on his VAX 6.2 
systems.

When we investigated, we found that his code was subtracting a zero date/time
from the current date/time and then passing the result to SYS$ASCTIM.

It turns out that if the Delta Time patch has not been installed, LIB$SUB_TIMES
will return IVTIME in these circumstances. However, on systems on which the
patch has been installed, LIB$SUB_TIMES returns a successful status and it's
SYS$ASCTIM that fails with IVTIME, just like it should ...
And the customer's application was coded to handle errors from LIB$SUB_TIMES
but not from SYS$ASCTIM ...

Anyway, the customer has now gone off to fix his application, and I thought
that everyone should know about this change in behaviour.



	.Title	SubTimes

	$Lib$RoutinesDef

	.Psect	RwData	NoExe, Wrt, Quad
V_Tmp:	.Long	0
	.Long	0
V_Cur:	.Long	0
	.Long	0
V_Edt:	.Long	0
	.Long	0
XDate:	.Word	23
	.Word	0
	.Address B_Day

	.Align	Quad
B_Day:	.Blkb	23

	.Align	Quad
Sub_Msg:.Ascid	"Calling LIB$SUB_TIMES ..."

	.Align	Quad
Asc_MSg:.Ascid	"Calling $ASCTIM ... "


	.Psect	Code	Exe, NoWrt
	.Entry	SubTimes, ^M<>

	$GetTim_S	V_Cur

	$Lib_Put_OutPut_S	Sub_Msg
	$Lib_Sub_Times_S -
		V_Cur, -
		V_Edt, -
		V_Tmp
	Blbs	R0,	10$
	Ret


10$:	$Lib_Put_OutPut_S	Asc_Msg
	$Asctim_S -
		Timbuf=Xdate, -
		TimAdr=V_Tmp
	Blbs	R0,	20$
	Ret

20$:	Ret

	.End	SubTimes

VAXLIBR kits for V5.0-V5.0-2, V5.1-V5.1-1, V5.2-V5.2-1 have been released 
in the last 2 days and should be available via FTP, WWW and other methods 
shortly.

	Just a quick question.

Is there a way to install the VAXLIBR06_070 patch from batch?
I have a customer who has over 140 systems in different locations.
Would really like a way to batch this.

The only way I could think of possibly doing this is by modifying KITINSTAL.

I feel bad for the customer in that here in canada, they were not given 
as much warning about the problem as in other locations.

Any help appreciated!

		/Guy

:Is there a way to install the VAXLIBR06_070 patch from batch?

   VMSINSTAL supports an "auto answer" mode -- one can save the answers
   from one installation, and then relocate the answer file and reinvoke
   the VMSINSTAL installation -- the installation will be based on the
   contents of the auto-answer file.

   See the VMSINSTAL documentation around the use of option "A".

   You can also look at the use of OPCCRASH -- see SHUTDOWN.COM for
   the logical names it uses -- as this tool can be used to remotely
   crash a system.  (One cannot call SHUTDOWN from within batch, as the
   queues get stopped before the completion -- one can call SHUTDOWN
   from a detached process specifying the list of required parameters,
   or one can call OPCCRASH directly.)

    Hi,
    
    My customer has OVMS AXP 6.2-1h3 and applyed the patch and today
    rebooted the system. However, he has ORACLE applications and, only
    today, he was informed that is necessary to relink the oracle
    applications. The matter is that he has thousands of program to be
    relinked and he is not able to do this today. He wants to do that
    during the weekend. He wants to knonw is there is a way to have the
    system configured as before the patch application, without to execute a
    backup image of the system disk?
    
    Any help will be very welcome, Mauro.

   re: Note 238.238 by VAXRIO::MAURO >>>
       -< How to recover the system without backup? >-

   One looks at the KITINSTAL, sees which files are replaced, and then
   pulls these specific off a distribution kit or (better) recent full
   BACKUP placing them (carefully) into the appropriate SYS$COMMON:[*...]
   directly, and one then reboots.  One could also take a look at the
   "drop ECO" command procedure, but that has had a few bugs.  (See the
   previous discussions here around the known typographic error in some
   versions of the "drop ECO" comnmand procedure.)

   KITINSTALs are usually pretty easy to figure out.

re 238.237

Thanks for the answer.
This will really help.
/Guy

    If you were just using $numtim, (I.e., none of teh other restricted
    routines), because it's a system service rather than a library routine,
    is there any reason why you'd have to relink?
    I could only find $numtim in a shareable image, so it couldn't be
    linked as static code, could it?
    
    Thanks,
    Steve.
    

:    If you were just using $numtim, (I.e., none of teh other restricted
:    routines), because it's a system service rather than a library routine,
:    is there any reason why you'd have to relink?

   I would expect no need to relink an image that used the sys$numtim 
   system service call.  (And I'd expect most callers of sys$numtim
   would also continue to operate after 19-May-1997, with or without
   the ECO...)

.238>    during the weekend. He wants to knonw is there is a way to have the
.238>    system configured as before the patch application, without to execute a
.238>    backup image of the system disk?
    
    But WHY would they bother to go back (for a day) the patch does not
    break anything for them does it? It just gets them a more flexible
    machine. Not that it is applied, they should simply be happy.
    If they have a serious reason to be unhappy having applied the patch 
    which in the oracle case only set's up for the next step and does not
    really address a direct problem, then they should clearly articulate
    why they want to roll back. They should do so such that we can clear
    up a misunderstanding, or to have others benefit from their insights.
    
    fwiw,
    	Hein.
    

:.238>    during the weekend. He wants to knonw is there is a way to have the
:.238>    system configured as before the patch application, without to execute a
:.238>    backup image of the system disk?
:    
:    But WHY would they bother to go back (for a day) the patch does not
:    break anything for them does it? It just gets them a more flexible
:    machine. Not that it is applied, they should simply be happy.

   Hein has a good point -- they should not _need_ to relink en-mass,
   though they will want to relink in the near future.  (The need to
   relink images may or may not be necessary, but it will remove any
   chance the old (pre-ECO) code is incorporated from STARLET.OLB into
   any of the images -- the presence or absense of the patch will not
   alter this behaviour.)

  /Guy,

>Is there a way to install the VAXLIBR06_070 patch from batch?
>I have a customer who has over 140 systems in different locations.
>Would really like a way to batch this.

   See note 238.117 for full details on how to streamline bulk application
 of the ECO kit.
						John Gillings, Sydney CSC

  re .243: Hein,

    I've had one *geniune* problem caused by installing the patch. The customer
  was *relying* on the documented behaviour of one of the LIB$ routines
  returning an error on an invalid time value (> 10,000 days). As a quick fix,
  he needed to back out the ECO in order to keep his systems running while
  he planned changing his code.

    On the other hand, we've had *dozens* of people who've got themselves
  into trouble after installing the ECO and (naturally) blamed all their
  problems on the ECO. These have ranged from a VAXstation 3100 with a 1.3GB
  system disk on which SYSTEM_MESSAGES.EXE landed across the 1GB mark
  (system wouldn't boot) through all manner of "lurking" problems waiting
  for the next reboot to strike. The existence of the ECO_DROP makes it
  much easier for the CSC to convince them that the problems are NOT due
  to the 10K ECO.

    I've also had comments from many customers about how much they appreciate
  having the ECO_DROP procedure, even if they don't actually use it. It's
  worth having just to give confidence to system managers.

    This whole exercise has revealed that the "issues" are mostly perception.
  It doesn't matter how much technically accurate assurrances we can give,
  customers are very parinoid about their systems.

>they should not _need_ to relink en-mass

    We know this, and a certain data base company must know it as well, but
  they still insist that all their customers relink everything. That's their
  policy - "If there's a patch, install it, then relink everything in sight".
  Despite the inconvenience, many customers actually seem to like this as it
  makes them feel like they've done something! (plus job security?).

						John Gillings, Sydney CSC

Customer Barb Semon-Chambers (Seq. # C970509-723) tells me that she has 
gotten a COM file call SHOW10K off the Digital WEB site and it runs okay 
on her VAX.

If she runs this on her ALPHA from the System or other accounts it 
immediately quits with the only message visible being:

        %RMS-W-RTB, 512 byte record too large for user's buffer

Doing a SET VERIFY before running this gives no further information.

I have searched all replies to the VMS notes file under this note 238; where
DELTA TIME issues are discussed, and found nobody having reported a similar
occurrence running the SHOW10K.COM file on an Alpha system.

I am posting this to see if anyone else has seen this or has an answer.

Gary Matthews 
DTN 343-1139

   re: Note 238.247 by 29087::MATTHEWS_G
       -< Running SHOW10K.com on Alpha-%RMS-W-RTB >-

   SHOW10K.DCL was likely transfered to the target system incorrectly --
   the wrong FTP transfer mode was likely used.  

   I am not aware of any problems with the tool, but I have seen more than
   a few FTP browser downloads garble the file format of SHOW10K.DCL, and
   of the patch kits.  

   The web browser applies semantics to transfers based on the file
   extension (the buzz-phrase for this process is "MIME"), and some
   browsers default to "binary" format transfer mode on unrecognized
   file extensions, and some browsers use "text" mode transfers.  And
   sometimes folks are moving files between two systems via manual FTP
   commands, and they forget to specify the correct transfer mode...

   The patch kits need "binary" or "image" transfer mode, and SHOW10K.DCL
   needs "text" or "ASCII" FTP transfer mode.

   Call the file up in the editor and look at it -- it's a DCL command
   procedure with some imbedded Macro32 source code.

    	I need to clarify some customer doubts, about relink or not:
    
    do I need to relink an application linked this way:
    
    $link object-name (accepting all defaults!)
    
    Thanks, Mauro.

No.  By linking in the default manner, you will link against the shareable
RTL images including LIBRTL.

				Steve

:    	I need to clarify some customer doubts, about relink or not:
:    do I need to relink an application linked this way:
:    $link object-name (accepting all defaults!)

   Steve is correct -- the answer is no.  (And the reboot will take
   care of the other problem -- applications that were running before
   the ECO was installed.)

   You might want to provide the questions and answers, and the system
   manager's and application programmers documentation to the customer
   -- please see the web site for copies: http://www.openvms.digital.com.

    
    DECevent is on the list of BOTH LPs affected and LPs NOT affected ?
    
    What is correct ? (except installing the patch anyway...)
    
    Volker.

DECevent should only be listed on the "NOT affected" list.  

An updated version of the charts, incorporating this change, 
will be posted to the web shortly.

Mary

There are 2 other corrections that we'll be making to the tables. 
Based on information I received on May 8, we put StorageWorks RAID
and Disk File Optimizer (DFO) on the "impacted" table. (They'd
previously been categorized as not impacted.)  Well, it turns out
that there's no 10k effect on those products and they should indeed 
be on the "not impacted" list. We'll get the tables updated
as soon as possible.

- Sue

Hi,

This is an update about the delta time limit situation (aka the 10k day
problem, or the May 19 problem). Over the past 8 weeks or so, OpenVMS has
distributed quite a few mailings about this restriction, in an attempt
to inform the larger OpenVMS community and also solicit feedback about
any effects the limitation and its remedies might have on layered
products and applications.  If you've responded to the various polls
and mailings we've sent out, thank you for providing information!

The primary source of information about the restriction and various
ECO kits is the OpenVMS external home page on the World Wide Web.

	www.openvms.digital.com

If you take a look there now, click on the item titled DIGITAL 
OpenVMS Delta Time Limit Information. That brings you to the page
dedicated to delta-time information, where you'll find:

- The original DIGITAL OpenVMS Delta-Time Limit Notification Letter
  sent to customers in late February/early March.

- New cover letter targetted at users whose systems are running versions
  prior to V5.5.  Here you'll also find information and pointers to pre-V5.5 
  ECO kits for those customers whose testing has shown a delta time-related 
  problem on pre V5.5 VMS systems.  (The key word there is TESTING - users
  on pre-V5.5 systems should TEST before assuming that they have problems.)

- Updated Guide to the OpenVMS Delta-Time Limit for System Managers and 
  Application Providers.

- Updated Questions and Answers about the limitation and the ECOs available.

- SHOW10K DCL command procedure which checks to see if the ECO is present
  on your system.

- New table showing DIGITAL layered products and applications that _ARE_
  affected by the delta time limit. 

	***  Note that all affected DIGITAL LPs and applications work ***
	correctly after the delta time ECO is applied to the host system. 
	*****************************************************************

- New table showing DIGITAL layered products and applications that are NOT
  affected by the delta time limitation.

- New utility (called Tensor) that can be used AFTER the ECO kit has been 
  applied. Tensor identifies applications that must be relinked in order 
  to pick up the changes included in the ECO kit.


Information can also be found here:

	BULOVA::DOCD$:[10K] for documentation

		DELTA_GUIDE.PS;1      9-MAY-1997 10:16:24.00
		DELTA_GUIDE.TXT;1     9-MAY-1997 14:15:09.00
		DELTA_QA.PS;1         9-MAY-1997 10:16:53.00
		DELTA_QA.TXT;2        9-MAY-1997 14:38:37.00
		LETTER.PS;1           9-MAY-1997 10:24:41.00
		LETTER.TXT;2          9-MAY-1997 10:54:36.00
		LP_TABLE.PS;3         9-MAY-1997 10:56:52.00
		LP_TABLE.TXT;3        9-MAY-1997 11:42:13.00
		PRE55LETTER.PS;2      9-MAY-1997 16:19:28.00
		PRE55LETTER.TXT;2     9-MAY-1997 16:19:28.00
		TENSOR.PS;1           9-MAY-1997 14:17:40.00
		TENSOR.TXT;1

	BULOVA::PUBLIC2$:[REMEDIAL_KITS.10K_DAY] for ECO kits that
		can be applied to VMS sytems. Refer to the DELTA_GUIDE 
		or DELTA_QA for specific kit information.

	BULOVA::DISK$SYSKITS:[PUBLIC] for Tensor utility files:

		TENSOR.CLD
		TENSOR_ALPHA.EXE
		TENSOR_VAX.EXE
	
Just a note - in addition to the information that's been distributed 
internally, we've tried to reach customers through our CSCs, DIGITAL
Call Center, VARs, DIGITAL Services community, DECUS organization,
Software Products Library inserts, MDDS mailings, Ambassadors, INFORM 
article, USEnet newsgroup, ISVnet, ASAP partners...well, you get the
idea ;-)

Thanks for your help in addressing this situation. Be sure to
check out the updated information on the OpenVMS home page!

- Sue

> DECevent should only be listed on the "NOT affected" list.  

That should probably read "NOT affected except on 7.0", right?
Unless they somehow avoid using any threads delay/cond_wait calls..

I've been out sick and haven't been able to review the latest charts.
Guess I'd better..

-M

    Mary, I've talked with both Liesl Kolbe (primary DECevent contact) and
    Keith Brown of the DECevent team and both assure me that the product
    isn't affected. They say they've tested and have found no ill effects
    due to 10k. I made a special point of pursuing this with them because 
    I knew they're a threaded product and I raised that aspect when I
    sent mail to Liesl.  The tables reflect the info that the product teams
    fed back to us.  We can only ask "But are you sure?" so many times...
    
    - Sue

    At a site that we manage a customer was wondering whether the following
    limit is related to the "10K delta time problem":
    
    $a = f$cvtime ( " -9999-0:0:0.00" )
    $sho sym a
    A = "1969-12-28 15:05:15.96"
    which is fine.
    
    $a = f$cvtime ( " -10000-0:0:0.00" )
    %DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC
    format\-100000-0:0:0.00\
    which isn't.
    
    Now
    
    SPECIFY
    
      Date_Time
    
        Delta
    
           Delta time is an offset from the current time to a  time  in 
    the
           future.  A delta time has the following format:
    
               [dddd-] [hh:mm:ss.cc]
    
           You can truncate delta time on the right.  You can also omit 
    any
           of the fields in the middle of the format as long as you 
    specify
           the punctuation marks.
     
    This problem arises when dealing with long time employee records. I
    suspect it doesn't like to parse the longer string but why is this
    the limit? He thinks it's suspicious.
    
    Thanks,
    
    Dale
    

  Dale,
    The *ASCII* representation of delta times has always been, and probably
  always will be, limited to < 10,000 days. That's because there is only room
  for 4 digits in the day field within the documented string length of an
  ASCII format delta time string. This cannot be changed now without
  potentially affecting an unacceptably large number of existing programs.

  It's the routines which manipulate *BINARY* delta times which have had the
  limit removed. Prior to the ECO, all legal binary delta times could also
  be translated into ASCII. After the ECO, it is possible to have a valid
  delta time which cannot be translated into ASCII because it exceeds 10,000
  days (although it is now a fairly simple matter to write your own formatting
  routines).
						John Gillings, Sydney CSC 

  PS: for those with sharp eyes:

>    $a = f$cvtime ( " -10000-0:0:0.00" )
>    %DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC
>    format\-100000-0:0:0.00\
>    which isn't.

    The extra zero in the error message "-100000" appears to be a typo. I've
  tried the same command on numerous versions and all give the expected
  error message:

%DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC format
 \-10000-0:0:0.00\

    John,
    
    Thanks for the reply. After patching a pile of systems this sort of
    blind sided me. It confirms what I suspected.
    
    Rgds,
    
    Dale

   Direct ftp-accessable Internet path to the 10K ECO patches:

	ftp://ftp.service.digital.com/public/vms/axp/v7.0/

	   files: alplibr05_070.*

	ftp://ftp.service.digital.com/public/vms/vax/v7.0/

	   files: vaxlibr06_070.*

    We're here on the 19th and the world doesn't seem to have ended. Indeed
    the weekend appears to have been very quiet. As far as I can tell,
    there was only 1 10K related call logged, and that was asking if it was
    necessary to upgrade UCX.
    						John Gillings, Sydney CSC

Well the US CSC has been drowning in 10K calls all weekend and I'm dreading 
Monday.  It's amazing how many people believe it is the CSC's job to tell 
people how to use IE, Netscape, Kermit, et.c etc. to transfer files!!!

Jilly

>It's amazing how many people believe it is the CSC's job to tell 
>people how to use IE, Netscape, Kermit, et.c etc. to transfer files!!!

  Aha! Perhaps that's the difference. On CSC initiative, we distributed a
  CD to all Australian and NZ customers containing the 10K ECO kits. We also
  threw in all the other rating 1 ECO kits available at the time.

  Sounds to me like the investement in creating and distributing the CD
  has been recovered by the low level of panic.

						John Gillings, Sydney CSC

    You missed a revenue generating opportunity there. The CSC in a country
    I know wanted �200 a go for creating media for the patches.
    
    Actually I think the Australian approach makes complete sense which is
    why I am not surprised it wasn't used here. 
    
    regards
    john

   I had pushed for CD-ROM distribution of the 10K and other key patches
   here in the US, but this obviously did not happen.  (The SSB letter
   barely happened before 19-May-1997 at various European sites, leaving
   us with some rather unhappy European campers.)

   OpenVMS engineering has seen a variety of how-to-download questions,
   as well -- most tend to be either MIME errors, or transfer problems
   when the files are later FTP'd over to OpenVMS.

:      <<< Note 238.266 by HNDYMN::MCCARTHY "A Quinn Martin Production" >>>
:            -< ncsa's http server was affected (OpenVMS Alpha 6.2) >-

   NSCA was only affected on older releases of the NCSA software -- we
   tried duplicating the error on more recent versions of the webserver,
   and were unsuccessful.  (This caused us some initial confusion, since
   the NCSA webserver was one of the initial reports of the 10K problem.)

There are also some sites where their policies forbid downloading software of
any type - distributing a CD would have been advantageous there too.

				Steve

   re: Note 611.0 by ROMTSS::SALVATI 
    
   THIS CALL NEEDS TO BE ELEVATED THROUGH FORMAL CHANNELS *NOW*.  IPMT!

:    Is there any information on the "delta time patch" for OpenVMS/Alpha
:    V1.5 ...

   I've cross-posted this from 611.*.  

   See the other notes here in 238.*, and see the web site.

:     It seeems to me that this version is not mentioned, but today
:    which is the 19-may-1997 one of my customers which is running this
:    version, is having problems with the date being one year on the future.

   I'd be surprised if this were related -- when a user-misuses a call
   to several of the time-related OpenVMS routines, one would expect to
   see run-time errors as a result.  I am *not* aware of off-by-one-year
   problems in this context -- I *have* seen off-by-one-year errors in
   other contexts.  

   We need the specifics of the problem and how it manefests itself,
   since the delta-time ECO is *not* related to the SHOW TIME display
   of time, nor the storage or retrieval of quadword time under OpenVMS.
   The ECO affects *only* the conversion of delta-time time values, and
   only when documented limits are exceeded.
    
:    Engineering says now that the patch is needed from V5.0 VMS/VAX, so,
:    due to the fact that Alpha code is derived form VMS/VAX V5.4-2, to my
:    opinion the same patch is needed on OpenVMS/Alpha V1.5.

   No, we are *not* saying this -- we are *explicitly* saying the need
   for this patch is unlikely, and that we do not recommend installing
   the patch.  RELEASE OF THE PATCH WAS PERFORMED FOR PRE-V5.5 RELEASES
   ONLY FOR THOSE CUSTOMER APPLICATIONS THAT HAVE MISUSED THE DOCUMENTED
   OPENVMS SYSTEM SERVICE CALL FORMATS, using these calls for UNIX-format
   date operations.
    
:    I know this version is not supported anymore but we have 280 branches
:    of an italian bank with the Alpha server with the date incorrect.

   These folks have been running an unsupported version of OpenVMS.

   WE HAVE BEEN TELLING FOLKS TO UPGRADE FROM V1.5 FOR SEVERAL YEARS,
   AND FOR SEVERAL MONTHS IN THIS PARTICULAR DELTA-TIME CONTEXT.  We
   will continue to encourage these folks to upgrade from V1.5 to a
   supported OpenVMS version -- V1.5 is *not* supported, and has *not*
   been supported for quite some time.
    

    Just so folks know, the letters for Europe were sent from the European
    SSB in Galway. They were shipped during the week of March 17-24.
    According to the European SSB, all European shipments were complete on
    March 24.  Indeed, as several folks have noted, notification in Europe
    has been less than perfect and even as late as last Thursday and
    Friday, I was handling inquiries from folks there who had just heard
    about the problem.
    
    In addition to separate mailings, the OpenVMS Delta Time Letter was
    sent to all OpenVMS MDDS Service customers and it was included in the
    OpenVMS VAX Software Products Library (SPL) customer update package for
    March. 
    
    - Sue

    re .266
    
    I heard that the "OSU/1.8 web server" also malfunctions as of yesterday.
    I believe that I am running this but I installed the patch a while ago
    so haven't personally had any problems.

  re .265: (john)
>    You missed a revenue generating opportunity there. 

    Quite the contrary! The arrival of the CD has made people notice that
  they're missing system management expertise on site. I hear consulting
  services have had a significant increase in consulting work to go and install
  the ECO, we've also had numerous customers purchasing monthly system
  management visits and a few "upgrades" to service contracts (only those
  customers with media contracts received the CD without asking - "Well sir,
  if you're expecting that level of service, you need a different contract").
  Further, we've not had any arguments with customers along the lines of
  "What!? you want ME to pay for YOUR bugs?".

    Given these results, I've had people ask if engineering could please
  arrange for a similar bug next year sometime.... ;-)

						John Gillings, Sydney CSC

    Hello John,
    
    You're quite right, my first para wasn't entirely to be taken
    seriously. Sounds like people in MCS Australia understand the true
    meaning of "whatever it takes" and "value selling".
    
    Mind you, any customers in the same situation as myself may not even
    have noticed the problem. This is being written on a VAX/OpenVMS 6.1
    system which has INSPECT and Motif (serving Vt1300s) and Pathworks and
    a few other LP bits but deliberately *does not* have the 10k day patch
    applied (as an experiment to see how bad things might get, safe in the
    knowledge that this isn't a production system and can be reconstructed
    reasonably quickly...).
    
    So far, nothing unusual has happened, despite the lack of patch. 
    
    regards
    john

The below is being posted under Note 238 where issues relating to the DELTA 
TIME patch are discussed, in the VMS Notes conference - VAXAXP::VMSNOTES.
The purpose of that is to assist others who are researching or may note
similar circumstances.

This is also being elevated (Priority 3) because the customer did make a 
specific request that may not be able to be answered in the notes file.

That specific request has been copied from the bulk of the below descriptive 
text and is repeated immediately below:

.....................
I must request an answer on whether the version of MESSAGE_ROUTINES.EXE in
VAXLIBR06_070 patch did, or did not, contain the fixes that were in the
earlier CSC patch #1012 V1.6 (QMAN$02_U2055) and whether that version of
MESSAGE_ROUTINES.EXE is compatible with the versions of QMAN$QUEUE_MANAGER.EXE
and JBC$JOB_CONTROL.EXE from #1012.
.....................


Below this is the full reply received from the customer - Jess Goodman.
After that is the writeup I first Emailed to Jess, outlining how I understood 
his phone description of the problem, making my comments, and asking for his 
feedback on what I thought. I put the customer's reply to my mail first 
because it just seemed to make more sense that way.

Gary Matthews
==============================================================================
From:	LDRNIS::"[email protected]" "Jess C. Goodman" 19-MAY-1997 17:24:46.57
Subj:	VAX queue entries only 'STARTING' after install/reboot of VAXLIBR06_070

Right now everything is working ok.  Here's more detail on the problems
we experienced earlier.

First off our cluster is fairly large; 19 nodes about evenly split between
5.5-2H4 Vaxen and 6.2 Alphas.  And as I mentioned we use batch queues very
heavily; at some times of the day there may be 1000+ jobs per hour.

We rebooted all the Alphas yesterday before 0Z (we use UCT) and all the Vaxes
this morning between 6z and 9z.

Most systems came up ok.  One VAX 3100 Workstation (which differs from other
nodes in that we have VOTES=0 and LOCKDIRWT=0 on it because it is a slow
system residing outside our computer room) would not boot completely; it
always hung while doing a SUBMIT.  Several reboots were tried on it.

I then noticed that most batch jobs that tried to run on the batch queues of
an Alpha Station 400 got stuck in a "STARTING" state.  This node has been
rebooted 9 hours earlier and it's possible this problem started then (since
the queues on this node are one of several targets for generic queues this
problem may not have been noticed).  Rebooting this node resulted in this
same hang on SUBMIT as the other node.

I then attempted to fail over the QUEUE_MANAGER process from a VAX 4100A
to the other VAX 41000A we let it run on (these systems share some DSSI
disks where the queue manager files reside).  Both of these nodes had been
rebooted an hour before.  This is when the QUEUE_MANAGER process got stuck
in RWAST state.  We rebooted that VAX 4100A and the problems on the other
two nodes went away and I went home to got some sleep.

I was called at home several hours later.  I was told that many jobs were
stuck in the STARTING state and could not be aborted, and that other processes
were stuck doing SUBMITs.  I am not sure what node(s) these problems occured
on.  I advised them to move the QUEUE_MANAGER with START/QUEUE/MANAGER/ON=...
and if that failed to reboot the system that it was running on.  It was at
this time (14z) that I called in the problem.  It turned out that this time
the START/QUEUE/MANAGER/ON= worked and we have not had any problems since.

However because our site is so dependent on batch jobs we can not just wait
to see if this problem reoccurs and then move the QUEUE_MANAGER or restart
the JOB_CONTROL process(es).

I must request an answer on whether the version of MESSAGE_ROUTINES.EXE in
VAXLIBR06_070 patch did, or did not, contain the fixes that were in the
earlier CSC patch #1012 V1.6 (QMAN$02_U2055) and whether that version of
MESSAGE_ROUTINES.EXE is compatible with the versions of QMAN$QUEUE_MANAGER.EXE
and JBC$JOB_CONTROL.EXE from #1012.

Attached is all Opcoms today regarding the queue manager.  The SYMDELs
due to NOSUCHDEVs are due to network printers and are common.  However
there was a SYMDEL due to FNF when we attempted to move the queue manager
the first time, and a CREPRCSTOP due to NOSUCHJOB occured when we moved
the queue manager the second time.

--------------------Attachment-----------------------------------------

%%%%%%%%%%%  OPCOM  19-MAY-1997 08:49:50.69  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
%QMAN-E-SYMDEL, unexpected symbiont process termination

%%%%%%%%%%%  OPCOM  19-MAY-1997 08:49:50.72  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
-RMS-E-FNF, file not found

%%%%%%%%%%%  OPCOM  19-MAY-1997 10:22:30.14  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
%QMAN-E-SYMDEL, unexpected symbiont process termination

%%%%%%%%%%%  OPCOM  19-MAY-1997 10:22:30.16  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
-SYSTEM-W-NOSUCHDEV, no such device available

%%%%%%%%%%%  OPCOM  19-MAY-1997 10:25:05.36  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
%QMAN-E-SYMDEL, unexpected symbiont process termination

%%%%%%%%%%%  OPCOM  19-MAY-1997 10:25:05.38  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
-SYSTEM-W-NOSUCHDEV, no such device available

%%%%%%%%%%%  OPCOM  19-MAY-1997 10:31:36.32  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
%QMAN-E-SYMDEL, unexpected symbiont process termination

%%%%%%%%%%%  OPCOM  19-MAY-1997 10:31:36.34  %%%%%%%%%%%
Message from user QUEUE_MANAGE on AW4
-SYSTEM-W-NOSUCHDEV, no such device available

%%%%%%%%%%%  OPCOM  19-MAY-1997 13:54:02.70  %%%%%%%%%%%    (from node AW1    at 19-MAY-1997 13:54:02.65)
Message from user QUEUE_MANAGE on AW1
%QMAN-E-CREPRCSTOP, failed to create a batch process, queue BBSHRQ_WS4 will be stopped

%%%%%%%%%%%  OPCOM  19-MAY-1997 13:54:02.77  %%%%%%%%%%%    (from node AW1    at 19-MAY-1997 13:54:02.69)
Message from user QUEUE_MANAGE on AW1
-JBC-F-NOSUCHJOB, no such job

--------------------End Attachment-----------------------------------------

>Sequence number: C970519-1306
>\+-----------------------  Beginning of Screener's Text -----------------------+
>\<s3> vms 6.2 axp, cluster queue manager, after applying delta time patch
>\queues arenot starting. Sterl 27018
>\+--------------------------- End of Screener's Text --------------------------+
>SO
>Jess Goodman (  [email protected]  ) is running a cluster with 2 Alphas at
>VMS 6.2 and 2 VAXes at VMS 5.5-2H4.

>The queue manager is run by the VAXes since they are at VMS 5.5-2H4 and the
>queue manager patch for this was installed ~6+ months ago.

>The DELTA TIME patch was installed several days ago for the Alphas and was
>just installed for the VAXes yesterday when they found out their software
>needed for them to do that.

>Since the VAX Delta Time patch installation and reboot, they have seen jobs
>on the VAX nodes go into a 'starting' state and if they cause the Queue
>manager to fail over to the other VAX, the Queue_Manager process will go
>into a RWAST state forcing a reboot.

>I have checked the QMAN VAXQMAN01_062 patch cover letter to see that the
>three files replaced by this patch are:

>    2.3  Files patched or replaced for OpenVMS  VAX  V5.5-2,  V5.5-2H4,
>          V5.5-2HF

>      o  [SYSEXE]JBC$JOB_CONTROL.EXE (new image)
>      o  [SYS$LDR]MESSAGE_ROUTINES.EXE (new image)
>      o  [SYSEXE]QMAN$QUEUE_MANAGER.EXE (new image)

>where Jess feels that the replacing of the [SYS$LDR]MESSAGE_ROUTINES.EXE
>file with the MESSAGE_ROUTINES.EXE in the VAXLIBR06_070 patch is behind the
>queues currently being in a 'starting' mode.

>Rebooting since the reboot required by the patch install, the queues have
>functioned for a few hours till they again get to the state where all
>entries are 'starting'.

>I asked Jess for any QMAN messages in the operator.log and Jess has not
>looked there. He is certain that he would have seen any such messages since
>he has many terminals with OPCOM ENABLED.

>I searched the VMS Notes file and STARS for queue manager related problems
>relating to the VMS 5.5-2  installs of the Delta Time patch.

>Nothing there refers to known queue problems after installing the
>VAXLIBR06_070 patch.

>I did find a question in the LATMASTER notes file about queue problems after
>the VAXLIBR06_070 patch has been installed.
>NOTED::LATMASTER  #1312 15-MAY-1997 mentions (coincidental?) after the
>Delta Time patch problems, but that does not seem similar to my
>customer's problem.
>...............
>Note 1312 describe's a customer seeing the OPCOM message %QMAN-E-SYMDEL  -

>     %%%%%%%%%%%  OPCOM   6-MAY-1997 09:16:30.48  %%%%%%%%%%%
>     Message from user QUEUE_MANAGE on RRPAD
>     %QMAN-E-SYMDEL, unexpected symbiont process termination

>The reply:
>    Please obtain the process dump and use the PDA (Printsymbiont Dump
>    Analysis). See note HAN::LOOPING_LATSYM 96.
>...............

>For my customer with the queue entries 'STARTING' problem, the quickest past
>answer for queue entries 'STARTING' has been to (from the SYSTEM account) to
>DELETE the JOB_CONTROL process, then restart it -  @SYS$SYSTEM:STARTUP JOBCTL

>This has typically been a safe fix for VAXes whereas it has been less safe
>for Alpha systems where disk Shadowing is done and a 'Shadow patch' has
>been installed.

>It is unknown when the last reboot was done on the VAXes before the Delta
>Time patch was installed.

>I have had several problems where the customer installed the VAXLIBR06_070,
>then rebooted and then seen problems that had not occurred before. In
>those cases the real cause was not the application of the Delta Time patch
>but the fact that things (usually LOGICALS) have changed since the last
>reboot, and these logical changes were not entered into any COM file to be
>recreated after a reboot.
>... so, the logicals did not exist after the reboot.

>The real question here is whether the [SYS$LDR]MESSAGE_ROUTINES.EXE
>file replaced in the VAXLIBR06_070 Delta Time patch will cause any
>conflict/problem by replacing the [SYS$LDR]MESSAGE_ROUTINES.EXE which was
>put onto the system by the earlier install of the QMAN patch for VMS 5.5-2H4?

>This mail is being sent to the customer by EMail and depending in his reply
>to act of STOPPING and RECREATING the JOB_CONTROL process improving the
>situation and his direct searching of the OPERATOR.LOG file for any QMAN
>responses after the VAXLIBR06_070 install shed to see if more light can be
>shed on the problem...

>I will then post an edited version of this text into the VMS Notes file
>under note 238 where all Delta Time issues are discussed.

>Gary Matthews

% ====== Internet headers and postmarks ======    REMOVED

Thanks to fellow VMS Printing support teammate Barbara Barsin passing this 
around, what could have caused confusion and concern is now just a note to 
know.

Process symbiont 210:
%CMA-F-BADPARAM, parameter to DECthreads operation is invalid
%CMA-F-NOMSG, message # 00408194

This is caused when DCPS is running and the DELTA TIME Patch is not
installed.

DCPS (DECprint Supervisor) uses DECthreads.

Install the patch and reboot and all is well.

Just wanted to let others know under this note/reply where DELTA TIME issues 
are discussed.

Gary Matthews 

Hi Gary,
 
The most common cause of jobs and queues being stuck in starting state is the QMAN$MASTER logical not being
defined correctly and/or the database location of the .QMAN$QUEUES and .QMAN$JOURNAL files not being defined
correctly.  I know you've been through the process before of using SYSMAN to verify the setup is correct.  From
SYSMAN :

	SYSMAN>set environ/clus
	SYSMAN>do show logcial QMAN$MASTER
	.... verify the logical translates to the same PHYSICAL location on each node

You need to check the database location.  On the V6.2 systems this is easy just issue the 

	$SHOW QUEUE/MANAGER/FULL 


Master file:  WORK2:[BACKUP]QMAN$MASTER.DAT;
Queue manager SYS$QUEUE_MANAGER, running, on ADU26A::
  /ON=(ADU26A,FLASHR)
  Database location:  WORK2:[BACKUP]

...

The "Database location" must be the same phsical device and directory on all node.  A common problem is this
location being defined to SYS$COMMON:[SYSEXE] which differs among the nodes.  This setup causes jobs to
get stuck in starting state.

The SHOW QUEUE/MANAGER command is not available on V5.5-2 systems.  Aswin Kumar will add a reply to this note
with a pointer to a small program you can use on V5.5-2 systems to display the database location.  The poor mans 
method is to DUMP/REC the QMAN$MASTER file and examine the last block in the file for the location.

Dave

BTW - SYMDEL due to FNF means the image specified in the /PROCESSOR qualifier was not found in SYS$SYSTEM
      of the node attempting to manage the queue 

Hi Gary,
 
The most common cause of jobs and queues being stuck in starting state is the
QMAN$MASTER logical not being defined correctly and/or the database location of
the .QMAN$QUEUES and .QMAN$JOURNAL files not being defined correctly.  I know
you've been through the process before of using SYSMAN to verify the setup is
correct.  From SYSMAN :

	SYSMAN>set environ/clus
	SYSMAN>do show logcial QMAN$MASTER
        .... verify the logical translates to the same PHYSICAL location on
             each node

You need to check the database location.  On the V6.2 systems this is easy just
issue the 

	$SHOW QUEUE/MANAGER/FULL 


Master file:  WORK2:[BACKUP]QMAN$MASTER.DAT;
Queue manager SYS$QUEUE_MANAGER, running, on ADU26A::
  /ON=(ADU26A,FLASHR)
  Database location:  WORK2:[BACKUP]

...

The "Database location" must be the same phsical device and directory on all
node.  A common problem is this location being defined to SYS$COMMON:[SYSEXE]
which differs among the nodes.  This setup causes jobs to get stuck in starting
state.

The SHOW QUEUE/MANAGER command is not available on V5.5-2 systems.  Aswin Kumar
will add a reply to this note with a pointer to a small program you can use on
V5.5-2 systems to display the database location.  The poor mans  method is to
DUMP/REC the QMAN$MASTER file and examine the last block in the file for the
location.

Dave

BTW - SYMDEL due to FNF means the image specified in the /PROCESSOR qualifier
      was not found in SYS$SYSTEM of the node attempting to manage the queue 

    Hi Gary,
    
    	This is the information on a tiny tool that can be used on V5.5-2
    to find the the database location.
    
    	The pointer to the image is in
    
        BULOVA::SYS$TRANSFER:SHOW_QUEUE_MANAGER_V552.exe
    
   Regards,
   Aswin
    -----------------------------------------------------
    
    Notes of how to use the tool:
    ----------------------------
    
    1. Create a temporary directory and copy the current qman$master.dat to
    it.
    
       - $ CREATE/DIRECTORY [.TMP]
       - $ SET DEFAULT [.TMP]
       - $ SHOW LOGICAL QMAN$MASTER
       - if the above command says no translation, then the file, QMAN$MASTER.DAT,
         should be in SYS$SYSTEM.
       - copy the file using the following command:
       - $ CONVERT/SHARE SYS$SYSTEM:QMAN$MASTER.DAT *  ! copy to [.TMP]
    directory.
    
    2. Copy the tool from BULOVA::DISK$TRANSFER:[PUBLIC]SHOW_QUEUE_MANAGER_V552.EXE;88
       to your [.tmp] directory.
    
    3. Use the tool.
    
       - $ RUN SHOW_QUEUE_MANAGER.EXE
    
    4. Output will look like:
    
      -----------------------------------------------------------------
    
             $ SHOW QUEUE/MANAGER/FULL
    
            Queue manager SYS$QUEUE_MANAGER  running, on PIDGIN::
              /ON=(*)
              Database location:  SYS$COMMON:[SYSEXE]
    
      -----------------------------------------------------------------
    
                                               
    5. Others:
    
       - Errors:
    
         - If you get an error like:
    
              " file open failure on QMAN$MASTER.DAT          29"
    
           it means the file QMAN$MASTER.DAT does not exists at the place where
           the tool is executing.
    
         - If you have any other problem, then check for the protections on
           QMAN$MASTER.DAT and SHOW_QUEUE_MANAGER.EXE.
    
         - If you are running the tool on a different system and if that
           system is not the part of the cluster where queue manager is running
           then you will get the following error message:
    
                    %SYSTEM-F-NOSUCHNODE, remote node is unknown
    
        - If you are not getting the node name on where queue manager is running,
          like the following line:
    
            Queue manager SYS$QUEUE_MANAGER  running, on ::
    
          it means, you have not defined the SYSGEN parameter, SCSNODE,
          on your system.
    ------------------------------------------------------------------------------
                                                                                

   Should it be run against OpenVMS, the Tensor tool will detect the
   delta-time-related object module code it is designed to look for
   in the following OpenVMS images:

     TYPE.EXE
     SHOW.EXE
     OPCOM.EXE
     JBC$JOB_CONTROL.EXE

   These images do contain copies of the target STARLET.OLB object
   modules that Tensor is designed to look for, but these images do
   not use the code in a fashion that will violate the 9,999 day
   delta-time limit.

   In other words, Tensor reports against these images -- and any
   other images that Tensor might flag that are known to not exceed
   the 9,999 day delta-time limit -- can be safely ignored.

   The web site is being updated to reflect this information.

    re .274
    
    As other responses have indicated, the fact that the 10K day patch
    requires a reboot has meant that many latent system management problems
    have been falsely attributed to it. Perhaps the instructions for the
    patch should have requested a reboot before the patch (as well as one
    after). Y2K tip?
    
    Formal escalation is probably the only way to get an answer to the
    specific question regarding what fixes are in which MESSAGE_ROUTINES.EXE.
    
    Has the customer tried backing out the patch? I realise it is a bit
    late (why did they leave it to the last moment?). That will perhaps
    establish whether the new image is at fault - at the risk of causing
    May 19 problems instead.

>>    have been falsely attributed to it. Perhaps the instructions for the
>>    patch should have requested a reboot before the patch (as well as one
>>    after). Y2K tip?

Hey, I like that idea.  A check in kitinstal.com checking for system up
time - if its over, lets say 1 year, then suggest that reboot be done before
continuing - also letting them know that another reboot will be done after
the kit is installed.

It may not cut down on the number of calls logged but at least they will be
"other problems" and not the kit.

bjm

    re: .280, .281

    This ECO has had more visibility than most, but problems that are
    blamed on, but not in fact directly related to, any particular ECO
    kit are fairly common.

    There have been various problems� reported that would not have been
    "caught" by the "pre-reboot" -- we're in enough trouble just for
    requesting the reboot, I'd expect requesting a second would not
    be popular.  (Further, some existing systems reboot _slowly_.)

	--

    �Examples include use of a system disk larger than 1.073 GB on a
    VAXstation 3100 series box, and some sites that seemingly haven't
    defragmented a heavily used system disk in over a decade...  Both
    can prevent a bootstrap from completing...

	CROSSPOSTED on PAMSRC::DECMESSAGEQ note 2883.
    
	Hello,

	A customer is complaining that the behaviour of timeout parameter in
read routine has been changed after he applied DELTA TIME patch.

	He tested in two different systems. One running VAX VMS 6.2 and DMQ 3.2,
and other running VAX VMS 5.5-2 and DMQ 2.1. He relinked his programs after
    he installed the PATCH. 

	Both system reported same results :

	BEFORE DELTA TIME patch : read timeout = 0 (zero) means "wait forever"
	AFTER  DELTA TIME patch : read timeout = 0 (zero) means "no wait... "

	Is this the new behaviour of DMQ? If so, how one can put a read to
wait forever for a message ?

	Thanks in advance for your help.
	Best Regards,

re: Note 238.283 by VAXRIO::VITOR

   This needs to be elevated via IPMT, and we will need an example of
   exactly how the customer is performing the wait in the code -- what
   is the "read" routine, what is the wait routine, and how are these
   calls being used?

   If an OpenVMS call is in direct use here, send the IPMT at the OpenVMS
   folks.  If using a DECmessageQ call, send it to the DECmessageQ folks.

  re .282: (Steve)

> We Have Been Requested To Reduce Reboots...

  When we distributed our CD, we filled it up with ECO kits and sent a cover
  letter which recommended lists of ECOs for each version of OpenVMS. For
  example:

  OpenVMS/Alpha V6.1-*: ALPLIBR05_070, ALPF11X03_070, ALPSYS08_070,
	ALPSYS17_061, ALPRMS04_061 and ALPSMUP01_070. If using shadowing
	also include ALPSHAD09_061 and ALPSHAD12_061

  We figured this was a minimal set of "essential" ECOs which could safely
  be installed in one hit and only require a single reboot. 

  However, we had numerous customers who interpreted these lists as meaning
  that *ALL* the ECOs were required for the 10K issue. Similarly for the
  ECOs for DECnet/OSI and TCP/IP Services which we also included.

  I thought the wording was fairly obvious:

  "   Other patch kits are included for your convenience, should they be
  recommended by a Digital Services specialist. Before installing any patch,
  Digital recommends that you ensure you have a valid backup of your system
  disk and that you have read all the relevant release notes and cover
  letters."

  Next time I'll try to spell things out in words of one syllable. Even then
  there will be people who don't understand.

						John Gillings, Sydney CSC

Hi,

We got a report from several customers (and were able to reproduce it) that 
Patwhorks V4.*  is IMPACTED by Delta-Time limitation.

Any files that were changed after 19-May-1997, will have wrong date when seen
from a PC. 

Installing the patch VAXLIBR06_070 solved the problem.

Who do you notify if you want to update the list of impacted application on
the Internet?

Thanks,

	Ronen 

:Who do you notify if you want to update the list of impacted application on
:the Internet?

  The PATHWORKS team (if you're not on it) needs to pass the confirmation
  along to Sue Avery, with a list of affected and unaffected versions...

    re .286
    
    Thanks for the information. We've had several other reports of
    PATHWORKS V4.* needing the ECO kits. CSC has seen a couple of these
    reports and I've received one or two via mail. Please note, though,
    that according to the PATHWORKS team, V4.* of PATHWORKS isn't
    supported. Because of that, when they did their testing, the PATHWORKS
    team only tested the V5.* platform. 
    
    However, that said, PATHWORKS is the only product we've heard of so far
    that's been confirmed to be affected by the problem.  So far this week,
    things have far quieter than some of us feared ;-)
    
    - Sue
    

	re .274:

	I'm on the team that created the images in the VAXLIBR06_070 kit.
The MESSAGE_ROUTINES.EXE for V5.5-2 that was shipped in VAXLIBR06_070
contains all the fixes that were in the MESSAGE_ROUTINES.EXE shipped in
the QMAN$02_U2055 and VAXQMAN01_062 kits. (Since both QMAN kits were
mentioned in the note, I wasn't really sure which you are currently
running).

	In addition, the MESSAGE_ROUTINES.EXE V5.5-2 image shipped in
VAXLIBR06_070 is fully compatible with the versions of QMAN$QUEUE_MANAGER.EXE
and JBC$JOB_CONTROL.EXE shipped in QMAN$02_U2055 and VAXQMAN01_062.

	So, as Dave has indicated in .276 and .277, your problems likely
stemmed from issues associated with the reboot rather than from the content
of VAXLIBR06_070.


				Tom Cafarella

              <<< VARESE::$1$DKB100:[NOTES$LIBRARY]BODC.NOTE;1 >>>
                -< BASEstar Open and DEComni Device Connection >-
================================================================================
Note 145.0               19-MAY-1997 10K day Draws Near.              No replies
FRSSMS::CELLAM                                       18 lines  15-MAY-1997 11:55
--------------------------------------------------------------------------------
    19-MAY-1997 Nears on OpenVMS Delta-Time Problem
    ________________________________________________
    
    I just wanted to make sure that the DEComni users are aware that
    the above problem will probably cause a failure.  In the AST sharable
    we only use the CMA error handling, in all others i.e. omni_server
    and omni_basic we rely on the CMA time slicing and this will screw
    up applications caught running a 00:00 19-MAY-1997.  
    
    Typically most DEComni VMS applications use timers and these use
    the delta-time facility, again any applciation using a timer at
    the above time can expect problems.
    
    DECnet OSI Transport will also have problems, so in any event you and
    your customers should install the appropriate LIB fixes under OpenVMS 
    VAX and Alpha.
    
    Chris Ellam

  One for the corporate PR department -- time for a couple of letters
  to these newspapers, explaining what steps we took (well) prior to
  the 19-May-1997 date...

  (Why the 10K question below was posted to the alt.sys.pdp10 newsgroup,
  and not to comp.os.vms where we've been discussing 10K for months, is
  beyond me.)

  From Risks-Forum Digest  Thursday 22 May 1997  Volume 19 : Issue 18
------------------------------

Date: 22 May 1997 16:17:38 -0700
From: [email protected] (Smith and O'Halloran)
Subject: DEC's OpenVMS has Y2K problem on 19 May 97: UNIX compatibility

The 20 May 1997 editions of newspapers in Alameda County (east of the San
Francisco Bay) reported a problems where the police computers ran out of
dates.  The article said that Bay Area police departments in Emeryville,
Oakland, Piedmont, Walnut Creek, and portions of the Contra Costa County
Sheriff's Dept all use DEC's Open VMS System.  It appears that Open VMS hit
the equivalent of the TOPS-10 DATE75 problem on Monday, 19-May-97.

I posted to alt.sys.pdp10 this message:

>Why would a 64-bit OS have a 27-year date limit?  Something in the PDP-11
>compatible RMS stuff?  I can't believe that DEC didn't learn from the
>DATE75 problem.

Here is the response:
: From: [email protected] (Tim Shoppa)
: Newsgroups: alt.sys.pdp10
: Subject: Re: Open VMS has a DATE75 problem?
: Date: 20 May 1997 22:51:51 GMT
: Organization: TRIUMF, Canada's National Meson Facility
: Message-ID: <[email protected]>
: References: <[email protected]>
: 
: DEC did learn from the DATE75 problem.  The internal VMS representation
: of time works until 31-JUL-31086 02:48:05.47.  The problem with
: 19-May-1997 is that some C programmers like to know the number of
: days from 1-Jan-1970 (the Unix base time).  To do this, these
: programmers used some "Delta-time" routines that are part of the
: VMS system libraries.  These delta-time routines have a maximum of 9999
: days difference built in to them, and this maximum was well documented 
: in the library manuals.  Nevertheless, application programmers
: tended to ignore this restriction and use the delta-time routines
: anyway.  Recently, some optional components of OpenVMS (such as the
: Security Server) were written in C and would suffer from the same
: problems, so this delta-time trap was more insidious than just affecting
: third-party applications.
: 
: DEC, in order to step around this problem, has released patched
: delta-time routines which no longer have the original documented 9999
: day limit.  As a result, application programs written in C which
: calculate delta-times from 1-Jan-1970 will continue to work properly
: after the patch is applied, despite the fact that the application
: programmers blissfully ignored the documented restrictions.
: 
: The 9999-day limit on delta times had always existed.  It's just
: that the proliferation of programs which like to know the number of
: days since the Unix base time is now the largest abuser of this limit.
: Before 19-May-1997, you'd encounter exactly the same problems if
: you tried to calculate the delta-time between any two dates more than
: 9999 days apart.
: 
: Tim. ([email protected])

INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for "ReBoot", PDP-10, and Clan MacLeod.

    It's nice to see that *some* people understood the situation. Tim
    Shoppa has written an accurate and succinct explanation of the issue.
    Could someone offer him a job in PR? ;-)
    
    						John Gillings, Sydney CSC

>    It's nice to see that *some* people understood the situation. Tim
>    Shoppa has written an accurate and succinct explanation of the issue.

Except for the part about the Security Server being written in C. :-)

But I agree - it's nice to see someone who actually read and digested
the communications.

-M

    Please see 238.234 for what looks like a similar report.

    Note that there are cases where the time services `lie', and
    return a binary value slightly off zero.

    The lib$sub_times call itself isn't much more than some quadword
    math, many programs used the lib$subx and lib$addx calls before
    lib$sub_times was available.

:Does anyone want to change their mind about $BINTIM being aberrant at the 
:singularity of 0?

    Our nerve endings are sufficiently raw that I would be *very*
    surprised if anyone signed up to make a change in this area.


              <<< VAXAXP::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 694.0  $BINTIM 0 00:00:00.00 and 10000 day delta-time patch eff  No replies
COMICS::EDWARDSN "Dulce et decorum est pro PDP prog" 32 lines   5-JUN-1997 09:43
--------------------------------------------------------------------------------
Just thought I'd point this out, since it may or may not have been seen.
The previous discussion which talked about the concept of $BINTIM returning 
0,0 (it's doing the right thing since what it wants to return is (-0,-0))
is in Volume 10, note 1251.

Once upon a time, if (for whatever reason) you decided to get a delta-time of 
0 00:00:00.00 and used $BINTIM it returned 17-NOV-1858 00:00:00.00 (effectively)
since there is no delta-time representation of this.
When your program continued, assuming that you had a correct delta-time, when 
you subtracted this from the current time, LIB$SUB_TIMES would dutifully signal
an error, since there was the 9999 day limit to delta time and you had just
overflowed it. Quite what the programmer would then do about this I have no 
idea, but one must assume that they handled the status and tried something 
different.

Now, the LIB$SUB_TIMES no longer gives an error, but instead cheerfully 
delivers a delta-time (quite a big one). When the program attempts to turn this
(what it assumes is a valid ABSOLUTE time) into a string using $ASCTIM it of
course is completely unable to comply, or worse still, doesn't modify the 
string which was passed to it so that it contains the previous contents.
This could potentially cause some catastrophies.

Does anyone want to change their mind about $BINTIM being aberrant at the 
singularity of 0?

Ouch.

Any comments?

Neil.