Do you have an estimate of when version 4 will be out?

Also, where can I find the bug fixes/enhancements that were made in version 3.4.25e?

Thank you.

I don't have a specific date for version 4. Originally it was planned for 2nd qtr of 2005 but we are experiencing some delays mostly caused by other vendors. There are no much changes in version 3.4.25e as compared to 2.4.25a, b, c, and d, that's why they were not announced separately as significant releases. We continue making small incremental improvements to support better integration with other "24x7" products and expand multi-platform and various international settings supports. For instance all versions 3.4.25a to 3.4.25e include updated versions of Java API supporting recently added features in 24x7 Scheduler Java Edition; also some fixes for problems in the graphical interface related to handling of New Zealand time formats "a.m./p.m." and so on.

: Do you have an estimate of when version 4 will be out?

: Also, where can I find the bug fixes/enhancements that were made in version
: 3.4.25e?

: Thank you.

Thank you for the response. Another question.

Back in January, I submitted a "new enhancement request" to place line numbers into the editor along with an option to turn this feature off. I also suggested adjusting the line numbers to account for scripts that were inserted using the @SCRIPT command. Can you tell me how that request is going?

Thank you again.

: I don't have a specific date for version 4. Originally it was planned for 2nd
: qtr of 2005 but we are experiencing some delays mostly caused by other
: vendors. There are no much changes in version 3.4.25e as compared to
: 2.4.25a, b, c, and d, that's why they were not announced separately as
: significant releases. We continue making small incremental improvements to
: support better integration with other "24x7" products and expand
: multi-platform and various international settings supports. For instance
: all versions 3.4.25a to 3.4.25e include updated versions of Java API
: supporting recently added features in 24x7 Scheduler Java Edition; also
: some fixes for problems in the graphical interface related to handling of
: New Zealand time formats "a.m./p.m." and so on.

I am sorry I don't know answers for these questions. In any case I don't think the editor will not account for line numbers in off-line scripts. This is simply impractical and unrealizable, not to mention the tremendous performance impact it would on the editor operations if the editor has to reload and refresh referenced files after each scroll or change in the in-line script.

: Thank you for the response. Another question.

: Back in January, I submitted a "new enhancement request" to place
: line numbers into the editor along with an option to turn this feature
: off. I also suggested adjusting the line numbers to account for scripts
: that were inserted using the @SCRIPT command. Can you tell me how that
: request is going?

: Thank you again.

This must be possible, because 24x7 does it already, it just doesn't display it in the editor.

Example:
You write a job with 50 lines of code and put an error into line 45. When you validate the job, a message comes back saying that there is an error on line 546. You look at your code and only see 50 lines. Then you realize that 500 lines are being inserted through an @SCRIPT command.

If the error is in the off-line script, the message should contain the line number inside the off-line script alone and indicate which off-line script the error was found in.

If the error is in the job itself, there should be some visual display of which line is in error without having to manually calculate how many lines are in the off-line scripts.

Does this sound like reasonable modifications that could be done to the editor?

: I am sorry I don't know answers for these questions. In any case I don't
: think the editor will not account for line numbers in off-line scripts.
: This is simply impractical and unrealizable, not to mention the tremendous
: performance impact it would on the editor operations if the editor has to
: reload and refresh referenced files after each scroll or change in the
: in-line script.

When the script is about to run all referenced files are loaded at once and only once. So the whole thing is in memory and line calculation is not a big deal.

When the script is edited, either on-line portion or off-line portion (files), at that time line numbers get changed frequently because of the changes (inside and outside). The editor must do a lot more work - monitor changes in externals file, invalidate changes in the on-line portion, basically it must recalculate line numbers all the time accordingly to all changes in all places. When the whole thing is loaded into memory this is not a problem, but anything that involves a file access surely creates certain performance impact. That's why I said that taking into account external files for line enumeration could be problematic from an editor-performance point of view. Again this is just my opinion.

Sorry if I wasn't clear in the first message.

: This must be possible, because 24x7 does it already, it just doesn't display
: it in the editor.

: Example: You write a job with 50 lines of code and put an error into line 45.
: When you validate the job, a message comes back saying that there is an
: error on line 546. You look at your code and only see 50 lines. Then you
: realize that 500 lines are being inserted through an @SCRIPT command.

: If the error is in the off-line script, the message should contain the line
: number inside the off-line script alone and indicate which off-line script
: the error was found in.

: If the error is in the job itself, there should be some visual display of
: which line is in error without having to manually calculate how many lines
: are in the off-line scripts.

: Does this sound like reasonable modifications that could be done to the
: editor?

I think I understand what you are saying. Displaying line numbers in the editor would be a performance issue. But what about changing the error message at validation time? Could the editor give back a better indication of where the error occured?

: When the script is about to run all referenced files are loaded at once and
: only once. So the whole thing is in memory and line calculation is not a
: big deal.

: When the script is edited, either on-line portion or off-line portion
: (files), at that time line numbers get changed frequently because of the
: changes (inside and outside). The editor must do a lot more work - monitor
: changes in externals file, invalidate changes in the on-line portion,
: basically it must recalculate line numbers all the time accordingly to all
: changes in all places. When the whole thing is loaded into memory this is
: not a problem, but anything that involves a file access surely creates
: certain performance impact. That's why I said that taking into account
: external files for line enumeration could be problematic from an
: editor-performance point of view. Again this is just my opinion.

: Sorry if I wasn't clear in the first message.

I agree with you. The validation should report correct line number or at least say "line XXX in file ZZZ"

: I think I understand what you are saying. Displaying line numbers in the
: editor would be a performance issue. But what about changing the error
: message at validation time? Could the editor give back a better indication
: of where the error occured?