Copying a test should also. . .

[greyhat64]

Seldom does a copied test stand as is. At least one parameter needs editting, whether it is the host/target, action profile, or even the monitoring agent. In that regard copying a test should also. . .

1. Automatically bring the copied test into 'Edit' mode in order for the appropriate changes to be made.
2. Suspend/Disable a test while it is being editted. An annoyance I've notice any time I'm editting a test which I know could be resolved manually, but it seems like such a natural thing to happen 'organically' as part of the edit process.
3. A not nearly as elegant, but functional change - Include a 'disable test' checkbox in the dialog box used to select the destination folder. I can then go back and edit tests at my convenience.

BTW - Thanks for 7.46 and all it has to offer! It's empowering to see a some of my 'Wish list' items included in the list of new features!

[KS-Soft]

Automatically bring the copied test into 'Edit' mode in order for the appropriate changes to be made.

Yes, we plan such option, at least for single item copying.

Suspend/Disable a test while it is being editted. An annoyance I've notice any time I'm editting a test which I know could be resolved manually, but it seems like such a natural thing to happen 'organically' as part of the edit process.

You mean do not perform test while somebody opens this item in Test Properties dialog? H'm, not sure. May be somebody just wants to check settings especially when there are many operators have access from remote RCC consoles...

A not nearly as elegant, but functional change - Include a 'disable test' checkbox in the dialog box used to select the destination folder. I can then go back and edit tests at my convenience.

May be we can do that.. low priority task

BTW - Thanks for 7.46 and all it has to offer! It's empowering to see a some of my 'Wish list' items included in the list of new features

You are welcome

Regards
Alex

[greyhat64]

Automatically bring the copied test into 'Edit' mode in order for the appropriate changes to be made.

Yes, we plan such option, at least for single item copying.

Awesome! How soon?

Suspend/Disable a test while it is being editted. An annoyance I've notice any time I'm editting a test which I know could be resolved manually, but it seems like such a natural thing to happen 'organically' as part of the edit process.

You mean do not perform test while somebody opens this item in Test Properties dialog? H'm, not sure. May be somebody just wants to check settings especially when there are many operators have access from remote RCC consoles...

I see your point, but it raises other questions, especially with regard to multiple user access. Is the HML file a custom database file format?
If not, (and I know this a stretch) wouldn't it be easier if the tests were stored as database records? There are huge advantages, such as

• Disabling the test as soon as any, but only if, a field property is being modified.
• Changes are saved without me needing to remember to click \File\Save.
• Record locking to prevent multiple RCC's from editting at the same time.
• On a different note, HML Manager and Replicator functionality could then be embedded as a natural function of the main console.
  For instance, group selection of tests for replication could be executed from the HM/RCC interface, prompting for the necessary field changes (mentioned earlier).
  In the background a SQL query copies the selected records, saving the necessary changes on the fly.
  Changes could even be saved as reversable transactions.

Note: I love all the functionality your tools give, but I fail to understand why many of them aren't integrated into the AHM console, even if it's just a call from the 'Tools' menu.
Harder to do, I'm sure, from the RCC interface.

A not nearly as elegant, but functional change - Include a 'disable test' checkbox in the dialog box used to select the destination folder. I can then go back and edit tests at my convenience.

May be we can do that.. low priority task

Not necessary if you implement the first two suggestions.

[KS-Soft]

Awesome! How soon?

May be in next version but I cannot guarantee.

I see your point, but it raises other questions, especially with regard to multiple user access. Is the HML file a custom database file format?

Yes, its custom format file.

If not, (and I know this a stretch) wouldn't it be easier if the tests were stored as database records? There are huge advantages, such as

Yes, standard SQL database will allow us to implement new functionality much more faster and easier. However there is one disadvantage - we will depend on 3rd party bugs. I hate bugs in our software but we can find it and fix it. While bugs in 3rd party software (like Windows API or ODBC drivers) make me just crazy because we cannot do much in such case So, some bug in SQL client software can make HostMonitor completely useless.

huge advantages, such as
Disabling the test as soon as any, but only if, a field property is being modified

This can be done without SQL. I just not sure this is high priority option.

Changes are saved without me needing to remember to click \File\Save

Has nothing to do with SQL again. Simply click Options -> Preferences and select "Autosave testlist after any changes"

Record locking to prevent multiple RCC's from editting at the same time

You underestimate me HostMonitor+RCCs will not allow you to edit the same test/profile from several consoles at the same time.

For instance, group selection of tests for replication could be executed from the HM/RCC interface, prompting for the necessary field changes (mentioned earlier).

If we implement network discovery tool, probably it will work in such way

Note: I love all the functionality your tools give, but I fail to understand why many of them aren't integrated into the AHM console, even if it's just a call from the 'Tools' menu

