Conference azur::mcc

I'm quite sure the problem is on the node you poll and not in MCC.
Counter Creation Time is a synthezised attribute computed by subtracting
Seconds Since Last Zeroed from the actual time of the request. It is
used as a reference for the PA to figure out if the reported counter
partition is valid. In your case it is not, and therefore PA cannot
calculate any meaningful value. 

So either the clock on your MCC system is broken (very unlikely) or the
Seconds Since Last Zeroed reported by the node is crap. 

What kind of machine do you poll and what is a zt-0-0 circuit?

*Robert

The node being polled in this example is a VAX 3100 M80, and ZT-0-0 
represents a port on a DSW42 (dual line controler) with the ZTDRIVER.

However, the example is not the only affected node there are a great
many, 3100, 4000, 4200 VAX systems, with either DSV or DSW devices.
Any of these node's historical data can easily reproduce the output 
example of .0, with the same PA command.

The same command performed in current or future time will succeed.

I've so far....

1) suspended all recordings
2) purged all historical data
3) deleted all recordings
4) defined all new recordings
5) restarted all new recordings

The results come back the same as .0

Perhaps your suggestion on the system clock is correct.  I'll check into
any type of diagnostics for the processor.

I'd like to eliminate any possible old definitions, polling data, 
corruption etc, and start the recording effort from scratch.

Can you tell me how this could be accomplished, short of reinstalling
MCC?

Thanks,

- Jeff

Jeff,


I was starting to tell you to remove the repository file as we sometimes do on
Ultrix and I remembered that you are running on VMS. 

On Ultrix, if the MIR files are deleted, they get recreated the next time the
application needs them. I don't know if it is the same on VMS or not. 

If you want to take the risk and try, the historical MIR files should be located
under the directory associated with the domain. Do a show domain xxx all attrib
and you should have the directory. Regarding the historical recording commands, 
I don't know where they are stored, but it is likely to be in a MIR file. You
might want to check in the current MIR location (/var/mcc on Ultrix) for an
historian MIR file. 

Another thing I have noticed in your command is that the duration and the
interval are both of 15 mn, so there is some overlap. I am not familiar with the
PA and I don't know if this is something recommanded or allowed, but if your
clock is correct and if it is not explicitely listed in the PA docs, that might
be another direction to check. 

Best regards,

Marc.

	Jeff,

	Your problem with historical data returned by the Show command
   is due to your time specification.  
	
>show node4 modsto circuit zt-0-1 seconds since last zeroed, -
>for start = 07-FEB-1994:12:00 until 07-FEB-1994:13:00 every 00:15 -
>duration 00:15, in domain rpt_nsrsnj
> 
>will return the following, in this *exact* order, note the time recording
>the mir is producing, and the sequence of this yield... (i.e. the second
>entry AT  7-FEB-1994 12:06:37 Counters appears twice, once as the second
>entry, and again as the 4th entry)
   .
   .
   .
>It is as though there are several processes storing data into the MIR for the
>same entity at the same time.

   When you specify past time in the Show command this request is processed
   by the Imformation Manager (IM) which goes to the historical MIR to get data.
   IM returnes data which are closest to the specified time. So for a single
   point of time IM returns data just before and just after this point. For
   a time interval IM returns data in this interval as well as data just before
   beginning of this interval and just after it.

   In your command you specified a repeated time interval:

     Data in MIR
         
              
     1. 11:51
              <------
     2. 12:06       : 1 interval 12:00 - 12:15
              <------
     3. 12:21       : 2 interval 12:15 - 12:30
              <------
     4. 12:36       : 3 interval 12:30 - 12:45
              <------
     5. 12:51       : 4 interval 12:45 - 13:00
              <------
     6. 13:06

 
     The following data samples are returned:

	- 1 interval (12:00 - 12:15):  1 - just before
                                       2 - in the requested interval
			               3 - just after 

        - 2 interval (12:15 - 12:30):  2
                                       3
                                       4

        - 3 interval (12:30 - 12:45):  3
                                       4
                                       5

	- 4 interval (12:15 - 12:30):  4
                                       5
                                       6  

	You can get all historical data between 12:00 and 13:00 by specifying
    the following scope of interest time "for start 12:00 duration 1:00:00".

>Partitions are for Identifiers, counters, characteristics, and status
>all of which are polling at 15 minute intervals (15 minutes is a waste
>for all but counters, however other error messages have shown that
>characteristics were not available, etc)

	Historical Data Use manual recommends polling interval be different
  for different attribute partitions. I think that error messages you saw
  were due to the incorrect time specification in the Show command.


	Your next problem with Show past time statistics. Be sure that you
  recorded ALL partitions required for statistics calculation (you can find
  this list in PA manual).

	SAm	

Greetings Jeff/SAm,

I had worked with Elizabeth on this and had done some poking around and wanted
to share some of this as some procedures I wrote helped set up the environment.

The initial error is created when asking for statistics. Jeff, please verify
the following command still produces the error.

show node4 modsto circuit zt-0-1 all statistics, -
for start 4:0 every 1:0 until 8:0 duration 1:0, in domain rpt_nsrsnj

%MCC-E-TIMELEMISMATCH, time_element does not match TIMEFRAME elements.

I saw the above error when playing on the system with a similar time syntax. I
have been using this syntax for years and would think it is valid for your
system. Assuming you used the MCC_RPT procedures to set up the RECORD 
statements then you should be polling

	CIRCUIT COUNTERs Hourly
	LINE CHAR Daily
	CIRC CHAR Daily

You can verify this with SHOW RECORD <entity> part=*, in domain <domain>
Polling these entities at these intervals has also worked for us (and many 
others) for years.

Also when poking around I noticed some time parameters which might be giving
you this headache. The system in Chicago had Eastern System Time, the mcc_tdf
logical didn't look quite right either. To add to the confusion the other dns
system sharing the info is in another time zone. Does anyone know what values
of time to check to ensure all is set correctly (ie. system time, mcc_tdf, 
local dns_tdf, remote dns_tdf, anything else)???

Lastly, if you think you have the system times and tdf's set correctly I would
delete ALL the *.*HIST* files you have. Deleting these will get rid of not only
the stored data but also RECORD schedules themselves. From here, reissue the
procedure which executes the RECORD commands from MCC_RPT to start polling
fresh. Wait a day and try again.

best regards,
brad...