Is it possible to delete a scheduled report in ReportCaster after it is in the running state?

Not from Report Caster console. However with careful comparison between the EDATEMP sub folders and the Agent number within the Reporting Server Console you could identify which agent to kill within the RS console.

The only thing I suggest is take sure you get the right one!

T

One good way to help identify which report is running is by setting up a set of agents specifically for ReportCaster. In addition, have a global include in your reports to log to file the report name, uid, and agent number. You can grep the file for the agents that are running to see what the last fex was that it (the agent) ran/is running. Again more granularity of which one it is that you might want to kill.

And if you still have additional information needed then do like Tony says and get more information with the edatemp. If there is still more then one in question... Pray!!!

After we opened case #52872540, Need to Cancel a ReportCaster Job That is Running, we found out that this is already a new feature request. Because we need to be able to kill run away reports, we need this functionality. We can have hundreds of reports running at the same time so we have no way to identify the report we need to cancel.

Michael, how do you set up an agent specifically for Caster?
(You're at Gallo? Tasty job!)

I was wondering the same. I know how to create a new Service - maybe called RC_DEFAULT - but there isn't a way in RC to specify which service should be used. You only specify servername:port number. You could create another instance of a server listening on a different port, but other than that I don't know how you would tell RC to use a specific agent/service.

This message has been edited. Last edited by: Darin Lee,

You can add a service from the web console Data Services tab and customize its agents. You would probably have to also set up a 'remote server' in the WebFOCUS client console to point to that service. Then add the new 'server' to the RC configuration. That might work.

I didn't know you could create a remote server for a specific service. A remote server is also just referenced by servername:port number.

I have 3 client node profiles pointing to the same port, each with a little different twist on security, one with a default id, one that forces a credentials prompt, and another with a fancy exit. The developers have to use the IBIC_server variable to be sure that they point to the correct node.

In the case for this post, however, I think you also need the new service in the server, same port, but with its own agents. This might work for Laurie.

We don’t understand what you are saying other than the part about seting up separate agents that ReportCaster would use.

Chuck Wolf had suggested creating a group of agents that only ReportCaster would use so we could separate them from agents used by the dashboard (Direct Query). However, that still would not identify what agent belongs to a specific ReportCater job, only that if you kill an agent you would know that is was for a ReportCaster job and not for a dashboard process.

This was from Chuck Wolf
To narrow down the agents tied specifically to ReportCaster you could set up a Data Service in your WebFOCUS Reporting Server with its own set of agents and then change the ReportCaster connection to explicitly configure to use that Data Service. At least that way you can know that any agent you kill will be a ReportCaster agent. If you know what time the schedule started you can see when the agent started and make an educated guess. I have never been asked this one before so this is my best guess.

As I stated previously, I think our requirements would be fulfilled with the new feature request but we are not sure when that will be available.

If you have access , even read only, to your server, you can look at the files within an agent directory.
We use an includable module in EVERY fex that dumps a .txt file into its running agent, that file is named the same as the fexname, and we -WRITE to that file the name of the author which we set in the fex
-SET &author='first.last@yourplace.com';
We can -WRITE to that little file at various interesting points in the fex, with bits of interesting information.
This is expecially useful in a crash.
We can just copyu the whole agent directory to a common disk area, and let the developer explore it.

Re: Chuck Wolf. What I said.

Susannah's idea is a good one. Another may be to use application ids or different ids as execution ids. Those ids show on the console.

Using the WebFOCUS Reporting Server Console you can define a new SERVICE named, for example, RCASTER. This service will have its own number of maximum and ready agents. In the ReportCaster Configuration Tool on the Data Server tab you can then specify this SERVICE in the URL that defines the Reporting Server, for example, jdbc:eda:\\localhost:8120;server=;CLASS=CLIENT(RCASTER)

ReportCaster jobs will run under this SERVICE when sent to the Reporting Server.

That answers my question. Thanks Gerry. I didn't know that you could use CLASS=CLIENT(servicename) to specify a particular group of agents. I'll definitely give that a try for my ReportCaster stuff.

Gerry, how could we do something similar for Deferred REports?

Susannah, Deferred reports already has its own set of agents. they are serviced by the DFM_DEFAULT service / agents

seems so, but seems that those agent numbers can be anything.

They can be anything, but they are controlled by a completely separate service from the other requests. When you start up the server you'll notice that the agents for the DEFAULT service get tscomid 1&2, the WC_DEFAULT agents get 3&4, and the DFM_DEFAULT agents get 5&6. They all end up in edatemp but are controlled by different services so the numbers assignment/sequence are meaningless except for ID purposes.