Why not? Why we need to put everything in single module? Log Analyzer can be installed on another system, it can be installed on several systems and you don't need to pay for several Enterprise licenses (just 1 Enterprise + N Log Analyzer). The same about Web Service, Telnet Service... E.g. you may install HostMonitor behind firewall and install Web Service outside...

Regards
Alex

[greyhat64]

First of all, I wish to address a mistaken impression - I have never underestimated you.

I share your distaste for third party dependencies and the bugs that come with them. Having said that,

1. I only mentioned SQL as a query language, not as a product (i.e. MS-SQL). You can utilize DBF (which you already support for log files) or write your own database engine if you prefer.
2. Besides, you've already yoked yourself to that horse by supporting ODBC log files. Including the storage of configuration or test records exposes you no further.
3. Combine that with your admission that doing so will allow you to "implement new functionality much more faster and easier" now tips the scales toward a db implementation (DBF, ODBC, or direct SQL), doesn't it?

huge advantages, such as
Disabling the test as soon as any, but only if, a field property is being modified

The reason I mention it is this: If I'm editting a test it's because the current parameters are inaccurate/incomplete. I want the statistics and, more importantly, the actions for that test to be suspended until I've made my corrections. Inaccurate/incomplete data is sometimes worse than no data at all, especially if the alarm is going to my manager.
To that end, making it happen seemlessly as I edit the test record is the simplest approach from an enduser standpoint.

Note: Autosave - Man, I remember seeing that, I just forgot.

Note: I love all the functionality your tools give, but I fail to understand why many of them aren't integrated into the AHM console, even if it's just a call from the 'Tools' menu

Why not? Why we need to put everything in single module?...

You can keep them as discrete, stand-alone components, but for simple ease of use why aren't they callable from your \Tools\ menu? It would save me a couple of clicks every time I need one of them (vs \Start\Program Files\HostMonitor7\{EXEName}.
Of course I could further crowd the 'QuickStart' part of my Startbar, but it doesn't seem like too much to ask to have it callable from the console. Doing so in RCC, on the other hand, would seem to be a much more difficult proposition. RCC would have to inventory locally installed components somehow - not impossible, just different.

[KS-Soft]

I only mentioned SQL as a query language, not as a product (i.e. MS-SQL). You can utilize DBF (which you already support for log files) or write your own database engine if you prefer.

I do not think DBF is better then HML. If you mean DBF+ODBC+SQL for easy data manipulation then we return to problem with 3rd party bugs. Microsoft ODBC driver for DBF has some bugs (as far as I remember it causes resource leakage)

or write your own database engine if you prefer

Well, that's good idea but... would you like to wait couple years for next release of HostMonitor?
We are using some "database elements" but to implement really good, complette, fast and bugs free database engine would take several years.
If we succeed, may be we stop selling network monitoring software and start selling databases?

Besides, you've already yoked yourself to that horse by supporting ODBC log files. Including the storage of configuration or test records exposes you no further.

When customer has some strange problems with HostMonitor, we always asks about ODBC logging and tests. Customer may disable ODBC logging for testing, confirm that problem gone and then change ODBC driver or database.
If HostMonitor will use standard database, what we can tell customer when nothing works? Please remove our software and try something else?

The reason I mention it is this: If I'm editting a test it's because the current parameters are inaccurate/incomplete. I want the statistics and, more importantly, the actions for that test to be suspended until I've made my corrections. Inaccurate/incomplete data is sometimes worse than no data at all, especially if the alarm is going to my manager.

Yes, I understand this however I think its not a big problem in real world or rather it will not help you in real world.
E.g. you have moved your server to new location, servers IP address has been changed. If you keep in mind HostMonitor, you will disable or pause test while you are moving/reconfiguring/repairing your server. If you forgot to do this, test will fail and your statistics will not be so good anyway. While you need 1 minute to modify test settings so it will not make your statistics any worse.

You can keep them as discrete, stand-alone components, but for simple ease of use why aren't they callable from your \Tools\ menu? It would save me a couple of clicks every time I need one of them (vs \Start\Program Files\HostMonitor7\{EXEName}.

WMI Explorer and MIB Browser can be launched directly from Test Properties dialog when you setup WMI or SNMP tests.
Process Meter can be started directly from Test Properties dialog when you setup Dominant Process test.
Log Analyzer can be launched from popup menu ("Statistics" item), also you may use menu View -> Log Analyzer.
What else? RMA Manager? Well, HostMonitor does not provide built-in link to RMA Manager. However it you want to save 1 or 2 mouse clicks, you may customize popup many and add any items
http://www.ks-soft.net/hostmon.eng/mfra ... m#custmenu

Regards
Alex

[KS-Soft]

Automatically bring the copied test into 'Edit' mode in order for the appropriate changes to be made.
A not nearly as elegant, but functional change - Include a 'disable test' checkbox in the dialog box used to select the destination folder. I can then go back and edit tests at my convenience.

