Conference azur::mcc

    It should be valid.
    
    -Matt.

I pose the same question for BinRelTime.

--------------------------------------------------------------------------------

*SKIGOD> mcc set node haylof bra lib serv bra lib foo persistence time=00:10
DECmcc (V1.2.0)


Node LOCAL_NS:.haylof Branch Library Server Branch Library LOCAL_NS:.foo
AT 29-SEP-1992 12:27:38 Characteristics

Modification(s) completed successfully
                       Persistence Time = 0 00:10:00.00

*SKIGOD> mcc set node haylof bra lib serv bra lib foo persistence time=0
DECmcc (V1.2.0)

%MCC-I-NOPARCMD, 0
                 ^
%MCC-I-SYNTAXERR, Syntax error -- unable to interpret remainder of line
%LIB-F-AMBDATTIM, ambiguous date-time

    Well first off, what happens if you type 00:00?  The parser may not
    know how to interpret just 0 (it may be seeing that as the number of
    days, and cannot default the minutes, for example).
    
    -Matt
    

    
    
    
    RE: all
    It depends on what time syntax has been selected by the MCC user.
    
    For VMS time syntax, 0 is valid as an absolute time, but NOT as a
    relative time.  Expanding the relative "0" to "0:0" or whatever does
    not help.  The limitation here is the use of DCL routines to parse
    user-input time for VMS time syntax.  "0" is not a valid VMS delta time
    (to be translated to a MCC relative time) in this syntax.  Note that a
    single integer is interpreted as the hours field for both absolute and
    relative times.
    
    For DTS (ISO 8601) time syntax, 0 is a valid relative time.  If 0 is
    used as an absolute time, it is valid, but generates a time in the year
    0, which almost surely is not what you want.  An absolute time of 0 is
    invalid for scheduling.  Note that a single integer is interpreted as
    the seconds field for relative time and the years field for absolute
    time.
    
    The upshot is that MCC uses outside (external to MCC itself) time
    syntax for its operations, and is not in control of that syntax.  All
    in the interest of standardization and the un-NIH factor, which are
    worthy goals.
    
       Ted

For clarification:

1.  I had wanted to disable actions controlled by BinRelTime and BinAbsTime
    by making the time 0.  Are you saying this is not possible, at least
    for BinRelTime on VMS, because the FCL uses VMS routines to parse 0
    and 0 is an invalid VMS delta time?

    Assuming this is correct, it looks like I need another switch to turn
    on/off the functionality which uses the time value.  Sigh.

2.  I assume 0 is a valid BinAbsTime on VMS.  So I could specify 0 as the 
    value of my object attribute to disable functions based on that attribute.

3.  Another question regarding time.  We need a value for BinAbsTime to
    represent infinity (i.e. never).  Is 31-DEC-9999 a valid BinAbsTime on VMS?

    For clarification on my reply:
    
    In the binary formats, both BinAbsTime and BinRelTime can be 0.  Only in
    the parsing has there ever been a problem.  We had thought that a
    BinRelTime of 0 was valid on VMS, but it cannot be parsed properly from
    the FCL interface due to the aforementioned problem.  There was
    supposed to be a workaround in our code, but it does not seem to be
    there in the released software.  The time parsing behavior mentioned in
    .4 is the way it works at the FCL interface.
    
    For your questions in .5:
    
    1. In the V1.2 release of DECmcc, BinRelTime cannot be entered as 0 for
    the given reasons.
    
    2. 0 is a valid BinAbsTime for VMS and Ultrix.  Note that for VMS, it
    is interpreted at the FCL interface to mean "00:00 of today".  It does
    not mean the beginning of the time base.  Unspecified time fields
    default to the corresponding fields for today's date and time.  For
    Ultrix, it does mean the year "0", with all other time fields
    defaulting to the corresponding fields for today's date and time.  Be
    careful what you think you mean when all the world is defaulting around
    you, in possibly different ways.
    
    3. 31-DEC-9999 is a valid BinAbsTime for VMS.  Note that DECmcc already
    has a value for time infinity, detailed in the V1.2 release of the SRM. 
    We recommend that you use this mechanism instead of making your own. 
    The routine mcc_time_get_infinity( &my_infinite_time_desc ) writes the
    "infinity time" value into a previously created (by mcc_time_create)
    BinAbsTime.  The routine mcc_time_compare_infinity(
    &my_tested_time_desc, &comparison_result ) compares a BinAbsTime to the
    infinity time value and returns on of the values MCC_K_EQL, MCC_K_LSS,
    or MCC_K_GTR in the "comparison_result" (MCC_T_UNSLONG) parameter. 
    Both routines return cvrs of type MCC_T_CVR.  Our time of infinity is
    guaranteed to be directly portable (via mcc_call) between differing
    systems (VMS, Ultrix, etc) if the above routines are the only ones
    used.  Our time of infinity is at least as big as the one you propose.
    
       Ted

Re .6:

>    BinAbsTime.  The routine mcc_time_compare_infinity(
>    &my_tested_time_desc, &comparison_result ) compares a BinAbsTime to the
>    infinity time value and returns on of the values MCC_K_EQL, MCC_K_LSS,
>    or MCC_K_GTR in the "comparison_result" (MCC_T_UNSLONG) parameter. 

     Just curious :

     What does it mean when mcc_time_compare_infinity returns MCC_K_GTR ?

     Regards.

     Pierre.