Conference abbott::postmaster

1278.0. "MAILbus Postmaster for WANs *not* affected by Delta-Time Limit Problem" by MSKRAT::PAWELKO () Thu May 01 1997 17:55

Hello,


    The OpenVMS Delta-Time Limit Problem affects OpenVMS products
that use certain RTL library time conversion routines with delta
values > 9999 days.  

    While the MAILbus Postmaster for WANs product does use the
affected library time conversion routines,  it does not use delta
values greater than 9999 days.   Thus, I have determined that
it will not be affected by the OpenVMS Delta-Time Limit Problem.  

    Please inform any customers that may be concerned.  A detailed
analysis follows.


    Thanks,

         Mary 


===================================================================
OpenVMS Delta-Time Limit Problem
MAILbus Postmaster for WANs
29-Apr-1997


The MAILbus Postmaster for WANs product (SPD 36.59.06) is supported to
run on OpenVMS V5.4-3 through 6.n.    It does not depend on components
known to be impacted by the 10,000 day restriction.  Furthermore, 
although it does call some of the affected LIB$ calls directly, it adheres
to the 9999 day delta-time restriction, and would recover gracefully if 
by chance a delta time greater than 9999 was generated, causing an error
to be returned from these routines.  And finally, I found no evidence
that MAILbus Postmaster for WANs links against objects from STARLET.OLB.
A detailed analysis follows.

Mary Pawelko
(Former MAILbus Postmaster for WANs engineer)


============================================================================

Part I  Checking Direct Calls to Affected LIB$ Routines

MAILbus Postmaster for WANs does use the following affected library
and system routine calls:

   1. LIB$CVT_FROM_INTERNAL_TIME 
   2. LIB$CVT_VECTIM
   3. LIB$ADD_TIMES
   4. LIB$SUB_TIMES
   5. SYS$NUMTIM

After checking the code around each of these calls, I decided that the
chance of MAILbus Postmaster for WANs using a delta value greater than
9999 days is extremely unlikely (near impossible) and even if it did,
it would recover gracefully from the errors that would be generated in
all cases.  Detailed analysis follows.


1. LIB$CVT_FROM_INTERNAL_TIME:

a. DEPS$DDS.COB, 2 calls

   Call 1: does not use delta operation, OK
   Call 2: does use delta operation, but would only exceed 9999 days if
           it's been more than 9999 days since the last DDS extract;
           highly unlikely, but if it occurs, a warning will be logged
           and no DDS extract will be performed.
           Can be fixed by deleting [DEPS.DDS]LASTTIME.DAT.  OK.

           and can be fixed by deleting [DEPS.DDS]LASTTIME.DAT.  OK.

-----------------------------------------------------------------------------
2. LIB$CVT_VECTIM

a. DEPS$DDS.COB, 1 call
   
   Call 1: does not request that delta time be returned, OK

b. DEPS$SENDER.COB, 2 calls

   Call 1: does request delta time be returned, but uses a Postmaster/WANs
   system logical (DEPS$_TIME_OFFSET), which if badly defined defaults to
   0 (no time offset).  Worst case: If this logical was defined to 
   be > 9999 (highly unlikely and incorrect use of logical), a warning 
   would be logged and a 0 time offset would be used.  OK
          
   Call 2: does not request that delta time be returned, OK

c. DEPS$FERTCHER.COB, 1 call

   Call 1: does request delta time be returned, but uses a Postmaster/WANs
   system logical (DEPS$_TIME_OFFSET), which if badly defined defaults to
   0 (no time offset).  Worst case: If this logical was defined to 
   be > 9999 (highly unlikely and incorrect use of logical), a warning 
   would be logged and a 0 time offset would be used.  OK

-----------------------------------------------------------------------------
3. LIB$ADD_TIMES

a. DEPS$FETCHER.COB, 1 call

   Call 1: requests that absolute time be returned; uses a Postmaster/WANs
   system logical (DEPS$_TIME_OFFSET), which if badly defined defaults to
   0, as a delta time parameter.  Worst case: If this logical was defined to 
   be > 9999 (highly unlikely and incorrect use of logical), a warning 
   would be logged and messages sent to LAN Postmaster may have blank 
   posted, forwarded, delivered, and/or receipt dates.  OK
 
b. DEPS$SENDER.COB, 1 call

   Call 1: requests that absolute time be returned; uses a Postmaster/WANs
   system logical (DEPS$_TIME_OFFSET), which if badly defined defaults to
   0, as a delta time parameter.  Worst case: If this logical was defined to 
   be > 9999 (highly unlikely and incorrect use of logical), a warning 
   would be logged and messages would fail to be posted to Message Router
   because they would be missing posted dates.  Non-delivery reports
   would be sent and errors logged in this case.  This situation could be
   fixed by setting DEPS$_TIME_OFFSET to a reasonable and correct value.  OK

