Thanks for the quick response -
I am seeing that the 255 character limit does impact the display of this
variable. At 255 at below, the status window updates. At 256 and above, no
update in the window while the probe continues to run. I verified the variable
size with a strlen() inside the command line probe.
In regards to making a returned variable appear as not graph able: I tried the
${eval} route, and all it displays now is 0. So I guess it wants to evaluate
that text as an expression of some kind.
On the ProbeXML thing - It should be covered. I've been string comparing the
entire field, so as long as the entire ProbeXML field matches, I'll assume that
IM has matched it on all maps.
Thanks for the help,
Tony
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of William W. Fisher
Sent: Wednesday, January 02, 2008 2:56 PM
To: InterMapper Discussion
Subject: Re: [IM-Talk] Couple of Questions - Redundant Polling and Command Line
Probes
Tony Mumm wrote:
> First thing, I'm creating a custom command line probe. Let me first say that
> this is an excellent tool that I seemingly can do anything with. It does
have
> some quirks that I think I need some clarification on.
>
> My goal is to get status on some processes I have running. I query my
> processes, and it returns the status through the standard stdout:
> \{ $blah1 := "Status message", $blah2 := "Status message2" }
>
> I see two interesting behaviors when I run this. First, it seems that there
is
> a limit on the size of the variable that can be set in the stdout response.
If
> it gets too large, the probe stops updating. I assume that there is a size
> limit to any probe variable.
There is a size limit of 65535 bytes. That is, there's a limit of 65535 bytes in
the cmd-line probe output for the block
between \{ and }, including the delimiters.
Is this the limit you are seeing? The other common limit would be 255 chars, but
I don't see a code path (in 4.6.5) that
limits to that length.
> Second thing is that the status window underlines the returned values from the
> command line probe. Similar to what you would see if something is a value
that
> could be graphed. In fact, when I click on it, it tries to create a graph.
> With a textual string response, obviously this doesn't work. Is there any way
> to instruct IM not to consider the returned variable as eligible for graphing?
You can use an eval macro:
${eval: $blah1}
> Lastly - I've put some effort into trying to take advantage of the redundant
> polling feature. According to the docs, the attributes to the device must
match
> for it to be considered the same. I wrote some perl to parse the output of
> remoteaccess scripting and compare the fields of every device. It seems that
as
> long as the hash variable of ProbeXML field matches, it is considered the same
> device. Can someone at Dartware confirm that?
That's partially true. Technically, the devices are the same if the ProbeXML
fields are equal -- byte for byte. If the
hash-values are equal, you still need to compare the rest of the bytes.
Regards,
Bill Fisher
Dartware, LLC
____________________________________________________________________
List archives:
http://www.mail-archive.com/intermapper-talk%40list.dartware.com/
To unsubscribe: send email to: [EMAIL PROTECTED]
____________________________________________________________________
List archives:
http://www.mail-archive.com/intermapper-talk%40list.dartware.com/
To unsubscribe: send email to: [EMAIL PROTECTED]
