| The schedule and scope parts of a time frame are more independent than
what you assume. For all the mcc_ats_get_* routines, a relative scope
of interest is evaluated against the CURRENT scheduled time, or against
the current system time (sticky - obtained only once for relative
evaulations until the next mcc_ahs_reinit or an mcc_ats_set_current) if
there is no schedule time active. A scope of interest evaluation does
not take into account any of the schedule time components in the time
frame itself. It uses only the schedule time context that is contained
within the handle parameter of the mcc_ats_get_* call for the scope of
interest evaluation. This is the time context that is set during the
mcc_ats_set_current routine, or during an mcc_ats_get_* call, for the
schedule time component. An mcc_ats_get_* call for the scope of
interest does not update in any way the schedule time context contained
in the handle parameter.
Therefore, what you need to do is perform an mcc_ats_get_* call for the
schedule time component to set the schedule time context in the handle
to the desired time. Then perform the mcc_ats_get_first call (for a
relative scope of interest there can only be a single time range (no
periodicity) to get the beginning and ending time of the scope of
interest. Then compare the test time against the scope of interest
beginning and end times. Note that as the EVERY (periodicity) is
contained only within the schedule time, an mcc_ats_get_* call must be
made to move to the next period to evaluate the scope of interest (or
do your own mcc_ats_set_current for the schedule time component).
Now for the bad news:
If you examine the description of the mcc_ats_link routine in the SRM,
you will note that the UNTIL time is always ABSOLUTE. This puts a
severe crimp in the use of relative scope of interest times. Given
that the relative scope of interest times are evaluated relative to the
schedule time (or current time if there is no schedule time in the
handle), a relative scope of interest with a periodicity will always be
terminated at the SAME absolute time, regardless on any periodicity.
If the schedule time also has a periodicity, the resulting evaluation
becomes essentially useless. For this reason, we are not supporting
(at the user interface level) relative scopes of interest (FOR clauses)
containing periodicity. All periodicity MUST be done in the schedule
time component of the time frame (AT clause at the user interface).
Now for the worst news:
The description above of how the relative scope of interest is
evaluated against a schedule time context (or current time if there is
no schedule time context) is how it SHOULD work. Due to a bug in the
mcc_ats_get_* code, a relative time is always evaluated against a
sliding current time. Each time the mcc_ats_get_* call is made, the
then-current system time is obtained and used to evaluate the relative
scope of interest. Successive calls to mcc_ats_get_first for a
relative scope of interest will always result in DIFFERENT scope of
interest beginning and end absolute times. There is nothing you can do
to force it to use a base time that you specify. This is being fixed
for V1.2 as I write this (another engineer is doing it). Then the
relative scope of interest will be evaluated against a fixed base time,
either the current schedule time or a snapshot of the current time that
is used for all successive scope of interest evaluations (until a call
to mcc_ahs_reinit for the handle or mcc_ats_set_current for the
schedule time context is made).
Therefore, in order to do the evaluation that you want, you should do
an mcc_ats_get_first for the scope of interest to get the absolute
beginning and end times (mcc_ats_get_* routines only return absolute
times). Quickly grab the current time with a call to
mcc_time_get_current. Subtract this current time from the beginning
and end times to get relative beginning and end times. These times
will be approximately the same as those originally put into the time
frame during the mcc_ats_link call. Now you can do mcc_ats_get_* calls
on your schedule time, add in the relative scope of interest beginning
and end times yourself, and determine if the test time fall into the
resulting time range. This is a bit laborious.
There are no plans to have scope of interest evaluations examine the
schedule time component of the time frame. We will continue to use
only the schedule time context contained in the handle of the
mcc_ats_get_* routines. If you want to suggest a better plan, please do
so. We have no illusions that the scheme we have is perfect or even
complete (witness the absolute UNTIL time in the mcc_ats_link routine,
which is not currently scheduled for repair in V1.2).
Ted
|