Conference csc32::consolemanager

    >$ console extract nodename/time/out=toto.log
        .
        .
        .
    >    24-Jan-1996 00:48:45  S-NORMAL, normal successful completion
        .
        .
    
    >    Is it possible to have the time stamp more precise like this?
    
    >    24-Jan-1996 00:48:45.12  S-NORMAL, normal successful completion
    
    >    I suppose we can not but can someone to confirm it?
    
    We could I suppose but I have to ask why? Your talking about hundreths
    of seconds and I'd like to know why it would be necessary to have 
    that level of granularity? Part of the reason it isn't is that
    PCM allows duplicate timestamps within a 1 second granularity.
    
    Regards,
       Dan
    
        Thanks a lot
        Domenico

	Dan!
    
>        We could I suppose but I have to ask why? Your talking about hundreths
>    of seconds and I'd like to know why it would be necessary to have 
>    that level of granularity? Part of the reason it isn't is that
>    PCM allows duplicate timestamps within a 1 second granularity.
    
    Our customer is programming for a French National Lottery.
    This hundreths of seconds are very important for him because he starts
    some actions routines who read differents PCM's logfiles and starts
    some programs in function of their timestamp. It means two events can be
    logged in te same second but which one is logeed first?
    
    I hope my explanations are comprehensible (understandable)
       
        Thanks a lot
        Domenico
    

    >Our customer is programming for a French National Lottery.
    >This hundreths of seconds are very important for him because he
    >starts some actions routines who read differents PCM's logfiles and starts
    >some programs in function of their timestamp. It means two events can be
    >logged in te same second but which one is logeed first?
    
    Events will be sent to your action routine in the order that they
    were received. They will also be logged in the order that they are
    received. You could do a direct comparison of the time_t value in the
    event packets. I suppose there are scenarios where events are detected
    within milliseconds on two different controllers and the less busy
    controller got it's event packet to ENS first. The point here is that
    because there is more than one controller and the fact that they log
    and scan for events independently of one another you'd still have some
    uncertainty.
    
    I also still don'tave a good handle on your problem and the problem
    with a 1 second granularity.
    
    Regs,
      Dan

    Thanks
    
    Domenico