Conference azur::mcc

    Steve,
    
    I haven't tried this myself but it seems as though it should work.
    Try using the AT EVERY .... UNTIL statement without the START. I
    have used AT EVERY in rules but I have never put in UNTIL.
    
    ...brad

While were on the subject of alarms and times ... I noticed the following:

1) Start times must be specified as START=(16-MAR-1990)  with the ()s
   but UNTIL must be specified as   UNTIL=20-MAR-1990    without the ()s
   Why?  Other specifications return 'Illegal scheduling time specification 
   in alarm expression'.

2) Why are alarms only active as long as the MCC image that started them is
   active? (this may have been posted in an earlier note, but I couldn't find
   it)

 /Claudia Peters, NSSG

    
    How does AT work....
    
    AT is the preposition/qualifier.
    
    START is a set (that is why the parenthesis's) of start times. This
    can be an absolute (date-time_of_day or time_of_day); a relative
    time (+ or - some number of hours); or it can be omitted (meaning
    start it when entered by the user or command procedure).
    
    EVERY is a relative time (+ or - some number of days-hours_minutes)
    used to denote how often to repeat something.
    
    UNTIL is an absolute or relative time used to say how long to continue
    for. If useing mutitple start times I would suggest using a relative
    end time.
    
    For what you are looking for I would suggest removing the abolute
    start time, thus having your commands start when ever the procedure
    is started.
    
    RE: .2 question 2
    
    This limitation is being worked on (to the best of my knowledge).
    This is a current limitation.
    
    

RE: .0

HI,

I've been using the "at" prepostion and have found that the way it works with
respect to "start" time is NOT how I want it to (any other supporters?).
Specifically, when I specify a start-frequency-end_time  and the start time
is "before" the current time the command is not executed and I get
  %MCC-W-TIME_ALREADY_PA, MCC$CALL schedule time passed.
What I want is for the scheduler to start even though the starting time has
passed when a future end time has been specified.

Here's an example of how I had to "work around" the current implementation. I
wanted to submit a mcc batch job every morning (when will 'time' expand to
day-month-year ??) to enable a set of alarms. With the current implementation I
had to start the batch job early to guarantee it's starting time was before the
mcc "at" start time. This is simple to do but from a user point of view doesn't
seem right.

jrp> Following Brad's advice in .1 will allow you to start the batch job at any
     time and the rules will get enabled properly.  That is, if you don't 
     specify a START time, the default is the relative time "NOW".  You can
     also use a relative UNTIL time (e.g., UNTIL=+05:00:00 - 5 hours from the
     start time).

What are your thoughts? How about some reasons why the way it currently works
is the right-best way.

jrp> Wow!  Justification!  I'm not sure that I can handle this one, but I'll
     try.

     In MCC, two kinds of time are defined:

       o Scheduling time
       o Scope of interest time

     Scheduling time is represented, at the user interface (i.e., TRM and/or
     Alarms) with the AT preposition.  It is used to schedule the execution of
     the command typed in at the command line or the evaluation of the alarm
     expression specified in the rule that gets enabled.  

     It just didn't make sense to accept the command "TEST x AT 10:00" when it 
     is noontime.  If x was tested at noon anyway, the results might be mis-
     interpreted to be applicable for 10:00.  Yes, I realize that a timestamp
     is returned with the results, but...

     Now, it might make sense to let the command TEST x at 10:00 slide by
     when it is 10:00:05 or 10:00:15, but how close is close enough?  It's
     pretty subjective.  I'm not sure what rules the MCC scheduling system
     currently uses.

     It does make sense to process the command "SHOW what the value of x was 
     yesterday, right now".  For this kind of command, both scheduling time
     and scope of interest time are employed:

       SHOW x AT START=NOW, FOR yesterday (actual syntax not shown)

     Hope this helps...

     I, for one, would be interested in hearing more from you about why this
     "doesn't feel right".  How close does a scheduling time have to be to
     be close enough in your mind?

Thanks, ===Steve

RE: .2

> 2) Why are alarms only active as long as the MCC image that started them is
>    active? (this may have been posted in an earlier note, but I couldn't find
>    it)

Claudia:

  This is a limitation of Alarms for v1.0.  As note 124.2 states, alarm rules
  are processed (evaluated periodically over time) in the process in which they
  are enabled.  When that process "goes away" the rules are no longer 
  operational.

  We are evaluating two possibilities for future releases:

    o Privately implementing detached processes   
    o Using distributed MCC as a means for implementing detached processes

  Stay tuned... I'm as anxious to find out the answer as you are!  :)

                                                                      - Jerry

HI,

Please excuse me when I run on about a "problem" and it turns out I just don't 
know all the available syntax options. I just don't have the time!