-----------------------------------------------------------------------------
4. LIB$SUB_TIMES

a. DEPS$FETCHER.COB, 1 call

   Call 1: requests that absolute time be returned; uses a Postmaster/WANs
   system logical (DEPS$_TIME_OFFSET), which if badly defined defaults to
   0, as a delta time parameter.  Worst case: If this logical was defined to 
   be > 9999 (highly unlikely and incorrect use of logical), a warning 
   would be logged and messages sent to LAN Postmaster may have blank 
   posted, forwarded, delivered, and/or receipt dates.  OK

b. DEPS$SENDER.COB, 1 call

   Call 1: requests that absolute time be returned; uses a Postmaster/WANs
   system logical (DEPS$_TIME_OFFSET), which if badly defined defaults to
   0, as a delta time parameter.  Worst case: If this logical was defined to 
   be > 9999 (highly unlikely and incorrect use of logical), a warning 
   would be logged and messages would fail to be posted to Message Router
   because they would be missing posted dates.  Non-delivery reports
   would be sent and errors logged in this case.  This situation could be
   fixed by setting DEPS$_TIME_OFFSET to a reasonable and correct value.  OK

c. DEPS$DDS.COB, 1 call

   Call 2: uses absolute time parameters which will return a delta time,
           but would only exceed 9999 days if it's been more than 9999 
           days since the last DDS extract; highly unlikely, but if it occurs,
           a warning will be logged and no DDS extract will be performed.
           Can be fixed by deleting [DEPS.DDS]LASTTIME.DAT.  OK.


d. SYS_RMS.C, 2 calls

   Call 1: uses absolute time parameters which will return a delta time,
           but would only exceed 9999 days if a mailbag received from
	   a LAN Postmaster is dated more than 9999 days ago (highly
           unlikely).  If this does happen, the error will be ignored 
           and the mailbag will be processed anyway.  If there is trouble
           processing the mailbag, it will be moved to the DEPS$DEPS:[DMP]
           directory after three unsuccessful tries.  OK.

   Call 2: uses absolute time parameters which will return a delta time,
           but would only exceed 9999 days if a mailbag received from
	   one LAN Postmaster is more than 9999 days older than
	   another mailbag received from that same LAN Postmaster (highly
           unlikely).  If this does happen, the error will be ignored 
           and the first mailbag will be assumed to be older.   OK

-----------------------------------------------------------------------------
5. SYS$NUMTIM

a. SYS_RMS.C, 2 calls

   Call 1:  Will never be made if delta > 9999 because the LIB$SUB_TIMES()
            call immediately before this call would detect and ignore the
            error.  A delta time would exceed 9999 days only if a mailbag 
            received from a LAN Postmaster is dated more than 9999 days ago 
            (highly unlikely).   OK

   Call 2:  Will never be made if delta > 9999 because the LIB$SUB_TIMES()
            call immediately before this call would detect and ignore the
            error.  A delta time would exceed 9999 days only if one mailbag 
            received from a LAN Postmaster is more than 9999 days older than
            another mailbag received from that same LAN Postmaster (highly
            unlikely).  OK

============================================================================

Part II  Checking For Links Against STARLET.OLB

I found no evidence that MAILbus Postmaster for WANs links against any
objects from STARLET.OLB.

1. All of the executables that compose MAILbus Postmaster for WANs link
against the "LIBRTL" shareable library.  I concluded this by using
ANALYZE/IMAGE on these executables:

DEPS$BREAKBAG.EXE
DEPS$BUILDBAG.EXE
DEPS$DDS.EXE
DEPS$DDSREMOVE.EXE
DEPS$DEINSTAL.EXE
DEPS$DIREXPORT.EXE
DEPS$DIRIMPORT.EXE
DEPS$FETCHER.EXE
DEPS$LOGVIEW.EXE
DEPS$POST.EXE
DEPS$SENDER.EXE
DEPS$UAIPROG.EXE


2. No option files reference STARLET.OLB or use the /NOSYSSHR qualifier.


3. There are a number of old, static object libraries that MAILbus
Postmaster for WANs links against.  I ran LIBRARY/CROSS_REFERENCE=ALL
on all of these object libararies, and found no evidence of calls to the
affected LIB$ routines or links against object modules from STARLET.OLB.

DCF_BASE.OLB
DCF_TRANSLATE.OLB
DCF_MAIL_CONVERSIONS.OLB
DCF_DSAF.OLB
WPABASE.OLB *
WPADOC.OLB *
KOALA.OLB *
XPORT.OLB


* - the LIBRARY/CROSS_REFERENCE=ALL ACCVIO'd when applied to these libraries
so results are inconclusive whether or not these old object libraries
contain calls to the affected routines.

        Thanks Mary.
        
        Dave Zaniewski