Conference azur::mcc

Hi,

	I don't know why, but you cannot get the attribute Terminal Server 
	Uptime, using the TSAM.	But, the attribute you could calculate the 
	UPTIME from, is SECONDS SINCE ZEROED. I'm using the following rule 
	to check for terminal server resets (and It works):

	EXPRESSION  = (Terminal_server * SECONDS SINCE ZEROED < 320 ,-
                       AT EVERY 00:05:00)

	Question for engineering: Could be interesting also, an easy way 
	to trap the DECnet event LOAD REQUESTED from the load host, (without 
	writing myself a program communicating with the EVL...)

Thanks,

Jose Ignacio.	

The reason TSAM does not have server uptime, it that surprisingly enough
DECmcc does not provide such a basic datatype.  TSAM could probably have
provided a Latin1String with the number, but that would not be that useful
in this context.

As for DECnet events...that is in the DECnet IV AM, which I know nothing
about...

-Dave

    Dave,
    Could you describe what the "Server uptime" attribute would look like?
    We support a large number of time datatypes, I'm surprised that none of
    them can be used.
    
    -Matt.

It is a dddd hh:mm:ss.mmmm date/time (or yyy ddd hh:mm:ss.mmmm) which
basicly represents a *quantity* of time, not an absolute time, and
not a time which is relative, since this time information is essentially
a zero based counter on the device being managed which has been converted
into a format which is convient for the user to understand.

This time has no relation to the host, because the clock on the host and
the clock on the managed device are not synchronized, therefore it
would be incorrect for the host to convert any time it recieved into
some absolute or relative value in relation to the clock on the host.

As it stands, TSAM converts an easily read counter datatype into a difficult
to understand datatype.  (Quick: is 1675461 Seconds Since Zeroed yesterday
or last month?)  At the time I came upon this thing (already coded in TSAM)
I went over and asked about it.  I don't think anyone understood me.
The only option would have been for me to have created a custom datatype
with all of those values.  Since it was a lot of work, and people would not
have been able to alarm on it, I didn't do it.

This is not a concept which only occurs on Terminal Servers I suspect.

-Dave

BTW 1675461 seconds is aprox 19 days...

    Dave,
    
    Sorry, what I heard you describe was a relative time.  I understand
    what you are saying, but it is still a relative time (which is a
    *quantity* of time, and NOT synchronized).  Declare the string as a
    latin1string, put it in a descriptor, call mcc_time_convert() to
    convert it to an MCC_K_DT_BIN_REL_TIM datatype and return it (well,
    okay, the yyy portion would need to be fixed because it's an invalid
    delta time format).  If you examine the BinaryRelativeTime structure
    that the time routines returns you will notice that the TDF will be 0,
    and the Inaccuracy will be 0, which is correct.  Relative times are not
    synchronized, and as you stated, it has no relation to the host.  The
    end users will be very happy.  MCC might have trouble displaying a
    relative time which is greater than a year (I don't know), but that
    would be an MCC bug.  Relative times can be many hundreds of years.
    (BTW: have you ever seen a Terminal Server which has been up for a
    hundred years? :-)
    
    -Matt.

Matt-

Thanks,  actually I should have been more persistant, I've gone back and
looked at the SRM, and now I remember why this did not look like what I
wanted.  The SRM (Incorrectly I imagine) includes a definition of

	VMSDeltaTime ::== <dd> "-" ....
	          dd ::== "1" .. "31"

I don't know why that turned me off, I *know* what the correct definition
of VMSDeltaTime is!

Anyway, this looked like something that is not relative time.  I imagine the
code works correctly, it is just the documentation that was wrong.  There
should be no upper limit on days.  I don't think VMS relative time has years
anyway, then you get into all sorts of complications trying to figure out
how many days (and hours, and seconds) a statndard year has when some
instanciations of years leap.

RE: your remark about handling relative time greater than a year.  I can't
see why that would not work.  I would see more problems with when you reach
100, 1000 or 10000 days....

As for terminal servers being up for several years.  I'm sure we have some
customers who would like Digitial to think that their terminal servers have
been up since Edison invented the lightbulb...and we'd better make d*mn sure it
stays that way! :-)

-Dave