Trace Window Showing

I am running a JAL script job in version 5.1.395 that I recently converted from version 3.4.33. The job uses the RunAndWait command as follows:

RunAndWait( "essmsh e:\\transfer\\balsheet\\scripts\\balsheet.mxl", "", 0 , processid )

In version 3.4, while this step was running, a window would show on the server showing the details of the underlying essmsh process running just like if I issued the same command at a DOS command prompt. In the new version of 24x7, when the RunAndWait command is issued I get an empty window that pops up with the title "24x7 Trace". I see no details of what is happening with the underlying script. I don't have trace enabled in 24x7 so not sure why this is happening. I prefer the way it was handled before, just wandering if there is a way to show the details of the underlying script while it is running in new version.

Thanks,
Jeff

Each job has its own console if trace is enabled. So, in order to see the trace, please enable the global trace option in Tools/Options menu, Log tab. You presently have it in a mixed state. All traces are now explicitly recorded and saved in log files if you don't disable capturing of job output option. That option is independent from the global trace option.

I enabled trace at the global options level and it behaved exactly the same, I am still only seeing a blank console window titled 24x7 Trace while the job runs.

What do you have in the registry for value in HKEY_LOCAL_MACHINE\SOFTWARE\SoftTree Technologies, Inc.\24x7 Scheduler\5.0\TraceEnabled?

Do you see the trace in job capture in the Output? (see links and content on the Output tab when job is selected in the GUI window)

The registry has a value of "Y" in the TraceEnabled key.

The detailed output from the MAXL script is not captured in the job capture output accessed on the Output tab of the GUI. It contains only 24x7 log output. However, the debug.log file in the 24x7 directory does contain the detailed MAXL script output I am looking for. I was just hoping I could get that to display in the console window while the job is running like it does in the old version, to allow me to monitor the job progress.

Thanks,
Jeff

I've done some experimenting using latest version 5.1.399 and I'm unable to reproduce your results. I don't get trace in separate qwindows for each jobs, but I do get job output from JAL jobs always captured, unless I specifically disable it, and it is available on the Output tab. I suggest that you try upgrading your instance to the latest version. The download link for your platform is available here http://www.softtreetech.com/24x7/index.htm

I installed version 5.1.399 and still experience the same thing. Below are screenshots showing what I see on version 3.4.33 versus 5.1.399, hopefully this helps clarify the issue:

I am hoping there is a way to "see" what is happening on the console while the script is calling the external application as it behaved in the older version.
Thanks,
Jeff

I continued to test different jobs and one that normally runs 5 minutes would just hang during the RunAndWait step and not complete for over an hour, I finally had to kill it. In troubleshooting this issue, I decided to turn off the option to "capture and archive job output". That instantly fixed my problem and the job ran in the normal 5 minutes. In addition it solved my other problem as the 24x7 Trace window went away and behavior reverted back to the way it did in the old version. I can now see the details of the "RunAndWait" process running in the console.

This resolves my issue as I am happy to disable the capture and archive job output to get things to work correctly, however it appears there is a problem with enabling that option on some types of jobs.

Do the processes that you run from the jobs read or write from the console. The "capture output" feature does redirect process stdout and stderr so that it can be consumed by the scheduler/job process and then saved to a cataloged output file. I wander if there is something special these jobs do that causes some sort of a abnormal behavior.

I am not aware of it, but possibly that is the problem. There is a command within these processes to "spool" stdout and stderr to a log file, so I am capturing the output successfully without the 24x7 "capture output" feature. I think the current solution is adequate for me and allows me to monitor the progress of the jobs as they run on the console.
Thanks

Well... there could be a conflict if 2 processes attempt to redirect the same stdout and sterr. That likely explain the root cause of the issue.