another nit ...

[Peter Van Epp]

	Yep, this helps (and the current behaviour makes sense). To do what
I want to do I only need to skip the first man record and take the timestamp
from the first data record so my start time reflects when the data in the 
file started.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

> 
> Hey Peter,
>    Here is the logic behind the time values in the initial
> management record.  If we need to change it, lets
> do that.
> 
>    There are two time stamps in all argus records.
> For the initial management these times represent the
> argus startime and the current time.  The startime
> represents the time when argus started.  This is important
> for a client to know if argus is restarting.  The "current
> time" is the time when the record was generated.  Clients
> can use this time for synchronization purposes, or to
> calculate record propagation time.  That is, the time it
> takes for the ultimate receiver to finally get the record.
> When argus is generating a file locally, the currentime
> will represent when the file was originally created.
> This is not necessarily relevant to the time that a
> particular argus file was created, because this initial
> argus record is not modified when you post process the file.
> 
>    If you sort an archive file, and generate a new
> sorted argus file, the first record in the new file will
> be the original initial management record, unchanged.
> Same goes for a when you use ra() to pick out that one
> record of interest, and store it in a file.  The initial
> management record in the resulting file will be the
> original one.
> 
>    Now, this is an interesting issue, because when we
> aggregate archive files, and actually create new argus
> records, the original initial management record should
> probably be modified, since this is a brand new thing.
> And the argus ID in each aggregated record should probably
> change, and the transaction ID's and sequence numbers
> also should probably change, which they don't do today.
> 
>    Not to open up a can of worms, but we should have some
> understood "rules" as to what to do with the values,
> especially in archived files.
> 
> 
> Hope this helps,
> 
> Carter
> 
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York  10022
> 
> carter at qosient.com
> Phone +1 212 588-9133
> Fax   +1 212 588-9134
> http://qosient.com 
> 
> 
> 
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Peter Van
> Epp
> Sent: Thursday, May 31, 2001 4:22 PM
> To: argus
> Subject: another nit ...
> 
> 
> 	I just noticed this nit: the date on the initial man looks to be
> when the argus started rather than when the file was ripped out from
> under it (which was in fact 29 May 01 14:40). Assuming thats working as
> designed I 
> need to ignore the initial man line when figuring out when a file
> started.
> 
> 22 May 01 20:57:53    man version=2.0     probeid=3848370891
> 
>                                         STA
> 29 May 01 14:39:59    udp ,,,
> 
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
> 
>