Now that I understand the at syntax my first statement till applies.
In my opionion,
If a user specifies  a start-frequency-end_time and the start time has past
he still might expect the whatever to startup and continue until the end time.
===Steve

    Hello,
    
    Re:  .5 (alarms & processes)
    
    Having the ability for alarms to run without the user process is
    VERY important from a network operational standpoint. Present
    release schedules show distributed MCC not coming along until
    Oct '91 FCS. Which means probably about April '91 for IFT of V2.0.
    That's a LONG time to wait. Detached process and a shorter time
    frame gets my vote.
    
    ...brad

    re: .6
    
    I understand your request, if the entire scheduling time has not
    passed, then start up anyway and let it finish. This is doable,
    but is it right...this is a question that can be addressed for version
    1.1. For the short term we are working this issue from a documentation
    stand point; meaning, we are looking to see what the parser* can
    do to return a better, more descriptive, error message. One of the
    basic problems with time already passed, is that the AT clause has
    multiple times in it, and that what the user means might not be
    what the code is interpretting the clause to mean. An example we
    hit not to long ago was the following command entered at 9:00
    (time and exact syntax have been changed slightly)
    
    	AT start = 10:00 every +1:00 until 8:00
    
    What they meant was start at 10 in the morning and run until 8 at
    night, but the 8:00 was interpretted as 8 in the morning. The error
    returned was time already passed. This was made even more confusing
    because the end time preceed that start time, and this error was
    not printed. It took the user a while to determine what was wrong.
    Hopefully the new messages will make it easier to understand what
    it wrong.
    
    

    Actually, since it seems that MCC uses VMS like time arguments, why not
    permit "TODAY" as equivilent to "NOW" since you allready let people use
    "TOMORROW" etc. In the case where you want to look at data from some
    time in the past to some time in the future, "TODAY" means 00:00:00.00
    on today.
    
    s/rob
    

    The distinction between TODAY and NOW is that TODAY is 00:00:00.00
    (midnight of this day) while NOW is what ever time it is when the
    user enters the command. NOW is the default for any commands where
    the start time parameter is not explicitly stated.
    
    The followig is a sample run using the two keywords in X0.10.0
    (internal baselevel).
    
    DECmcc (X0.10.0)
    
    MCC> spawn show time
      17-MAY-1990 09:10:14
    MCC> !!!!! THIS WILL EXECUTE IMMEDIATELY, NOTE THE TIME ON THE
    MCC> !!!!! "AT" LINE OF THE HEADER
    MCC> test node4 joppa, at start=(NOW)
    Node4 JOPPA
    AT 17-MAY-1990 09:10:56
    
    
    Node Testing completed successfully.
    MCC> spawn show time
      17-MAY-1990 09:11:04
    MCC> !!!!! SINCE TODAY MEANS MIDNIGHT, AND IT IS ALREADY 9am THEN
    MCC> !!!!! THIS COMMAND SHOULD FAIL SINCE THE TEST COMMAND CAN ONLY
    MCC> !!!!! BE REQUESTED TO RUN THE TEST NOW OR SOME TIME IN THE
    MCC> !!!!! FUTURE (TODAY IS REALLY ONLY USEFUL FOR THOSE MODULES
    MCC> !!!!! THAT ARE SUPPORTING REQUEST IN PAST TIME, LIKE PERFORMANCE
    MCC> !!!!! ANALYSIS ON HISTORICALLY RECORDED DATA - V1.1 FEATURES)
    MCC> test node4 joppa, at start=(TODAY)
    %MCC-W-TIME_ALREADY_PA, MCC$CALL schedule time passed
    MCC>
    

Am running the FT1.1 software on VMS 5.4 system. Basically followed the 
procedures outlined in Chapter 5 of the DECmcc Alarms Use manual. Have a batch 
similar to that on pag 5-13 . It appears to be running since the batch log
file indicates the alarms are enabled and it appears to be active in the system.
When I activate another MCC sessions and do a SHOW MCC 0 ALARMS RULE * ALL
CHARACTERISTICS it state all alarms are STATE = DISABLED

It might be nice if the users on the system had a way of viewing all the enabled
alarms assuming they have the right privs, protection, etc. 

In order to get around the disabling of the alarm when the process ends, I gave 
the SHOW command in the BATCH job a +10. 

As the previous entries seem to state, 2 things are needed.

1. The ability to declare an ALARM as a permament entity to always be running 
even if the process stops

2. The ability to view the enabled alrams from any MCC process if privs,protects,
etc. are ok.

> It might be nice if the users on the system had a way of viewing all the enabled 
> alarms assuming they have the right privs, protection, etc.                      
>                                                                                  
> In order to get around the disabling of the alarm when the process ends, I gave  
> the SHOW command in the BATCH job a +10.                                         
>                                                                                  
> As the previous entries seem to state, 2 things are needed.                      
>                                                                                  
> 1. The ability to declare an ALARM as a permament entity to always be running    
> even if the process stops                                                        
>                                                                                  
> 2. The ability to view the enabled alrams from any MCC process if privs,protects,
> etc. are ok.                                                                     


  I couldn't have agreed with you more! In order to implement the above 
  functionality, Alarms could either use a private protocol to communicate
  to the background process, or wait for MCC director to be able to do
  Director to Director communication. We in Alarms have prefered to wait
  for Kernel to provide the detached process communication functionality. 
  V2.0 of MCC will be supporting detached process communication.

  - Anil Navkal