Most job termination issues are primarily issues under UNIX and Linux with telnet connections, but kills apply to Windows as well.

One problem with non-hardwired connections, such as network and modem connections, is that they can become disconnected unexpectedly. (Actually, under UNIX, turning off a hardwired dumb terminal can also cause the session to be disconnected, but mainly this is an issue for telnet and modem connections.) Under UNIX, such disconnects generally cause the process to be terminated, which may not be such a good thing, particularly if the process was doing some kind of posting. To make matters worse, since the session’s display is disconnected at the same time as the process is terminated, you typically get no message on the screen, making it difficult to track what, when, or even if anything happened.  

A closely related situation occurs when a process is killed using the UNIX kill command or A-Shell KILL.LIT command (and this is independent of the hardware connection type).

Under UNIX/Linux, a process being killed or disconnected is sent a "signal" which in most cases can be trapped and responded to by a "handler", which is essentially like the error trap in a BASIC program. A-Shell contains handlers for a number of signals, but the two of interest to this discussion are SIGTERM and SIGHUP. SIGTERM is the standard kill signal and is sent by KILL.LIT/K, and by the operating system when it is preparing to shut down. (It can also be sent with the UNIX kill utility, using the –TERM switch, as well as via MX_GETSIG.) SIGHUP is the signal sent when a process has been disconnected from its terminal device, such as due to a loss of network connection, or modem hangup. (It may also be sent manually with the UNIX kill utility, using the –HUP switch, or via MX_GETSIG.)

Windows does not support these signals per se, but A-Shell does emulate the SIGTERM signal (with KILL.LIT/K).

When A-Shell receives a SIGHUP or SIGTERM signal, it generates a BASIC error (#250 for SIGHUP and #251 for SIGTERM), allowing your program a chance to do some kind of graceful shutdown instead of just being obliterated. In the case of SIGTERM the error #251 is raised immediately, while in the case of SIGHUP, the error #250 may or may not be delayed, depending on which command line options were specified when A-Shell was launched.

The BASIC error won’t do your application much good if you don’t trap it. Programmers may often neglect error trapping, both because no one likes to think about errors, and because there is a general sense that the errors you plan for are never the ones that occur. Some may also rationalize that the default handling of errors (in which the BASIC runtime system reports the error message and line number, if applicable) is as good, or better, than the typical custom error trap code. These were never great excuses, and they are even less so in the modern environment where BASIC errors can be caused so easily by disconnects, both caused by careless user action (e.g. resetting the PC) as well as by network errors that are not anyone’s fault.

A simple error trap routine might look something like the following:

on error goto TRAP:

......

TRAP:

! special handlers for errors 250-255

on err(0)-249 goto &

TRAP'HANGUP, TRAP'KILL, TRAP'QZAP, TRAP'SOCKERR, &

TRAP'TIMEOUT, TRAP'WINCLOSE

TRAP'SOCKERR:

! <This occurs only during socket comm. Sessions using

! TCPxxx.SBR; it can be handled like most other BASIC

! errors, and thus we just fall through…>

<Existing error trapping, which may display messages,

prompt user to acknowledge, chain to menu, etc., none

of which makes much sense in a disconnect situation.

See ERRMSG.SBR and FILNAM.SBR which may be very handy

in error trap routines.>

TRAP'HANGUP:

TRAP'KILL:

TRAP'QZAP:

TRAP'TIMEOUT:

TRAP'WINCLOSE:

<close files, possibly log error, no input or display>

END                 ! terminate program

Errors 254 (timeout) and 255 (window close) are discussed in the next topic. Error 252 (queue zapped) occurs if your job table record is removed or corrupted. Although these are somewhat unrelated to the hangup and kill conditions, as a practical matter, the handling is probably the same.

In addition to this method of trapping and logging disconnects, which is highly recommended, but which requires some modification to your programs, you can also have A-Shell at least create a log of these kinds of events by adding TRACE=SIGHUP to theMIAME.INI file (see the TRACE system parameter.  

A-Shell/UNIX supports several Command Line Switches (see for details) which modify the way hang-ups are processed: –h (ignore hangup signal), –hd (delayed hangup response), –hp (hangup parent), –hetcki (hangup error on tcki), and –hei (hangup error immediate).