Chapter Contents


SAS Component Language: Reference

Modifying the Behavior of Submit Blocks

You can modify the default processing of submit blocks by specifying options in the SUBMIT statement. SUBMIT statement options control the following behaviors:

Controlling Where Submitted Code Is Executed

By default, code that is collected in the preview buffer using SUBMIT blocks is sent to SAS software for execution. SCL provides options for the SUBMIT statement that alter the default behavior. If you specify the CONTINUE option in the SUBMIT statement, you can control where code is submitted with the following options:

submits the code in the preview buffer to the command line of the next window that is displayed. The code should contain valid commands for that window; otherwise, either errors are reported or the submitted commands are ignored.

sends the code in the preview buffer to the Program Editor window. You can modify your code in the Program Editor window and then submit it for execution.

submits the code in the preview buffer to SAS software's SQL processor, from both TESTAF and AF modes. The SUBMIT SQL option enables you to submit the SQL statements without having to specify a PROC SQL statement. Submitting SQL statements directly to the SQL processor is more efficient than submitting PROC SQL statements.

Controlling What Happens After a Submit Block Executes

SCL also provides SUBMIT statement options that you can use to control what action, if any, the application takes after a submit block executes. These options are CONTINUE, IMMEDIATE, PRIMARY, and TERMINATE. Without one of these options, the code in a submit block is simply passed to the preview buffer, the application continues executing, and the code in the submit block is not processed by SAS software until the application ends.

suspends program execution while the submit block executes and then continues program execution at the statement that immediately follows the ENDSUBMIT statement. (CONTINUE is the only SUBMIT option that is valid in FSEDIT and FSBROWSE applications.)

stops program execution after the generated statements are submitted. Use this option with caution. Using this option in a labeled section that is executed individually when a CONTROL LABEL statement is in effect can prevent the execution of other labeled sections. A program in a FRAME entry does not compile if it contains a SUBMIT IMMEDIATE statement.

returns the program to the application's initial window after the generated statements are submitted. This option is useful when you want all the intermediate windows to close and you want control to return to a primary window in the current execution stream. This option causes looping if the current program is the primary window.

stops the SAS/AF task after the statements in the submit block are processed. This option is useful when an application does not need to interact with users after the submitted statements are processed. However, use TERMINATE with caution because re-invoking the application can be time-consuming.

Using SUBMIT CONTINUE in FSEDIT Applications

The behavior of a SUBMIT CONTINUE block in an FSEDIT application depends on how the application was invoked.

Submitting Statements to a Remote Host

By default, statements in a submit block are executed for processing on the local host. If SAS/CONNECT software is available at your site, you can also submit statements for processing on a remote host. To send submitted statements to a remote host, use the following form of the SUBMIT statement:

submit remote;
...SAS or SQL statements to execute
on a remote host...

In situations where an application user can switch between a remote host and the local host, the user can issue the REMOTE command to force all submits to be sent to a remote host. The syntax of the REMOTE command is REMOTE <ON|OFF>. If neither ON nor OFF is specified, the command acts like a toggle.

The REMOTE option in the SUBMIT block takes precedence over a REMOTE command that is issued by an application user. A SAS/AF application must have a display window in order to issue and recognize the REMOTE command. Before SCL submits the generated code for execution, it checks to see whether the user has issued the REMOTE ON command. If a user has issued the command, SCL checks to see whether the remote link is still active. If the remote link is active, SCL submits the code for execution. If the remote link is not active, SCL generates an error message and returns. The preview buffer is not cleared if the submit fails.

Chapter Contents



Top of Page

Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.