Both options implemented in version 7.47 (unofficial update), available at www.ks-soft.net/download/hm747d.zip
Please install version 6.46 before using this update

Regards
Alex

[greyhat64]

Automatically bring the copied test into 'Edit' mode in order for the appropriate changes to be made.
A not nearly as elegant, but functional change - Include a 'disable test' checkbox in the dialog box used to select the destination folder. I can then go back and edit tests at my convenience.

Both options implemented in version 7.47 (unofficial update), available at www.ks-soft.net/download/hm747d.zip
Please install version 6.46 before using this update

??? I assume you mean 7.46. Anyway - THAT"S AWESOME!!!

Now I just have to convince you that pausing a test during editting is at least a worthy of the Options/Behavior tab.
Honestly, this is my last time to argue this one.
Real life scenario:
This all began with a shell script test running via RMA. I had run this type of test before so, being a bit cavalier, I set up a series of actions (email, restart service, restart server if that fails), saved, and pressed on to other things. My mistake - a resolvable error (parameter in my script ) sent the server into a jag of restarts, and my manager in a panic.
Can you see why I simply want all actions to cease if I initiate an edit of a test?
Of course you can blame me and say that I should've been more careful (that's a given), or tell me to pause first, then edit.
But especially in a panic situation when time and patience are both in short supply, it seems like a natural extension of the editting process.

[KS-Soft]

Sorry, I cannot assign high priority to this task.
Also I see possible problem: somebody can open Test Properties dialog just to view test settings then he can forget about test because phone rings, boss makes meeting or just because there is lunch time So, test on screen = test disabled.
Probably we can add view and edit modes, add some timer and popup reminders...

Low priority task. If more people will vote for this, I can increase priority to medium

Regards
Alex

[greyhat64]

And since you mentioned it. . .
We got way off point in the database discussion - 'nuff said. That is until you brought up,

When customer has some strange problems with HostMonitor, we always asks about ODBC logging and tests. Customer may disable ODBC logging for testing, confirm that problem gone and then change ODBC driver or database.

Since you brought it up I'm going to re-emphasize the need to consolidate log file entries.

It's visionary and commendable that you have included the option for a backup log file, but, as I've stated before, a backup log file needs to be treated like a transaction log. Not only does this prevent data fragmentation, it is particularly important in order to maintain a sense of data integrity and accessibility.

• Imagine, after multiple ODBC failures how many 'fragments' you could end up with. In that regard:
• Log consolidation should be available for DBF and Database (ODBC) logging. I don't see text or HTML formats working well in this regard.
• Posting these backup 'transactions' to text or DBF format should be a requirement. No sense in complicating it by needing to strip HTML code - ugh!
• You could have this happen transparently or, since you already have a (bad status) "execute alert profile when log inaccessible" option, you could employ a corresponding (good status) entry to:
  1. Test the consistent availability of the 'main' log file (i.e. after 3 successful attempts to contact)
  2. Post these 'offline' transactions, then
  3. Revert back to using the primary log file

I've examined both your text (Tab delimeted) and HTML formats, finding one significant difference with an additional field in the text file - appears to be a test record number. It should be easy enough to post those entries to an ODBC datasource.
Of course if you feel a need to modify your text file format in order to accommodate this, you have my permission.
Logically you want it to mirror the data record format of the db entries, but as long as the data is posted and I can analyze/report the results, I don't care what the text file format looks like. What I do care about is having the data all in one spot.

Sidenote: I can see XML, but does anyone really use the HTML format for logging? A fine report format, which you already support, but direct logging to HTML - strange.

(XML - I smell another upgrade opportunity! )

[KS-Soft]

It's visionary and commendable that you have included the option for a backup log file, but, as I've stated before, a backup log file needs to be treated like a transaction log. Not only does this prevent data fragmentation, it is particularly important in order to maintain a sense of data integrity and accessibility
...

Yes, we plan such (and other) improvements for ODBC logging. I do not think we will implement such algorithms for text or HTML logs.
BTW: Log Analyzer is able to analyze several log files and create consolidated reports.

I've examined both your text (Tab delimeted) and HTML formats, finding one significant difference with an additional field in the text file - appears to be a test record number.

TestID? HostMonitor records TestID into HTML log file as well, however its not visible when you check log using web browser.

It should be easy enough to post those entries to an ODBC datasource

You can and you should store TestID in ODBC log using %TestID% macro variable.

Regards
Alex

[greyhat64]

If more people will vote for this, I can increase priority to medium

I promised I wouldn't say anything more, but how do I start a petition?
That's why I made the roadmap suggestion a long time ago, an interactive list of potential upgrades that everyone can vote on.
You do a great job of responding, and you would still have the ultimate say-so, but it would be fun to see if anyone, especially the new forum users, would chime in, feel more involved, and participate more to help contribute to AHM's future. A Who's Hot or Not for future enhancements.

