|
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.
Chaining to a program with the STOP statement in Synergy .NET and 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. The same problem occurs on OpenVMS, unless you use a bound chain.
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"
