No, it doesn't really make much sense.
First of all - what is the *problem*? A task not terminating isn't, necessarily, a problem. It might be annoying and unsightly but is there an actual problem like maybe some data doesn't get exported or a report doesn't get generated or some business process goes wrong...
If you do go ahead and terminate the process does it solve your problem? Or does it just happen again the next time the task runs?
What do you mean by "is being left running"?
Who is doing the leaving? "Left running" by whom? Or what action was supposed to transition it from running to not running? And why is that no longer happening? A scheduled task will launch a process but unless you go out of your way the task scheduler doesn't generally terminate those tasks. They usually run until some internal criteria is met and then they exit. Understanding that criteria could lead to understanding why it is not happening.
Or...
Are you saying that it is running longer than "usual" (which would imply that you have records showing what is "usual") or, perhaps, longer than "expected" (which implies that you have a length of time in mind). Or are you saying that it is never finishing (and that it used to finish and terminate cleanly)?
Do you have the source to saonlineack_v2? That sounds like custom code.
Even if you lack the source you can run "proGetStack <processid>" from a proenv command line and get a protrace.<processid> file which will contain a 4gl stack trace. That stack trace will tell you what line of code is being executed at the moment you run proGetStack. If your code is looping, or blocking on something (maybe someone has a record lock on something that you need), or just executing a massive out of control query you will know where to look for more insight. Or, if it is vendor code and you don't have the source, you can tell the vendor where to look.
Why are you worried that others may be running a Progress session? That shouldn't be a concern about terminating _this_ process. You said this is a dedicated server. So terminate interlopers with extreme prejudice. (Ok, that might be slightly anti-social, you could always give them a warning or two and then kill them...)
The more general concern about terminating a Windows process is that if the process being terminated is connected to the database via shared memory then there is a risk that killing it via task manager will crash the database. That will impact all users of that database. Not just users on that same Windows instance. If you are unsure if the process is using shared memory look for -S on the command line. You show a -S above so this process is NOT using shared memory and, therefore, killing this process is not risking a db crash.
Does this task create any logs that show any errors or which might provide any insight into what is happening? You might want to consider adding "-clientlog logfilename" to your process startup parameters if there is no current logging.
Beyond that, I have a few observations:
1) It is a headless batch job. It should not be prowin32, it should be _progres. Not that that has anything to do with the problem du jour. It just bugs me.
2) "OE111" suggests OpenEdge 11.1. Which aligns well with "after 10 years". Have either Windows or Crystal Report been upgraded or received service packs since this process was deployed? (I'm pretty sure that Windows is getting service packs more or less every week.) What is your excuse for running a woefully obsolescent release of OpenEdge and failing to apply service packs to that? I see NXT in your path so I'm guessing that this is an Infor SXE deployment. In spite of what first line tech support will always tell you - it *is* possible to upgrade OpenEdge. You just need to escalate a few layers. There *are* people at Infor who understand that upgrading OpenEdge is ok.