BTW: Log Analyzer is able to analyze several log files and create consolidated reports.

Yeah, I mentioned that earlier myself. But I would reserve that for reporting across AHM servers and their potentially separate log files, not to act as a surrogate for real data consolidation.
SideNote: I stumbled on the reference to %HM_FILEGUID%. A great way to record multiple AHM's data to one datasource. Good Thinking! But it does presume that Log Analyzer is able to parse using that field - Personally I would make it a required field for all logging.
As for the TestID, I just missed it in the forest of HTML tags. Everything else is good there.

Yes, we plan such (and other) improvements for ODBC logging. I do not think we will implement such algorithms for text or HTML logs.

I hope in the latter statement you are saying you won't post updates to text or HTML logs - understood. I still wouldn't mind using text for the backup (transaction) log file format. It's easy enough to write a query script that will import a text or DBF file to an ODBC datasource.

Speaking of Log Analyzer, I've not spent nearly enough time with it yet, but, for instance, %Recurrances% does not show up in Log Analyzer's ODBC logs Manager configuration. Maybe it doesn't need to be there, but if not, why are we instructed to record it? This implies a descrepency in formats, format requirements, or intent.

Which raises the questions:

• Do you plan to establish a hard and fast logging format? I hope so. Fields could be appended manually to the end of the 'standard' field list as necessary per user requirements, but the base requirements should be 'untouchable'.
• Have you be considered having AHM create the initial table to the defined ODBC source? It would reduce the opportunity for user error.

Thanks again!

[KS-Soft]

That's why I made the roadmap suggestion a long time ago, an interactive list of potential upgrades that everyone can vote on.

I believe we ca spend significant amount of time on this task with near 0 effect. Less than 1% of customer will use such application in "write" mode. Last time we discussed this idea I provided "posts per user" statistics. Here is another example: version 7.42 Beta (with some bugs) was downloaded over 10,000 times. Within a months we have received 0 bug reports.

SideNote: I stumbled on the reference to %HM_FILEGUID%. A great way to record multiple AHM's data to one datasource. Good Thinking! But it does presume that Log Analyzer is able to parse using that field - Personally I would make it a required field for all logging.

This variable was implemented for 1 particular customer. We do not think Log Analyzer really needs to consolidate logs from various HostMonitors. We think single HostMonitor can perform consolidated monitoring using RMA.

Speaking of Log Analyzer, I've not spent nearly enough time with it yet, but, for instance, %Recurrances% does not show up in Log Analyzer's ODBC logs Manager configuration

I do not see why Log Analyzer needs this field.

Maybe it doesn't need to be there, but if not, why are we instructed to record it?

Where do you see such instruction? In example of SQL Query? Its just example. You may use any fields and variables but nobody requires %Recurrances% variable.
There is list of obligatory fields
http://www.ks-soft.net/hostmon.eng/mfra ... tm#odbclog

Do you plan to establish a hard and fast logging format? I hope so. Fields could be appended manually to the end of the 'standard' field list as necessary per user requirements, but the base requirements should be 'untouchable'.

Hard and fast? This is text format.
If you really need to add some fields, you may use "Execute external program" action and really simple script to create your own log.

Have you be considered having AHM create the initial table to the defined ODBC source? It would reduce the opportunity for user error.

Yes. We plan a lot of changes regarding ODBC logging
http://www.ks-soft.net/cgi-bin/phpBB/vi ... php?t=4698

Regards
Alex

[greyhat64]

SideNote: I stumbled on the reference to %HM_FILEGUID%. A great way to record multiple AHM's data to one datasource. Good Thinking! But it does presume that Log Analyzer is able to parse using that field - Personally I would make it a required field for all logging.

This variable was implemented for 1 particular customer. We do not think Log Analyzer really needs to consolidate logs from various HostMonitors. We think single HostMonitor can perform consolidated monitoring using RMA.

Of course HostMonitor can perform consolidated monitoring using RMA. The point is that doesn't fit everyone's working model of how it should be done. Which is probably why the 'one user' asked for such an ID.
And since you have if there, why not use it as part of the standard ODBC dataset? If there is a single AHM it won't make a difference, if there are multiple AHM's it will make a world of difference.
It's like your car having a 5th gear and never using it.

[KS-Soft]

Of course HostMonitor can perform consolidated monitoring using RMA. The point is that doesn't fit everyone's working model of how it should be done. Which is probably why the 'one user' asked for such an ID

Its impossible to create software that will completely fit everybody.

And since you have if there, why not use it as part of the standard ODBC dataset?

There is no standard ODBC dataset yet. I think HostMonitor version 8 will use standard database for logging

Regards
Alex