|
WTSupported in traditional Synergy on Windows
|
WNSupported in Synergy .NET on Windows
|
USupported on UNIX
|
VSupported on OpenVMS
|
STOP [function]
Arguments
function
(optional) One of the following termination functions to perform:
- The name of a program to which to chain. (a)
- The name of a command file to which to chain. (a)
- An exit status to send to the operating system. Synergy/DE predefines two of these in a system-independent way to indicate if the operation succeeded or failed: D_EXIT_SUCCESS or D_EXIT_FAILURE. (n)
- On OpenVMS, a DCL command, with an optional argument list. (a)
Discussion
The STOP statement terminates program execution and passes control either to another program or the monitor.
If function is a program, it can be any executable program in Synergy .NET or on OpenVMS, but it must be a Synergy program compiled with the dbl compiler in traditional Synergy on Windows or UNIX. If the program is a bound program, function must be the name specified with the -b or -p compiler option. (Bound programs are not supported on .NET.)
To chain to a command file, precede the command filename with an “at” sign (@) as follows:
stop "@filename"
or
stop "$@filename"
|
When stopping to a program or command file, arguments cannot be passed. Use the EXEC subroutine instead. |
To chain to a DCL command on OpenVMS, precede the command with a dollar sign ($) as follows:
stop "$command [arg1] [arg2] ..."
If function is not specified, no further program statements are executed, control returns to the operating system prompt, and D_EXIT_SUCCESS is returned. All I/O channels that are not closed before the STOP are purged.
|
|
Even though the channel is purged, pending terminal input characters are not removed during a STOP chain. You must drain the buffer before stopping to another program. For example, while %ttsts(chan) accept(chan, dvar) |
If function is a name but is not found, a “File not found” error ($ERR_FNF) is generated.
System option #43 controls whether a Synergy application produces a stop message when a STOP statement is executed.
Windows platforms prevent exceptions from being thrown across the kernel (user32.dll) boundary. This means that a Windows callback (for example, a .NET assembly API delegate called from a WinForm or an ActiveX event called from a UI control) cannot perform a STOP chain. If a Windows callback attempts to perform a STOP chain, the runtime generates an $ERR_NOCHAIN error.
Due to a .NET Framework limitation, chaining to a program with the STOP statement in Synergy .NET causes a delay when the new program is started, and any on-screen data is cleared and recreated, which may cause flicker. We recommend that you avoid chaining with Synergy .NET.
Examples
The following example returns an error status to the operating system (on UNIX).
stop 1
The following example chains to the rpt.dbr program and the cleanup command file, respectively.
stop "rpt" stop "@cleanup"
