Hi,

We get crashed agents sometimes and I'm a bit confused as to how I should process theses crashes.

I know it maybe a report or an ETL that crashed. But I don't know what the agent was doing at the time it crashed.

edaprint does not say much about that.

If anybody knows how to tweak edaprint or to find out what happenned with a crashed agent, let me know! I'm a bit desperate right now...

Thanks

There are a number of ways to diagnose but I'll give you a couple of easy ones once you determine which program it is. But first, and I hope these are browser-based, you can compare the datetime stamps in your web server log to the start time of the agent that crashed. You should see the page or program.

Once you find the program, run it by hand to make sure that it still fails. If it does, open it in the editor and put a -EXIT in turn after each section to determine what is failing. You can then put a readlimit in that section until it stops crashing the agent so that you can do a view source to see what the error actually is.

But I see you are using Data Migrator. Can you turn a trace on to find the problem program?

hmmm... you won't like this one...

I can't repeat the error!

I don't know what was running at that time.

It could be a report... It could be an ETL...

As for turning the traces on, it could go on for days before I get the error again. So traces is not an option as long as we can't repeat the error.

This message has been edited. Last edited by: Pascal Bellerose,

If you look at the server console page and see crashed agents, then there is also a Tscomid. That id is the number of the agent that took the request.
If you look in the directory where the server runs (typically c:\ibi\srv76\wfs), you will see a directory with the name edatemp. In that directory there are the subdirectories of the agents. The directory you're looking for should have a name like ts00000x where the 0000x is the tscomid. It may be that the agent left some files in that directory before crashing. If so, it may help you find out what request was running. If there is nothing in that directory then you're out of luck ...

There were two Summit labs on this topic. The labs can be downloaded from the Summit 2009 Wrap Up page. Here are the direct URLs for the labs:

Beginner Debugging:
http://www.informationbuilders...60510962339529038721

Advanced Debugging:
http://www.informationbuilders...53036202381695395881

Thanks very much Southern Belle for these links!

Pascal
we do something a bit different
We have a module in our baseapp called
mod_agentdoc.fex
..
-SET &filedoc = &FOCFEXNAME||'.txt';
FILEDEF MYAGENT DISK &filedoc (APPEND
-RUN
-WRITE MYAGENT &FOCFEXNAME &DATE &TOD
...
Our users include this module at the top of every fex
-MRNOEDIT BEGIN
-INCLUDE baseapp/mod_agentdoc.fex
-MRNOEDIT END
...
Users are then encouraged to continue write to this file at various points throughtout their process.
-WRITE MYAGENT &author &whatever
...
-WRITE MYAGENT after first extract lines= &LINES
-WRITE MYAGENT after next define focerrnum=&FOCERRNUM
..whatever they can think up or want to do.
When an agent crashes, this little text file can be opened up by the admin (who has server access) and examined.
The entire agent can be copied to a work director off the server, and the developer can then examine its contents at leisure, While the admin can go ahead and kill the agent.