Conference azur::mcc

    Richard,
    
    Could you please give us more info on where you're using the BinRelTim
    datatype in the Iconic Map?  Is it one of your arguments?
    
    I believe the time of zero will be valid in some future version of MCC.
    The current time routines use the VMS routines which don't support a
    time of 0 properly (I think?  Could someone from the Kernel team
    verify?)
    
    Christine
    

Christine, it is an attribute which is a sequence of records, one of the
fields of the record is BinRelTim.

TYPE
    AvgDLDLoadTimeRecord = 15 RECORD
                               Name        = 0 : DLDName;
                               AvgLoadTime = 1 : BinRelTim;
                              END RECORD;
TYPE
    AvgDLDLoadTimeSeq = 16 SEQUENCE OF AvgDLDLoadTimeRecord;

       CHARACTERISTIC ATTRIBUTES
         ATTRIBUTE Average Load Time = 7 : AvgDLDLoadTimeSeq
           ACCESS = SETTABLE,
           DISPLAY = TRUE,
           SYMBOL = ATTR_AVG_LOAD_TIME,
           DEFAULT = NO DEFAULT,
           CATEGORIES = (CONFIGURATION)
         END ATTRIBUTE Average Load Time;
       END ATTRIBUTES; (* CHARACTERISTICS *)

    Richard,
    
    We tried out a few arguments using the BinRelTim datatype:
    	Arg1 -- BinRelTim datatype
    	Arg2 -- Record containing BinRelTim in one of its fields
        Arg3 -- SetOf the above Record
    
    In all instances, the BinRelTim was passed down correctly,
    including    10 00:00:00.
    
    Which version of the MCC are you running?  The only possibility
    that I can think of is that there was a bug in a low-level Record
    datatype routine in the version prior to the one that we have here
    in MCC-land.
    
    Christine
    

RE: .3

Christine,

One of these days I'll learn to always cite the version I'm running and
save you the trouble of asking...

It is T1.1.0, 

MCC_ICONIC_MAP_PM.EXE;3
                     21-NOV-1990 14:13:06.35
 

I just tried it again, and can still reproduce the problem of it not
accepting 10 00:00:00 (validation error).

    There should be another kit coming out real soon.  Dave Moore announced
    it in another note in here, asking for volunteers.  Could you try it
    out in that new kit?  If you still have problems, let us know ASAP.
    But for now, it always works on our latest private version of the
    Iconic Map.
    
    Christine
      

re: .5

The problem reported in the basenote was indeed corrected in the V1.1 SSB
kit. But we're still concerned about the limits on the range of 
acceptable values for BINRELTIM.

We're trying to use BINRELTIM to represent durations in the lifecycle
of removeable media. These times can be on the order of decades, such
as the data retention time of a magnetic tape. We also need a way to
represent infinity, as in "never release this tape". Since BINRELTIM
doesn't have a representation of infinity, we could use 0 to disable
releasing a tape. But...

A value of zero is still not accepted. A value as small as 0 00:00:00.01
works, but no smaller. This is probably because VMS Delta times are
represented as negative values to differentiate them from absolute
times.

Values greater than 248 days are not accepted. It will take 248 23:59:59.99
but it won't take 249.


MCC> set medial test persistence time = 248 23:59:59.99

MediaLibrary DEC:.CXN.S.DBS-AIM.MCC.RSK.test
AT  4-SEP-1991 13:17:30 Characteristics

Modification(s) completed successfully.
                       Persistence Time = 248 23:59:59.99


MCC> set medial test persistence time = 249 00:00:00
%MCC-E-BIN_REL_TIM_ERR, error in Binary Relative Time value

It would seem that the 63-bit magnitude could accomodate much larger numbers
of days. If these are real restrictions of the VMS Delta time representation,
we'll use an integer number of days for these attributes, as they don't
need 100-nanosecond resolution in any case.

Thanks.

    Yes, you are right about the VMS delta time restriction of not
    being able to represent 0, as the cause of the MCC time problems
    you describe.
    
    Yes, there is a bug where we cannot accept more than ~248 days.
    
    Yes, there is need (and in fact a bug) where we need to be able
    to represent the concept of Infinity both as a relative time and
    as an absolute time.  I would prefer that Infinity be a keyword at
    the User Interface, and then we can represent it internally which
    ever way we want.  Developers would then call Time routines to
    ask, "Is this value Infinity?"  We have the ability internally
    to use Infinity as an absolute time, but these are undocumented
    routines.  In general, we have been representing the magic
    Infinity value as the largest displayable value for that Time
    Management System.  For example, on VMS, Infinity for Absolute
    time is something like "31-DEC-9999 23:59:59.99".
    
    We will be migrating over to DTSS as our time manager (instead of
    VMS) for V1.2, at that time, most of our problems will be solved
    (I think).  I will check to see which of these bugs will be fixed.
    The Time person for MCC is now Ted Hupper (TOOK::HUPPER), you may
    want to send him mail for any more specific concerns (about DTSS,
    etc.)
    
    -Matt.

    RE .6,.7:
    
    The V1.1 time routines suffer greatly from using VMS time routines. 
    
    The V1.2 time routines, as Matt mentions, use the DECdts API routines
    for performing all time calculations.  It is NOT necessary to have
    DECdts installed or running on your system.  The 2 outright bugs
    mentioned (no "zero" relative time and no relative time > 248 days) are
    completely fixed in V1.2 in current baselevels.  Relative times can now
    be in the order of 3600 years, according to the DECdts people.  Is that
    enough?
    
    We are not changing our current implementation of infinity time for
    V1.2, so absolute times have an infinity value of "31-DEC-1991
    23:59:59.99" for either VMS or Ultrix.  We have no specific relative
    infinity time, but the larger possible relative values allow selection
    of something like "> 1000 years from now == infinity".  This might be
    safer than reserving zero relative time for infinity.  A zero relative
    time is only sitting on the continuum of positive to negative (DECdts
    allows this) relative values, and can arise from time calculations in
    the darndest places.
    
    RE .7:
    
    Matt, I'm at TOOK::T_HUPPER.  How soon we forget. :^)
    
    Ted

>    We are not changing our current implementation of infinity time for
>    V1.2, so absolute times have an infinity value of "31-DEC-1991
>    23:59:59.99" for either VMS or Ultrix.  We have no specific relative

You mean 31-DEC-9999 23:59:59.99 for absolute infinity, don't you Ted? 
                ^^^^
Or should I  be ready to unload my stock ? ;^)

/doug

re: .8

>    completely fixed in V1.2 in current baselevels.  Relative times can now
>    be in the order of 3600 years, according to the DECdts people.  Is that
>    enough?

I do believe that will be sufficient. (And if it isn't at least *we* won't
be dealing with the QAR :-)  )

Thanks.

    RE: .9
    
    Yes, 31-DEC-9999 23:59:59.99 it is for absolute infinity.  Been working
    on the time routines too long - got that "1991" burned into my
    eyeballs. :^]
    
    Ted