Kill PID in Open Edge, but SYS Monitor still shows "cancelling"

Epicor ERP 9
1

Hey everyone, new to the forum, I’ve been working on “re-implementing” many of the modules in our installation. We keep getting MRP or Scheduler processes stuck during the schedule night time runs. When a process hangs, we try to cancel from the sysmonitor, but just hangs in a “canceling” state. I use the referenced PID number and look for it on the openegde pool display and kill the process. It drops from the pool status, but continues to show up in sysmon and prevent a relaunch. Only way to recover is to restart the process, task, and main appserver, which dumps all the users. It’s of course not well received.

Anyone know how to kill the process and clear it from the sysmonitor?

2

just restart the processserver and taskagent, not the main one.

3

When i do that, i loose printing and report generation. And the sysmon still shows cancelling

4

which version of ERP 9.05 are you on?

5

restarting the taskagent and processserver should resolve it, but, if you have to restart the main appserver then I’d recommend creating a dedicated printing appserver so that when this happens, you can restart the taskagent, processserver, and printing appserver so it doesn’t knock users out of the system.

Here is how one can do so

Using the OpenEdge Explorer:
Creating a dedicated print AppServer-OET-E905.pdf (215.3 KB)

Using the Progress Explorer Tool:
Creating a dedicated print AppServer-PET-E905.pdf (179.1 KB)

1 Like
6

9.05.702a

this is where i’m gonna have to bring someone on board to split the print server, no idea how to direct it to a new one. i feel like in the past few weeks i’ve been going around in circles.

7

The two documents I just uploaded go over all of the particulars of creating the new appserver process and telling the Epicor ERP system to use it for printing.

I would recommend reviewing the steps first to see if you feel comfortable with the process conceptually first. If not, then reaching out to someone else might be appropriate. As far as E905 written procedures go, I’d put this one at a 3 out of 10 (though, I am biased as I did write the documents in question :/).

If making this issue go away now would bring you happiness, I can implement this for you (assuming you have a valid maintenance agreement with Epicor; I didn’t check) if you don’t feel comfortable with it tomorrow morning–it would only take ~10 minutes or so. Just let me know.

1 Like
8

Thanks a lot! I’ll review those documents, is it safe to assume that there isn’t a good way to make the cancel command in sysmonitor work correctly? and restarting process and task app servers is really the only answer?

9

When someone cancels a process from the ACTIVE tasks in the system monitor, what actually happens is that the system creates a record on a specific table; systaskkill to be exact.

Every process that runs through the system monitor is supposed to break from whatever work it’s doing every so often and check to see if there is a systaskkill record for it to cancel–if so, the process does whatever the developers want it to do to back out/stop.

Situation 1:
What happens when the process is terminated (the _proapsrv in E905) that was tied to that ACTIVE task while the process is in the system monitor? Literally nothing, so there isn’t a process there anymore to check to see if the systaskkill record is there. One needs to restart their appserver processes to address.

Situation 2:
What happens when the process is stuck in an endless loop due to a data related problem? e.g. a BOM where the parent part is also a child of itself (for example). Same actual outcome as the first situation–the program doesn’t break from it’s cycle to check to see if a cancel request was issued.

Situation 3:
What happens if a specific process doesn’t have the logic to check to see if there is a cancel request? Same as situation 1 and 2, and there are a few of them that behave this way in E9.05–I don’t recall what they are at the moment.

Situation 4:
What happens if you have a process that is executing happily, it breaks every so often to check for a cancel request, there is code for that process to actually cancel, and it actually sees a cancel request? Then, and only then, will canceling it from the system monitor work.

Situation 5:–inferred, easy to test for those that are curious
What happens if you are running a massive report that takes hours and hours to render on the SSRS side, and you submit a request to cancel it after the ERP part of the process but before SSRS completes? It will probably cancel from the system monitor, but, the processing on the SSRS side will continue (I’m guessing, I haven’t checked).

The cancel request is a “suggestion” for the process, if it is there to accept it and knows how to and what to do when it accepts it, to let it know that it would be nice for it to stop please and thank you. There are lots of reasons why a specific process can’t–some of them can’t by design due to the nature of what that specific process does. The cancel request isn’t the system taking a hammer to it to get it to stop, which is what a lot of people believe it really is.

When the taskagent/processserver processes restart, it should look for any systaskkill records and then mark any tasks that were on the ACTIVE tasks tab as CANCELLED–what you are running into could be a bug in the version of ERP that you are on.

2 Likes