SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
Capturing Job Output

 
Reply to topic    SoftTree Technologies Forum Index » 24x7 Scheduler, Event Server, Automation Suite View previous topic
View next topic
Capturing Job Output
Author Message
Joseph Spivey



Joined: 25 Jul 2000
Posts: 8

Post Capturing Job Output Reply with quote

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

Wed Jul 26, 2000 3:17 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7841

Post Re: Capturing Job Output Reply with quote

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

Wed Jul 26, 2000 4:34 pm View user's profile Send private message
martin santos



Joined: 26 Jul 2000
Posts: 2

Post Re: Capturing Job Output Reply with quote

: 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'

Wed Jul 26, 2000 5:02 pm View user's profile Send private message
Joseph Spivey



Joined: 25 Jul 2000
Posts: 8

Post Re: Capturing Job Output Reply with quote

: 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.

Thu Jul 27, 2000 5:52 pm View user's profile Send private message
Joseph Spivey



Joined: 25 Jul 2000
Posts: 8

Post Re: Capturing Job Output Reply with quote

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.

Thu Jul 27, 2000 6:32 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7841

Post Re: Capturing Job Output Reply with quote

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.

Thu Jul 27, 2000 9:05 pm View user's profile Send private message
Joseph Spivey



Joined: 25 Jul 2000
Posts: 8

Post Re: Capturing Job Output Reply with quote

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

Fri Jul 28, 2000 12:48 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7841

Post Re: Capturing Job Output Reply with quote

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

Fri Jul 28, 2000 1:03 pm View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » 24x7 Scheduler, Event Server, Automation Suite All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.