How to break out of program running in infinite loop in PDSO

CTRL-Break? Or find the CPU-internsive prowin32.exe or prowin.exe in Task Manager and kill it.

The OE-dba in me thinks you might want to be very careful.  Is this a "shared memory" client application?  Aren't those always risky to kill (IE. by killing them, it risks an OE database crashing, or worse)?    

It seems like you should take into consideration whether it is a "shared memory" app, vs a remote "client-server" app (which is connected by TCP.)

You might want to try to use the disconnect operation on the related user *before* killing the application, right?

  proshut <db-name> -C disconnect <user-num>

I don't mean to cause alarm, but there are KB's that talk about the dangers of killing processes that share memory with the database, eg. knowledgebase.progress.com/.../P14679

Agreed.

>> I’m killing (DELETE key in Windows Task Manager) runaway prowin.exe’s since years. And my DB’s have never become inconsistent.

That is good to know.  Maybe there is less risk of problems in doing this on Windows (vs UNIX)?  On the UNIX side we have had bad experiences.  Thankfully HP-UX is nearing the end of its life.

All we need now is a KB from Progress where they give this their BLESSING, instead of a ton of articles that say NOT to kill "shared memory" ABL processes.

Killing shared memory connections _is_ unsafe.  The kbase articles are correct to warn people not to do it.

But, as Mike observes, the circumstances here are such that it ought not to matter.  So what if your development db on your PC crashes?  That's not a big deal.

I have probably not read *every* kbase on the topic but the "unsafe" part of killing a shared memory connection is that it might cause the db to crash.

BY ITSELF that will not cause any integrity problems.  You will just restart and go through crash recovery.

People end up with corruption and similar issues when they take additional steps like restarting with -F or using OS level tools to manipulate the data extents.  There is an unfortunately strong correlation between people who use "kill -9" and people who take those other steps.  That sometimes leads to the false impression that killing the shared memory connection corrupts data.

Thanks for your useful suggestion !! . Actually i am testing a code in Progress Developer Studio which has a UI and i want to stop the execution at any point whenever i want to . Same as we do using CTRl-PAUSE-BREAK in Progress GUI .

Is there any other similar option in PDSOE .

Thanks for your useful suggestion !! . Actually i am testing a code in Progress Developer Studio which has a UI and i want to stop the execution at any point whenever i want to . Same as we do using CTRl-PAUSE-BREAK in Progress GUI .

Is there any other similar option in PDSOE .

For example : Please refer below code . If i run this code in PDSOE , it will show the frame with options as written in the code . I want to stop the program without using the Exit option in the frame .

DEFINE VARIABLE msg  AS CHARACTER NO-UNDO EXTENT 3.

DEFINE VARIABLE ix   AS INTEGER   NO-UNDO INITIAL 1.

DEFINE VARIABLE newi AS INTEGER   NO-UNDO INITIAL 1.

DEFINE VARIABLE func AS CHARACTER NO-UNDO.

/*LAST-EVENT:SET-LASTKEY(0, keycode("insert")).*/

/*/*assign lastkey = keycode("insert").*/      */

/*apply lastkey .                              */

DISPLAY

 "     Please choose     " SKIP(1)

 " 1  Run order entry    " @ msg[1] ATTR-SPACE SKIP

 " 2  Run receivables    " @ msg[2] ATTR-SPACE SKIP

 " 3  Exit               " @ msg[3] ATTR-SPACE SKIP

 WITH CENTERED FRAME menu NO-LABELS.

REPEAT:

 COLOR DISPLAY MESSAGES msg[ix] WITH FRAME menu.

 READKEY.

 func = KEYFUNCTION(LASTKEY).

 IF func = "CURSOR-DOWN" AND ix < 3 THEN

   newi = ix + 1.

 ELSE IF func = "CURSOR-UP" AND ix > 1 THEN

   newi = ix - 1.

 ELSE IF func = "GO" OR func = "RETURN" THEN LEAVE.

 IF ix <> newi THEN

   COLOR DISPLAY NORMAL msg[ix] WITH FRAME menu.

 ix = newi.

END.

Running code from Developer Studio (PDSOE), assuming you are using a separate AVM to do that, which is the default, is no different than running it with -p.  If CTRL-Break doesn’t work, it is not because you are running from PDSOE.

>>  There is an unfortunately strong correlation between people who use "kill -9" and people who take those other steps.  That sometimes leads to the false impression that killing the shared memory connection corrupts data.

Tom, I can understand this point of view because I have a long experience with Progress too, and after a while you learn how to avoid some of the more severe pitfalls.

But I can see the other side too.   We are talking about the crashing of the *entire* OE database server because a *single* connected client was misbehaving and needed to be terminated.  It isn't reasonable for a system admin to face these high stakes whenever they must terminate a runaway (or hung) client application.  Nor does it seem right that we should "blame the victim" when the OpenEdge database goes into a panic mode and decides to crash itself, and it results (directly or indirecly) in subsequent database corruption.

On a personal note, I recently opened a bug (KB 000089700) where one of the workarounds for the problem, once encountered, is to terminate a remote server with promon (see article P39432 for those instructions).  This is analogous to killing a shared memory client.  If we ever face any subsequent data corruption as a result of that bug, or the recommended workaround, then it is definitely the OE database that will be getting the blame.

The original post that we were talking about is regarding a situation in someone's development environment.  I agree that bad habits can start there but I think it is a bit of a leap in this case.

