How to stop running program

If you are the user running the program you type the "interrupt" key.  This is often control-c but it could be defined as something else on your system.

If you are an administrator who needs to stop some other user's program you need to send a signal to it.  This is done with the "kill" command (you must either be the same userid as the target process or you must be root to use "kill".).  The safest signal is SIGINT -- this will raise the STOP condition in the 4gl session.  In most cases this will result in the startup procedure being re-run (IOW the user will get to start over from their initial screen).  For instance:

# ps -ef

UID        PID  PPID  C STIME TTY          TIME CMD

tom      11521 17307  0 09:27 pts/0    00:00:00 _progres -p startup.p

# kill -SIGINT 11521

If you do not want the session to go back to the start and would rather just terminate the whole session use SIGHUP.  This is similar to a user "hanging up" or closing their terminal window.

SIGKILL, also known as "kill -9" and other similar signals are very dangerous -- they cannot be detected, caught or handled and because Progress can not detect them or react to them Progress cannot cleanup properly.  This can, and often does, lead to a database crash.  You should never use these signals unless you are prepared to deal with the consequences.

You should also be very careful about using the "trap" command in the .profile or in the scripts which launch Progress.  Using "trap" interferes with normal signal processing and can result in "runaways" and other psychotic behaviors.  See this article for more information:  http://dbappraise.com/traps.html

It’s the ancient topic but I’d like to check if there are any changes since it was discussed many years ago.

Unfortunately the classic “Traps, Kills, Hung Users, Runaways And Other Psychos” article now is not available but the idea was to send the sequence of the signals in the following order:
SIGUSR1
SIGINT
SIGQUIT
SIGTERM
SIGHUP

I guess the order can be explained by information from PROSIGTRACE:
SIGINT is the only signal that “sets SOFT ctrl-c (via utssoftctlc ()). (4465)”. The other handled signals set “HARD ctrl-c” (no matter what it means).
SIGINT and SIGQUIT are the only ones that “ignore while in unix escape. (4467)”
The descriptions of SIGTERM and SIGHUP are identical. So should we spend the time and send SIGHUP if SIGTERM did not work?

What about SIGALRM - the only one with “immediate: do not delay handling this signal. (4468)”?

The signals with the property “drSigClient: Signal dispatch specific to CLIENT. (4427)”:
SIGHUP
SIGINT
SIGQUIT
SIGTRAP
SIGPIPE
SIGTERM

So what about SIGTRAP and SIGPIPE?

Article: How Progress interprets and handles kill Signals
knowledgebase.progress.com/.../P67938

Signal Name: SIGPIPE
Common Signal Number: 13
Considered by Progress: HANDLED
Client Handling: 1) if writer wants to process broker pipe then return, 2) look for valid output stream to write broken pipe message 3) look for dead sub processes and attempt to close
their file descriptors
Server Handling: 1) IGNORED by forked process, 2) If screen exists perform some screen cleanup write message that signal received

** Pipe to subprocess has been broken. (140)
PROGRESS intercepted a SIGPIPE signal. This could be the result of a premature termination of a program used in an INPUT/OUTPUT THROUGH statement, or the abnormal termination of a shell invoked by the UNIX statement.

When the handled signals do not work and we are sure it’s safe to terminate a session then what’s better to use as an absolute last resort - one of the STANDARD fatal signals (like SIGFPE) or REALLY fatal signal (SIGKILL)?
For example, some standard fatal signals write the appropriate message to the .lg file (if it is open when the signal is received):
SIGILL - SYSTEM ERROR: Illegal instruction. (47)
SIGBUS - SYSTEM ERROR: Bus error. (48)
SIGFPE - SYSTEM ERROR: Floating point exception. (50)
SIGSYS - SYSTEM ERROR: Illegal system call. (297)

Is it the only advantage of the standard fatal signals compared to SIGKILL?

Are there any side-effects of turning on PROSIGTRACE for all processes in production environment?
The customer of our is often getting the hung sessions that can't be stopped by the handled signals.
Their protrace files used to contain the following calls:

_poll_sys [/usr/lib/hpux64/libc.so.1]
_poll [/usr/lib/hpux64/libc.so.1]
utPollMultiple [/usr/dlc/bin/_progres]
rnCheckForEvents [/usr/dlc/bin/_progres]
rnSocketSelect [/usr/dlc/bin/_progres]

_poll_sys [/usr/lib/hpux64/libc.so.1]
_poll [/usr/lib/hpux64/libc.so.1]
sock_poll_ipv4 [/usr/dlc/bin/_progres]
npp_poll [/usr/dlc/bin/_progres]
WebGetEvent [/usr/dlc/bin/_progres]

It looks like a session is waiting for a response from TCP socket opened by application itself. Are there any gentle ways to interrupt these waits?