Conference azur::mcc

1311.0. "Is the mcc_ats_link routine supposed to order time elements ?" by TENERE::LAVILLAT () Mon Aug 05 1991 12:43

I am currently trying to use the MCC_ATS routines to create complex scope
of interest to pass to NOTIFY or GETEVENT calls.

I have now a problem with the mcc_ats_link routine, which seems to apply
also by simply using the FCL.

I understood (guessed ^) by reading the SRM, that mcc_ats_link was linking
schedule/scope time elements and SORTING them.

In fact it seems that mcc_ats_link simply add the specified time element at
the end of the time frame.

Since mcc_event_get looks at the first time scope element to retrieve events,
if you do not order your time elements BEFORE calling mcc_ats_link, you will
get wrong results (FCL does not seem to re-order time element within a FOR 
clause).

As example, could you tell me if this GETEVENT request is valid or not, and
who is supposed to order the time instants : FCL/me or mcc_ats_link ?

Regards

Pierre.

Here is the log (with some debug output cuts) :

$ define mcc_event_log 129
$ mana/ent/deb

MCC> spawn show time
   5-AUG-1991 16:51:23
MCC> getevent osi a test a any event, for start (23:00,20:00,16:00) dur 1:00
DBG> e time_spec
MCC_TESTOBJ__GETEVENT_TESTOBJ\mcc_testobj__getevent_testobj\time_spec:  3181160
DBG> call mcc__ats_frame_dump ( 3181160 )
time frame at 308a68 hex
schedule
   is NULL
scope
   contains 3 elements
   element 0
      begin is ABSOLUTE:  5-AUG-1991 23:00:00.00 
      end is ABSOLUTE:  6-AUG-1991 00:00:00.00 
      periodicity is NULL
      period_end is NULL
   element 1
      begin is ABSOLUTE:  5-AUG-1991 20:00:00.00 
      end is ABSOLUTE:  5-AUG-1991 21:00:00.00 
      periodicity is NULL
      period_end is NULL
   element 2
      begin is ABSOLUTE:  5-AUG-1991 16:00:00.00 
      end is ABSOLUTE:  5-AUG-1991 17:00:00.00 
      periodicity is NULL
      period_end is NULL
value returned is 52854793
%DEBUG-I-DYNIMGSET, setting image MCC_TESTOBJ_AM
DBG> go
Tracing error paths in Event Manager
Waiting until ->  5-AUG-1991 16:53:59.07
Start_time =  5-AUG-1991 23:00:00.00
End_time   =  6-AUG-1991 00:00:00.00

FINAL wait time ->  6-AUG-1991 00:00:00.00
%MCC-I-CANCEL, cancel
EDQ_DEQW_SUBSCR_EVENT found alert termination request
Maintainer Thread was alerted during Timer Wait:
%MCC-E-ALERT_TERMREQ, thread termination requested
Failed to dequeue event:
%MCC-E-NOMOREVT, no more events in event queue
Get Event was Alerted
MCC> exit
%DEBUG-I-EXITSTATUS, is '%MCC-S-NORMAL, normal successful completion'
DBG> Exit 

I sent mail off to the kernel team, to find out what their expectations.
I will also see if I can find anything in the SRM that states what should
be done here, my guess is that a QAR is probably required.

jill

    RE .0:
    
    The mcc_ats_link routine does not sort the time elements, so the
    unpleasant behavior you see is expected.  This has already been QARed,
    and will be changed for V1.2.
    
    Ted

Thanks for your replies.

Just to be sure :

Will mcc_ats_link in V1.2 merge overlapping interval of times ?

If not I will have to do it myself as well as the re-ordering of time elements.

Regards.

Pierre.

    RE .3:
    
    mcc_ats_link does NOT merge overlapping time ranges.  Nor do any of the
    mcc_ats_get_* routines.
    
    However, mcc_event_get itself DOES merge overlapping time ranges.  All
    time ranges that overlap are combined into a single time range.  This,
    in effect, simplifies the scope-of-interest time expression used by
    mcc_event_get. 
    
    This seems to (with the V1.2 fix to mcc_ats_link) meet your
    requirements for events handling.  
    
    Ted

  RE .4

Thanks, it seems that I have what I need.

I just wonder why you do a part of the processing within mcc_ats_link and
a part within mcc_event_get, but if it works...

Regards

Pierre.