Roughly 30 years ago I found this whole thing very annoying too.  I made some bold statements about how it should be done differently to some guy named "gus" on PEG.  I am hoping that those posts have all been lost to the ages but he was remarkably patient with me.

I did eventually learn a few things about why it is the way that it is and I especially learned about the things that I should have known better than to be doing.  I stopped doing that stuff.

You are also quite right -- Progress is going to be blamed.  That hasn't changed in 30+ years and it probably never will change.

None the less -

It isn't reasonable for a "sys admin" to look at "kill -9" as the cure all for all problems.  Those are the sys admins with the especially unfortunate bad habits.

Another one of those bad habits is deciding that a process "needs to be terminated" all too casually.  An awful lot of processes that offend people's sensibilities are doing no harm and should be simply left alone.

If your sys admin thinks that kill -9 "always works" or words to that effect you should not blame Progress -- you need a new sys admin.  If you cannot educate that sys admin then there are almost certainly lots of other things that they have been up to that will need to be fixed.  You probably want to start by taking all of that person's shell scripts out into the desert and burning them.

Following the recommended procedure to disconnect a shared memory client is not analogous to to killing a shared memory client with "kill -9".  "Kill -9" is swatting a fly with a truck.  It is the completely wrong tool for the job and it *will* break things.  But it will not, by itself, corrupt your database.

(For the record -- once in a very great while we do run into situations where the recommended procedure fails and the process cannot be cleanly disconnected.  In almost all cases we decide to allow the problematic process to stay attached until we have a "quiet time" or maintenance window available.  It is not an everyday occurrence.  It happens much less than monthly across our customer base and some of those customers are very, very large and active.  So far as I can recall we have resorted to a daytime "kill -9" once in the last 2 or 3 years.  And I don't remember the time before that.)  

I also certainly agree that more effort should go into educating people not to use "kill -9" or taskmgr (which is basically the same thing in Windows land) and that the fallout when someone does do that should be better handled.  One really good place to start should be making the .lg file messages surrounding such events a whole lot clearer.  Another good idea would be to create a dedicated tool for disconnecting sessions that explains the options and the pros and cons of the internal options as well as the consequences of the external options.  Make it easier for people to do the right thing.  Don't hide it in options to tools that sound very much like the wrong thing to be doing.

> Another good idea would be to create a dedicated tool for disconnecting sessions that explains the options and the pros and cons of the internal options as well as the consequences of the external options.

I believe it would be enough to have a flag in Usrctl table (let's say a "banishment" flag as an addition to the "usertodie" flag) that will prohibit a user to lock any resources in the shared memory. Also a database should not crash if a dead session was simply waiting for a buffer lock (but the current reaction is "User died during microtransaction"). And finally we could do the same checks with the "banned" sessions as watchdog does for the dead ones. If the "banishment" was successful then it's safe to use kill -9.

I do very much like your "banishment" flag idea.

But...

The reason that I think adding a named tool specifically to manage disconnections is that people don't think.  Carefully executed actions that follow a defined procedure are the exception out there -- not the rule.

The overwhelming majority of people responsible for OpenEdge databases are not trained and experienced OE DBAs and they they are very often not particularly trained at administering the OS that OE is installed on either.  They are even less trained with regards to the peculiarities of OpenEdge (this was one of David's key points).  

We can advocate for adding all of the helpful technical safeguards in the world and people will still do the wrong thing.  

They *will* take the path of least resistance.  Every time.  And Progress will be blamed.  Every time.

To improve the behavior you need to make it really easy to do the right thing more often and, preferably, by default.

Having the "disconnect" options buried in "proshut" is not exactly intuitive.  And the lack of helpful, supportive tools to get untrained people through this process is problematic.   Proshut doesn't even warn you if you are wanting to disconnect user #2 and accidentally select option #2 (yes, I have been personally traumatized by this, it was a long time ago but the pain still burns).

This next bit veers off into technical minutiae but I didn't think there were any states where merely *waiting* for a latch causes a crash.  I was under the impression that the session had to actually be executing the code protected by a latch for a panic to be appropriate.  That makes sense to me -- the stuff going on inside latch protected code involves data that is local to the process execution.  There would not be any reasonable way to undo half done changes.

For instance -- if the latched code is moving an item on a linked list there are at least two pointers that need to be updated.  The process making the change knows what item it is moving and which entries are being changed.  Nobody else knows that.  If it has changed the pointer to the original item to now point to the next item the list no longer knows where the original item is.  If you crash at that point the thing you are moving will be lost - nobody is pointing to it.  The list is consistent but incomplete.  Likewise you could move it first and then remove it, but if you crash in the middle of those actions you have a double entry.  In this case you might think that a second list could be keeping track of everything just in case and that in the event of a failure the list could be scanned and rebuilt.  But that has a cost and we'd probably complain about that too.

(My example may, or may not be anything that OpenEdge actually does -- I'm trying to keep it very simple.  But there are certainly data structures protected by latches for consistency reasons and the performance trade off has to be considered.)

Tom,

"Proshut doesn't even warn you if you are wanting to disconnect user #2 and accidentally select option #2 (yes, I have been personally traumatized by this, it was a long time ago but the pain still burns)."

+1

Business stopped for ~300 people

Stefan

Tom,

"Proshut doesn't even warn you if you are wanting to disconnect user #2 and accidentally select option #2 (yes, I have been personally traumatized by this, it was a long time ago but the pain still burns)."

Been there. Done that, Traumatized to this day, too.

(I just have 10 users... but one of them has a voice pitch specially so high...)