I would like to be able to capture to a report file the output that is going to a command shell window when a job runs. I have scoured the help file but all I can find is how to redirect output from the RunAndWait type statements. This is my second day with 24x7 so maybe I'm overlooking the obvious.

TIA, Joseph Spivey

Check out .LOG files in the 24x7 directory. Different information forwarded to different files. Still most of this information can be seen in the Log Viewer.

: I would like to be able to capture to a report file the output that is going
: to a command shell window when a job runs. I have scoured the help file
: but all I can find is how to redirect output from the RunAndWait type
: statements. This is my second day with 24x7 so maybe I'm overlooking the
: obvious.

: TIA, Joseph Spivey

: Check out .LOG files in the 24x7 directory. Different information forwarded
: to different files. Still most of this information can be seen in the Log
: Viewer.

try 'mybatchfile.bat > mybatchfilelog.txt'

: Check out .LOG files in the 24x7 directory. Different information forwarded
: to different files. Still most of this information can be seen in the Log
: Viewer.

With all trace options set I did find this log file. Because it is mixed with all outputs from other jobs, it usefulness for our application is limited. With this in mind I went ahead and tried o simply redirect output from the various "RunAndWait" calls that we issue,
for example, RunAndWait "test.bat > test.rpt"

I spent ages stepping through the debugger trying to get this to work. I confirmed syntax via a CMD shell session, but no matter what I did, the output went to the 24x7 cmd shell window, not the file I was trying to redirect to. After much frustration I ran it without the debugger, and it worked. Conclusion, 24x7 JAL is (in this instance) working differently in debug mode than regular mode. If this is correct, then no doubt you'll understand how my faith in the debugger is reduced.

I was still having problems redirecting output from MS SQL V7.0 "ISQL.EXE" so I went back to my simple "test.bat" case to work forward from there. To my astonishment, this now *does* work through the debugger. I double checked this very carefully before posting on a public forum and got repeatable results, but not any more. I am still unable to redirect from ISQL though (triple checked it this time). The following command runs as expected from cmd shell, but not through RunAndWait...

c:/mssql7/binn/isql.exe -Ssrv -Usa -Ppwd -Q"EXEC sp_who" > sp_who.rpt

If I take off the redirection, it works!

We have verified all the stuff we thought would be difficult with 24x7, but this simple matter of redirection of output to a file of our choice is proving most frustrating.

Thanks for your help

: With all trace options set I did find this log file. Because it is mixed with
: all outputs from other jobs, it usefulness for our application is limited.
: With this in mind I went ahead and tried o simply redirect output from the
: various "RunAndWait" calls that we issue,
: for example, RunAndWait "test.bat > test.rpt"

: I spent ages stepping through the debugger trying to get this to work. I
: confirmed syntax via a CMD shell session, but no matter what I did, the
: output went to the 24x7 cmd shell window, not the file I was trying to
: redirect to. After much frustration I ran it without the debugger, and it
: worked. Conclusion, 24x7 JAL is (in this instance) working differently in
: debug mode than regular mode. If this is correct, then no doubt you'll
: understand how my faith in the debugger is reduced.

Can you post your script here?

By the way, the redirection has nothing to do with the debugger. The command is sent to the Operation system as it is specified in the script. However, the way you enter the command in the script does matter. Also note that if you don't specify full file name, the output file is created in the current directory which may differ between job runs. It's a good idea to do it like RunAndWait "test.bat > c:\\logs\\test.rpt", "", 0, proc_id

: With all trace options set I did find this log file. Because it is mixed with
: all outputs from other jobs, it usefulness for our application is limited.
: With this in mind I went ahead and tried o simply redirect output from the
: various "RunAndWait" calls that we issue,
: for example, RunAndWait "test.bat > test.rpt"

: I spent ages stepping through the debugger trying to get this to work. I
: confirmed syntax via a CMD shell session, but no matter what I did, the
: output went to the 24x7 cmd shell window, not the file I was trying to
: redirect to. After much frustration I ran it without the debugger, and it
: worked. Conclusion, 24x7 JAL is (in this instance) working differently in
: debug mode than regular mode. If this is correct, then no doubt you'll
: understand how my faith in the debugger is reduced.

Hi, I really appreciate your help. In a follow up post yesterday you'll see that although I observed this behaviour several times, I can no longer reproduce it. However, I'm still having a problem with the number one program we need to call from 24x7, Microsoft's Query Analyser image ISQL.EXE. From MSDOS I can call ISQL.EXE with or witout output redirection, it works OK. From 24x7, I only have success when I do not redirect output. Something is making ISQL.EXE regard the redirection as additional (and invalid) IASL call arguments. This may explain it better...

// Works OK.
RunAndWait "c:/mssql7/binn/isql.exe -Ssrv -Usa -Ppwd -Q\"EXEC sp_who\"", "c:/24x7_test", 0, process

// Fails with "isql: unknown option >"
RunAndWait "c:/mssql7/binn/isql.exe -Ssrv -Usa -Ppwd -Q\"EXEC sp_who\" > sp_who.rpt", "c:/24x7_test", 0, process

In both instances the same command works directly from MSDOS. Perhaps someone with more 24x7 experience would know if additional punctuation is required to prevent ISQL.EXE from trying to interpret the redirection as it's own call arguments?

Hope someone can help.

Joseph Spivey

: Can you post your script here?

: By the way, the redirection has nothing to do with the debugger. The command
: is sent to the Operation system as it is specified in the script. However,
: the way you enter the command in the script does matter. Also note that if
: you don't specify full file name, the output file is created in the
: current directory which may differ between job runs. It's a good idea to
: do it like RunAndWait "test.bat > c:\\logs\\test.rpt",
: "", 0, proc_id

Run it as
RunAndWait "cmd /c c:\\mssql7\\binn\\isql.exe -Ssrv -Usa -Ppwd -Q\"EXEC
: sp_who\" > sp_who.rpt", "c:\\24x7_test", 0, process

This should work.

By the way have you tryied doing the same job without isql involved?
You can probably do the same thing by making
a "database" type job or
a "JAL script" type job using DatabaseConnect, DatabaseExecute, DatabaseDisconnect

In the last two cases you will have much more flexibility and options for error handling

: Hi, I really appreciate your help. In a follow up post yesterday you'll see
: that although I observed this behaviour several times, I can no longer
: reproduce it. However, I'm still having a problem with the number one
: program we need to call from 24x7, Microsoft's Query Analyser image
: ISQL.EXE. From MSDOS I can call ISQL.EXE with or witout output
: redirection, it works OK. From 24x7, I only have success when I do not
: redirect output. Something is making ISQL.EXE regard the redirection as
: additional (and invalid) IASL call arguments. This may explain it
: better...

: // Works OK.
: RunAndWait "c:/mssql7/binn/isql.exe -Ssrv -Usa -Ppwd -Q\"EXEC
: sp_who\"", "c:/24x7_test", 0, process

: // Fails with "isql: unknown option >"
: RunAndWait "c:/mssql7/binn/isql.exe -Ssrv -Usa -Ppwd -Q\"EXEC
: sp_who\" > sp_who.rpt", "c:/24x7_test", 0, process

: In both instances the same command works directly from MSDOS. Perhaps someone
: with more 24x7 experience would know if additional punctuation is required
: to prevent ISQL.EXE from trying to interpret the redirection as it's own
: call arguments?

: Hope someone can help.

: Joseph Spivey