Syntax for the SIGNON and the SIGNOFF Statements and Commands

SIGNON Statement and Command

Initiates a connection between a client session and a server session.

Valid in:

client session

Syntax
Options
Difference between the SIGNON Command and Statement
Difference between Synchronous and Asynchronous SIGNONs
Difference between SIGNON and AUTOSIGNON
User ID and Password Naming Conventions
Examples
	Example 1: Sign-on Using a SAS/CONNECT Script
	Example 2: Secured Sign-on Using an Encoded Password
	Example 3: Creating a Sign-on Windows Command File
	Example 4: Signing On to Two Server Sessions for Remote Processing
	Example 5: Using MACVAR to Test for a Successful Sign-on

Syntax

SIGNON <options>

Options

AUTHDOMAIN=auth-domain | "auth-domain"

specifies the name of an authentication domain, which is a metadata object that manages the credentials (user ID and password) that are associated with the specified domain. Specifying the authentication domain is a convenient way to obtain the metadata-based user credentials rather than having to explicitly supply them during server sign-on.

An administrator can define an authentication domain by using the User Manager in SAS Management Console.

Examples:

authdomain=DefaultAuth
authdomain="SAS/CONNECT Auth Domain"

Requirement:	The authentication domain and the associated credentials must be stored in a metadata repository, and the metadata server must be running in order to resolve the metadata object specification.
Requirement:	Enclose domain names that are not valid SAS names in double or single quotation marks.
Interaction:	If you specify AUTHDOMAIN=, do not also specify USERNAME= and PASSWORD=. Otherwise, sign-on is canceled.
See Also:	For complete details about creating and using authentication domains, see the SAS Intelligence Platform: Security Administration Guide.
See Also:	SAS Management Console User's Guide and SAS Management Console online Help

CMACVAR=value

specifies the macro variable to associate with the server session. The macro variable is set at the completion of the execution of the SIGNON statement. The macro variable becomes the default macro variable for the current server session.

Note: If the SIGNON command or statement fails because of incorrect syntax, the macro variable is not set. [cautionend]

Here are the values for the CMACVAR= option:

0	indicates that the sign-on is successful.
1	indicates that the sign-on failed.
2	indicates that you have already signed on to the current server session.
3	indicates that the sign-on is still in progress.

Alias:	MACVAR=
Interaction:	This default can be overridden only by specifying the CMACVAR= option in the RSUBMIT statement or command.
See Also:	CMACVAR= option in the RSUBMIT statement

CONNECTREMOTE=server-ID server-ID

specifies the name of the server session that you want to sign on to. If only one session is active, server-ID can be omitted. If multiple server sessions are active, omitting this option causes the program statements to be run in the most recently accessed server session. The current server session is identified by the value that is assigned to the CONNECTREMOTE system option.

You can specify server-ID using different formats:

process-name

process-name is a descriptive name that you assign to the server session on a multi-processor computer when the SASCMD= option is used.

computer-name

computer-name is the name of a computer that is running a Telnet daemon or that is running a spawner that is not specified as a service. If the computer name is longer than eight characters, a SAS macro variable name should be used.

computer-name.port-name

computer-name is the name of a server, and port-name is the name of the port that the spawner service runs on. If the computer name is longer than eight characters, assign the computer name to a SAS macro variable and use the macro variable name as the server ID.

computer-name.port-number

computer-name is the name of a server, and port-number is the port that the spawner service runs on.

CAUTION:

Specifying computer-name.port-number for the server ID will fail under these conditions:

when used in a WAITFOR statement that is used to wait for the completion of an asynchronous RSUBMIT.

Instead, use a one-level name, such as the computer-with-port.
when used in a LIBNAME statement.

Instead, use a one-level name or a two-level name, such as computer-name._ _port-number.

computer-with-port

computer-with-port is a macro variable that contains the name of a server and the port that the spawner service runs on, separated by one or more spaces. This specification is appropriate in cases where the server-ID must be specified as a one-level name.

computer-name._ _port-number

computer-name is the name of a server and port-number is the port that the spawner service runs on. This format can be used to specify the server-ID value for the SERVER= option in a LIBNAME statement.

These examples of specifying server-ID correspond to the preceding formats.

	1 signon emp1 sascmd="!sascmd";
	2 %let sashost=hrcomputer1.dorg.com; signon sashost;
	3 %let sashost=hrcomputer1.dorg.com; signon sashost.sasport;
	4 signon hrcomp1.2267;
	5 %let sashost=hrcomp1.dorg.com 2667; signon sashost;
	6 signon hrcomp1._ _2267;

Alias:	CREMOTE=, PROCESS=, REMOTE=
See Also:	CONNECTREMOTE= System Option

CONNECTSTATUS=YES|NO

specifies whether the Transfer Status window is displayed for file transfers within the current server session.

Here are the values for this option:

YES\|Y	indicates that the Transfer Status window is displayed for file transfers within the current server session.
NO\|N	indicates that the Transfer Status window is not displayed for file transfers within the current server session.

Alias:

CSTATUS=, STATUS=

Default:

YES for synchronous RSUBMITs. NO for asynchronous RSUBMITs.

Interaction:

If the CONNECTSTATUS= option is omitted from the SIGNON statement, its value is resolved as follows:

1	If the CONNECTSTATUS system option is specified, the value for the CONNECTSTATUS system option is used.
2	If the CONNECTSTATUS= option is specified in a subsequent RSUBMIT, PROC UPLOAD, or PROC DOWNLOAD statement, that value would override the default value of CONNECTSTATUS= option for SIGNON.
3	Otherwise, the default behavior occurs. The default for a synchronous RSUBMIT is YES, which displays the Transfer Status window. The default for an asynchronous RSUBMIT is NO, which does not display the Transfer Status window.

See Also:

Transfer Status Window

See Also:

CONNECTSTATUS System Option

CONNECTWAIT=YES|NO

specifies whether RSUBMIT blocks execute synchronously or asynchronously. Synchronous RSUBMIT statements are executed sequentially. An RSUBMIT must be completed in the server session before control is returned to the client session.

For asynchronous RSUBMIT statements, you can execute tasks in multiple server sessions in parallel. Control is returned to the client session immediately after an RSUBMIT begins execution to allow continued execution in the client session and in other server sessions.

Here are the values for the CONNECTWAIT= option:

YES\|Y	specifies that the RSUBMIT blocks execute synchronously.
NO\|N	specifies that the RSUBMIT blocks execute asynchronously.

Alias:

CWAIT=, WAIT=

Default:

YES

Interaction:

If the CONNECTWAIT= option in SIGNON is omitted, the value for the CONNECTWAIT= option is resolved as follows:

1	If a value for the CONNECTWAIT= option has been specified in the RSUBMIT statement, that value is used.
2	If the CONNECTWAIT system option is set, the value for the system option is used.
3	Otherwise, the default behavior, to execute synchronously, occurs.

Interaction:

If CONNECTWAIT=NO is specified, you might also specify the CMACVAR= option. CMACVAR= enables you to programmatically test the status of the current asynchronous RSUBMIT to find out whether the task has completed or is still in progress.

When %SYSRPUT executes within a synchronous RSUBMIT, the macro variable is defined to the client session as soon as it executes.

When %SYSRPUT is executed within an asynchronous RSUBMIT, the macro variable is defined in the client session when a synchronization point is encountered. To override this behavior, use the SYSRPUTSYNC= system option.

Note: If CONNECTWAIT=NO is specified, an automatic sign-off will not occur unless CONNECTPERSIST=NO is also specified. [cautionend]

See Also:

SYSRPUTSYNC System Option

See Also:

Synchronization Points

See Also:

CONNECTWAIT System Option

CREMOTE=

CSCRIPT=file-specification

specifies the SAS/CONNECT script file to be used during sign-on.

When the SIGNON command executes, SAS log messages for the server session are displayed in the LOG window of the client session.

file-specification

specifies the location of the SAS/CONNECT script file.

Here are the values for file-specification:

"filename"

s the physical location of the SAS/CONNECT script file in the current working directory. Enclose the filename in double or single quotation marks.

fileref

is the name of the reference file that is associated with the script file. A previously executed FILENAME statement must define the fileref.

If the fileref that you define for the script is the default fileref RLINK, you can omit this specification from the SIGNON command.

"fully-qualified-filename"

is the full path to the SAS/CONNECT script file. Enclose the fully qualified filename in double or single quotation marks.

"SASSCRIPT-specification"

is the physical location of the SAS/CONNECT script file in the directory that is specified by the SASSCRIPT system option.

Alias:	SCRIPT=
Interaction:	If multiple CSCRIPT= options are specified, the last specification takes precedence.
Interaction:	When you use the CSCRIPT= option, do not also use the NOCSCRIPT option. If you use NOCSCRIPT and CSCRIPT=, sign-on is canceled.
See Also:	NOCSCRIPT option
See Also:	SASSCRIPT= System Option
See Also:	FILENAME statement in SAS Language Reference: Dictionary and the companion that is appropriate for your operating environment.

CSTATUS=

CSYSRPUTSYNC=YES|NO

specifies whether to synchronize the client session's macro variables when the client session receives results from the server session or when a synchronization point is encountered. Macro variables are updated in the client session using the %SYSRPUT macro in a SIGNON statement.

Note: The %SYSRPUT macro is executed in the server session. [cautionend]

Here are the values for this option:

YES|Y

specifies that the client session's macro variables will be updated when the client receives the results of the server session's execution of the %SYSRPUT macro. The results are delivered in the form of a packet. Specifying YES does not mean that the client's macro variables will be updated immediately after the server's execution of the %SYSRPUT macro variable. YES means that the client's macro variables will be updated when the client receives the packet from the server. Therefore, the exact time at which the client's macro variables are updated will depend on the availability of the client to receive the packet. If the client is busy, the server will wait until the client session is ready to receive the packet.

NO|N

specifies that the client session's macro variables will be updated when a synchronization point is encountered. This is the default.

Default:	NO
Alias:	SYSRPUTSYNC=
Interaction:	If the CSYSRPUTSYNC system option is specified, the SYSRPUTSYNC= option takes precedence over the system option.
Interaction:	If the SYSRPUTSYNC system option is specified and the CSYSRPUTSYNC= option in SIGNON is not specified, the system option will apply to the SIGNON statement.
Interaction:	Changing the value assigned to the CSYRPUTSYNC= option between consecutive asynchronous RSUBMIT statements causes unpredictable results. You are advised not to change the value between asynchronous RSUBMIT statements.
See Also:	Synchronization Points
See Also:	SYSRPUTSYNC System Option
Featured In:	For an example of how to prevent CSYSRPUTSYNC= option overrides, see Example 8: Forcing Macro Variables to Be Defined When %SYSRPUT Executes.

CWAIT=

INHERITLIB=(client-libref1<=server-libref1> ... client-librefn<=server-librefn>)

enables libraries that are defined in the client session to be inherited by the server session for read and write access. Also, each client libref can be associated with a libref that is named differently in the server session. A space is used to separate each libref pair in a series, which is enclosed in parentheses.

Note: Because the SAS WORK library cannot be reassigned in any SAS session, you cannot reassign it in the server session either. [cautionend]

This example shows that the libref named LOCAL in the client session is inherited for use in the server session:

signon job1 inheritlib=(local work=remote);
rsubmit;
   libname local list;
   libname remote list;
   data local.a; 
   x=1; 
   run;
endrsubmit;

Interaction:	If you use the INHERITLIB= option and the SASCMD= option when signing on to a server session, the server session attempts to access the client library directly rather than to inherit access to the library via the client session. If the client session and the server session attempt to access the same file simultaneously, only one session is granted exclusive access to the file. The other session's access to the file is denied. SAS/CONNECT does not support concurrent multi-user access to the same file. This functionality is supported by SAS/SHARE.
See Also:	SASCMD=
See Also:	SAS/SHARE User's Guide

LOG=KEEP | PURGE | file-specification OUTPUT=KEEP | PURGE | file-specification

Used only when NOSIGNONWAIT is in effect, these options direct the SAS log or the SAS output that is generated by the current server session to the backing store or to a file specification. A backing store is a SAS utility file that is written to disk in the client SAS WORK library.

Here are the values for these options:

KEEP

spools log or output lines, as applicable, to the backing store or to the computer on which the client session is running. The log or output lines can be retrieved using the RGET, RDISPLAY, RSUBMIT CONNECTWAIT=YES, or SIGNOFF statement. This is the default.

PURGE

deletes all the log or output lines that are generated by the current server session. PURGE is used to save disk resources. Use PURGE if you can anticipate a large volume of log data or output data to the backing store that you do not want to keep, and you want to preserve disk space.

file-specification

specifies a file that is the destination for the log or output lines. The file is opened for output at the beginning of the asynchronous RSUBMIT and is closed at the end of the RSUBMIT. After the current RSUBMIT has completed, subsequent RSUBMIT log or output lines can be appended to the preceding RSUBMIT destination file using the LOG= or OUTPUT= options to specify the appropriate filename.

Note: Directing output to the same file for multiple concurrent asynchronous RSUBMIT statements is not recommended. [cautionend]

Here are the values for this option:

"filename"

is the physical location of the SAS log file or the SAS output file. Enclose the filename in double or single quotation marks.

fileref

is a SAS name that is associated with the physical location of the SAS log file or the SAS output file.

Note: Use the MOD option in the FILENAME statement to open the referenced file for an append. The MOD option is an external I/O statement option. [cautionend]

Default:	KEEP
Interaction:	Use the LOG= or OUTPUT= option only when the SIGNONWAIT=NO option or the NOSIGNONWAIT system option has been specified. Otherwise the option is ignored and this message is displayed: WARNING: LOG=/OUTPUT= options invalid with synchronous rsubmit. Options will be ignored.
Interaction:	If you direct the log or output lines to a file and then use RGET or RDISPLAY to retrieve the contents of an empty backing store, you will receive a message such as the following: WARNING: The LOG option was used to file log lines for the current SIGNON. There are no log lines for RGET to process. CAUTION: Do not simultaneously use the asynchronous RSUBMIT and the PROC PRINTTO statement and redirect output. Caution: Redirecting output by using a LOG= or an OUTPUT= option in the SIGNON statement and using a locally submitted PROC PRINTTO statement can cause unpredictable results. If you use both the asynchronous RSUBMIT and the PROC PRINTTO statements, you might expect that the PROC PRINTTO statement causes data from the server session to be written to the file that is specified in the PROC PRINTTO statement. If this PROC PRINTTO behavior occurs, the LOG= or the OUTPUT= option in the SIGNON statement is ignored, and no data is written to the backing store or to the specified file. However, because the asynchronous RSUBMIT and the PROC PRINTTO statements execute simultaneously, predicting which operation will complete first is impossible. The timing of the completions of these operations determines whether the results are written to the SIGNON log or to the PROC PRINTTO log.
See Also:	SIGNONWAIT option
See Also:	SIGNONWAIT System Option
See Also:	MOD option in the FILENAME statement, which varies by operating environment. See the SAS Companion that is appropriate for your operating environment.

MACVAR=

NOCSCRIPT

specifies that no SAS/CONNECT script file should be used for sign-on. NOCSCRIPT accelerates sign-on and conserves memory resources.

Alias:	NOSCRIPT
Interaction:	When you use NOCSCRIPT, do not also use SASCMD=, SERVER=, or CSCRIPT=. If you use NOCSCRIPT with SASCMD=, NOCSCRIPT is ignored. If you use NOCSCRIPT with SERVER= or CSCRIPT=, sign-on is canceled.
Tip:	NOCSCRIPT is useful if SASCMD= has been specified in a spawner invocation.
See Also:	CSCRIPT= option

NOSCRIPT=

NOTIFY=YES | NO | "e-mail-address"

specifies whether to notify the user that an asynchronous RSUBMIT has completed. The notification can be in the form of a message window or an e-mail message. The NOTIFY option is enabled only at sign-on and remains in effect for the duration of the server session.

Here are the values for this option:

YES|Y

enables notification via a message window. Here is the format of the default message:

Asynchronous task TASK1 has completed.

TASK1 is the server ID.

The message window does not interfere with any other task executions in progress. To acknowledge the message and to close the window, click OK.

NO|N

disables notification. This is the default.

"e-mail-address"

enables notification via an e-mail message, and specifies the e-mail address of the recipient for the notification. E-mail addresses are limited to a maximum of 256 characters. Enclose the e-mail address in double or single quotation marks.

The message includes information about the total time that was used for the RSUBMIT. If the LOG= and OUTPUT= options are also specified in a SIGNON statement, the e-mail message identifies the locations of the log file and output file.

Here is an example of enabling notification in a SIGNON statement:

options sascmd="!sascmd";
signon process1 wait=no notify=yes;
rsubmit;
   %put should get notification window;
endrsubmit;

To disable notification, you must sign off the server session and then sign on to the server session again, and either omit the NOTIFY= option or specify NOTIFY=NO in the SIGNON statement.

Here is an example of disabling notification in the next SIGNON statement:

signoff process1;
options sascmd="!sascmd";
signon process1 wait=no notify=no;
rsubmit;
   code-to-be-executed-in-server-session
endrsubmit;

Default:	NO
Restriction:	Notification occurs only for asynchronous RSUBMIT statements.
Interaction:	When you specify the NOTIFY="e-mail-address" option, you can also specify the SUBJECT="subject-title" option.
Interaction:	If NOTIFY=YES and the NOTERMINAL system option has been specified, the request for notification is ignored. This message is displayed: WARNING: The NOTIFY option is valid only if a TERMINAL is attached to this SAS session. Option will be ignored. However, notification can be directed to an e-mail address, regardless of whether the TERMINAL or NOTERMINAL system option has been specified.
Interaction:	If NOTIFY="e-mail address" is specified, but the e-mail message cannot be sent, notification will occur in the form of a message window, which is the action that occurs when NOTIFY=YES. Note: This behavior assumes that the NOTERMINAL system option has not been specified.
Interaction:	Notification fails if NOTIFY=YES or NOTIFY="e-mail address" and you specify statements or commands (such as RGET or SIGNOFF) during the asynchronous RSUBMIT that change execution from asynchronous to synchronous mode.
Interaction:	If NOTIFY="e-mail address" is specified, the SAS system and the operating environment that the SAS system runs under must be configured to support e-mail. Without appropriate configuration, your attempt to specify notification via e-mail might fail. Contact your system administrator for details.
See Also:	CONNECTWAIT=NO option
See Also:	LOG= and OUTPUT= options
See Also:	SUBJECT= option
See Also:	SAS system options that support e-mail configuration: EMAILHOST, EMAILPORT, and EMAILSY in SAS Language Reference: Dictionary

PROCESS=

REMOTE=

SASCMD="SAS-command" | "!sascmd" | "!sascmdv" | "host-command-file"

signs on to the server session on the same symmetric multiprocessing (SMP) computer that the client session is running on. This option is most useful when client and server sessions run on SMP hardware.

"SAS command"

For UNIX, OpenVMS, and Windows, specifies the command that is used to sign on to a server session.

Here is a typical example:
```
sascmd="sas"
```
As another example, commands that contain spaces must be enclosed in double quotation marks.
```
sascmd='"c:\Program Files\SAS\SAS System\9.2\sas.exe"';
```
For z/OS, specifies a colon that is followed by any SAS invocation options.

Here is an example:
```
sascmd=":ls=256"
```

"!sascmd"

For UNIX, OpenVMS, and Windows, signs on to a server session by using the same command that was used to invoke the client session

"!sascmdv"

For UNIX, OpenVMS, and Windows, signs on to a server session by using the same command that was used to start the client session and writes the SAS invocation to the SAS log.

"host-command-file"

In order to execute additional commands before SAS invocation, you can write a command file that is specific to your operating environment. Filename extensions vary according to operating environment. Windows filenames use the .bat and .cmd extensions. UNIX extensions include .sh , .csh , and .ksh . OpenVMS uses the .com extension.

Note: The SASCMD= option does not support z/OS command files. [cautionend]

The TCP/IP access method automatically adds options, such as -DMR, to the server session's SAS command.

For Windows, the TCP/IP access method also appends these options:

-COMAMID TCP
-ICON
-NOSPLASH
-NOTERMINAL

For all operating environments, you can also specify the NOSYNTAXCHECK option in the SAS invocation for the non-interactive server session. For details, see Starting SAS and Using Syntax Checking.

Restriction:

For z/OS, a command file cannot be used. Therefore, use a semicolon followed by options for the server's SAS invocation.

Interaction:

If the SASCMD= system option is already specified, the SASCMD= option that is specified in SIGNON takes precedence over the system option.

Interaction:

When you use SASCMD=, do not also use NOCSCRIPT. Otherwise, NOCSCRIPT is ignored.

Requirement:

SAS commands that contain spaces must be enclosed in double quotation marks.

See Also:

SASCMD= System Option

See Also:

SYNTAXCHECK= and NOSYNTAXCHECK= system options in SAS Language Reference: Dictionary

See Also:

ICON, NOSPLASH, and NOTERMINAL system options in SAS Companion for Windows.

See Also:

COMAMID= System Option

See Also:

NOCSCRIPT option

Restriction: OpenVMS only

If the NODETACH system option is specified, and if multiple server sessions are running under OpenVMS and you observe degraded performance, this error message is displayed:

ERROR: Process quota exceeded.
ERROR: Cannot spawn subprocess. Check process limit quotas and privileges.

NODETACH causes a sign-on to occur in a subprocess of the parent's process, which can use excessive resources. If NODETACH is specified, try setting the DETACH system option, which causes sign-ons to occur as detached processes rather than as subprocesses. For more information, see the NODETACH system option in the SAS Companion for OpenVMS on HP Integrity Servers.

To improve performance when using the NODETACH system option, ask your system administrator to set the following resources to the specified values for each sign-on to a server session:

OpenVMS Operating Environment Resource Values
User Account Resource	Minimum Value
Paging file quota	40000
Buffered I/O byte count quota	13000
Open file quota	65
Subprocess limit	1
Timer queue entry limit	1 to 8

When SAS is invoked from a captive OpenVMS account, you cannot use SASCMD= to sign on to a server session. Typically, SASCMD= performs a sign-on to a server session either in a subprocess or in a detached process. Starting subprocesses is not allowed under a captive account. A detached process that runs under a captive account cannot invoke SAS because a captive OpenVMS account is under the control of the login command procedure. The command language interpreter will execute only the commands in your login command procedure and then the process will exit.

The !sascmdv value in the SASCMD= option causes the display of a symbol that specifies how the server session was started. You can print the symbol's value by using the getsym DATA step function.

rsubmit;
   %put %bquote(
   %sysfunc (getsym(SASCMD_2042CF6B)));
endrsubmit;

SCRIPT=

SERVER="SAS-application-server"

specifies the name of a SAS Application Server that contains a SAS/CONNECT server component in its grouping. The SAS Application Server has been defined in the SAS Metadata Repository using SAS Management Console. The SAS Application Server is configured using a set of system resources, including a SAS/CONNECT server component and properties that start a SAS/CONNECT server session. The server properties are equivalent to the options that can be specified in the SIGNON statement.

"SAS-application-server": specifies a SAS Application Server that contains a SAS/CONNECT server component, which has been defined in a SAS Metadata Repository.

Requirement:	Enclose the name of the SAS Application Server in double or single quotation marks.
Requirement:	When you use the SERVER= option, certain system resources must be configured before you can access a SAS Metadata Server. For details, see Sign On to a Server That Is Defined in the SAS Metadata Repository.
Requirement:	If the specified SAS Application Server does not contain a SAS/CONNECT server component, the server sign-on fails.
Interaction:	When you use SERVER=, do not specify any other options in the SIGNON statement. If other options are specified, sign-on is canceled and this message is displayed: ERROR: Additional options are not valid with the SERVER option on the SIGNON command. These options should be specified in the server definition.
Tip:	Before you use the SERVER= option, you can use SERVERV= to view the properties that start a server session.
See Also:	SERVERV= Option
See Also:	SAS Management Console User's Guide and SAS Management Console online Help

SERVERV="SAS-application-server" | _ALL_

displays a verbose list of the properties that specify a SAS/CONNECT server sign-on. The server sign-on properties are equivalent to the options that can be specified in the SIGNON statement. The sign-on properties are associated with a SAS/CONNECT component, which is included in a set of system resources for the SAS Application Server.

"SAS-application-server": specifies a SAS Application Server that contains a SAS/CONNECT server component, which has been defined in a SAS Metadata Repository.
_ALL_: displays the sign-on properties for all SAS Application Servers that have been defined in the SAS Metadata Repository.

Here is an example that displays the values for the SAS/CONNECT component that is contained in the SAS Application Server sasmain .

signon serverv="sasmain";

Here is the output:

Server=                 hrmach1 -- SAS/CONNECT Server
Remote Session ID=      sashost
ServerComponentID=      A5Z3NRQF.AR00005L
Remote Host=            hrmach1.dorg.com
Communication Protocol= TCP
Service/Port=           sasconnect
Port=                   2267
Scriptpath=             tcpunix.scr
Tbufsize=               4096
Wait=                   No
SignonWait=             No
Status=                 No
Notify=                 "joe@apex.com"
Subject=                "hrmach1 task completed"

Requirement:	Enclose the name of the SAS Application Server in double or single quotation marks.
Requirement:	When you use the SERVERV= option, certain system resources must be configured before you can access a SAS Metadata Server. Also, one or more SAS Application Servers should be configured and should contain one or more SAS/CONNECT components. For details, see Sign On to a Server That Is Defined in the SAS Metadata Repository.
Interaction:	When you use SERVERV=, do not specify any other options in the SIGNON statement. If other options are specified, sign-on is canceled and this message is displayed: ERROR: Additional options are not valid with the SERVERV option on the SIGNON command. These options should be specified in the server definition.
See Also:	SERVER= Option
See Also:	SAS Management Console User's Guide and SAS Management Console online Help

SIGNONWAIT=YES|NO

specifies whether a sign-on to a server session is to be executed synchronously or asynchronously.

YES|Y

specifies synchronous sign-on. A synchronous sign-on causes the client session to wait until the sign-on to a server session has completed before control is returned to the client session for continued execution. YES is the default.

NO|N

specifies an asynchronous sign-on. An asynchronous sign-on to a server session begins execution and control is returned to the client session immediately for continued execution. Asynchronous sign-on allows multiple tasks (including other sign-ons) to be executed in parallel. Asynchronous sign-ons reduce the total amount of time that would be used to execute individual sign-ons to multiple server sessions. Using the saved time, the client session can execute more statements.

Default	YES
Interaction:	If the SIGNONWAIT system option is also specified, the SIGNONWAIT= option takes precedence over the system option.
Interaction:	If SIGNONWAIT is specified as a system option and the SIGNONWAIT= option is not specified, the system option will apply to the SIGNON statement.
Interaction:	If SIGNONWAIT=NO is specified, the USERID= and PASSWORD= options cannot be set to _PROMPT_.
Interaction:	To find out if sign-on has completed, use the LISTTASK statement in the RSUBMIT statement or the CMACVAR= option in the SIGNON statement.
See Also:	CMACVAR= option
See Also:	LISTTASK Statement

STATUS=

SUBJECT="subject-title"

specifies the subject title for the e-mail notification message that is sent after an asynchronous RSUBMIT completes. A subject title is limited to a maximum of 256 characters.

Here is an example of specifying a subject using e-mail notification:

options remote=myhost sascmd="!sascmd";
signon notify="joe.smith@apex.com" subject="First task completed on &SYSHOSTNAME";
rsubmit wait=no;
   code-to-be-executed
endrsubmit;

Restriction:	If NOTIFY="e-mail-address" is not specified, SUBJECT= will be ignored.
Interaction:	If SUBJECT= is specified in the SIGNON statement, the subject title will be used in e-mail notifications for asynchronous RSUBMIT statements unless the SUBJECT= option is specified in the RSUBMIT statement. If no SUBJECT= is specified, the default subject title is used: SAS/CONNECT task TASK1 has completed. TASK1 is the server ID.
See Also:	NOTIFY=
See Also:	RSUBMIT Statement and Command

SYSRPUTSYNC=

TBUFSIZE=buffer-size-in-bytes

specifies the size of the buffer that SAS/CONNECT uses for transferring data between a client session and a server session.

buffer-size-in-bytes

specifies the size of the buffer that SAS/CONNECT uses for transferring data. The value must be a number whose value is greater than 0 and is a multiple of 1024.

Default:	32768 bytes
Interaction:	If TBUFSIZE= is specified as an option in the SIGNON statement, it takes precedence over the TBUFSIZE= system option.
Interation:	If TBUFSIZE= is specified as a system option in the client session and in the server session, the value in the client session takes precedence.
Interaction:	If TBUFSIZE= is specified as a system option in the client session but is not specified in the SIGNON statement, the system option value will be used.
Interaction:	Do not specify TBUFSIZE= system option in the server session. If the TBUFSIZE= system option is included in the server's SAS invocation, an update to the server log might be delayed until the next client request for server processing has completed.
Interaction:	If TBUFSIZE= is not specified as a system option or as an option in the SIGNON statement, the default is used.
See Also:	TBUFSIZE= System Option

UID=

USER=

USERID=

USERNAME=user-ID|_PROMPT_

specifies the user ID to be used when connecting to a server session. Here are the values that can be assigned to USERNAME=:

user-ID: For details about a valid user ID, see User ID and Password Naming Conventions.
_PROMPT_: specifies that SAS prompt the user for a valid user ID. This value enforces security.

Alias:

USER=, USERID=, UID=

PASSWORD=password |"encoded-password" | _PROMPT_

specifies the password to be used when connecting to a server. The operating environment that the server runs under can also affect password naming conventions.

Here are the valid values for PASSWORD:

password

must be a valid SAS name that is 1 to 8 characters in length. The value for this option is replaced by Xs in the log. To protect this password, you should use the security software at your site to limit access to the SAS program statements that create the server.

"encoded-password"

is an encoded version of a password. Using encoded passwords promotes security and enables you to store SAS programs that do not contain clear-text passwords.

To obtain an encoded password, specify the clear-text password as input to the PROC PWENCODE statement.

Here is an example of code for obtaining an encoded password:

 proc PWENCODE in="srvmach";
run;
{sas001}c2Vydm1hY2g=

The clear-text password srvmach is specified in the PROC PWENCODE statement. The output is generated in the form {key}encoded-password . sas001 is the key, which is used to decode the encoded password to its clear-text form when the password is needed.

Note: The encoded password is case-sensitive. Use the entire generated output string, including the key. [cautionend]

Use the output from the PROC PWENCODE statement as the value for encoded-password in the appropriate statement.

For details about password naming conventions that are imposed by the operating environment, see Communications Access Methods for SAS/CONNECT and SAS/SHARE.

_PROMPT_: specifies that SAS prompt the user for a valid password. This value enforces security.

Alias:

PASSWD=, PASS=, PWD=, PW=

WAIT=

Details

Difference between the SIGNON Command and Statement

The primary difference between the command and the statement is that the SIGNON command can be issued only from the command line in any client SAS windowing environment window or in a DM statement. The SIGNON statement must be followed by a semicolon (;) and can be used in any client session.

Difference between Synchronous and Asynchronous SIGNONs

A sign-on is executed either synchronously or asynchronously.

synchronous: Client session control is not regained until after the sign-on has completed. Synchronous processing is the default processing mode.
asynchronous: Client session control is regained immediately after the client issues the SIGNON statement. Subsequent programs can execute in the client session and in the server sessions while a sign-on is in progress.

Synchronous sign-ons display results and output in the client session. If the SIGNON is asynchronous, you can use the RGET and RDISPLAY commands and statements and the LOG= and OUTPUT= options to retrieve and view the results.

Difference between SIGNON and AUTOSIGNON

You can explicitly execute the SIGNON statement to establish a connection between the client session and the server session. A sign-on entails accessing the computer that the server session will run on and then invoking a SAS/CONNECT server session.

An automatic sign-on is an implicit sign-on to the server when the client issues a remote submit request for server processing. When the AUTOSIGNON system option is set, the RSUBMIT command or statement automatically executes a sign-on and uses any SAS/CONNECT system options in addition to any connection options that are specified with RSUBMIT. For example, if you specify either the NOCONNECTWAIT system option or the CONNECTWAIT=NO option in the RSUBMIT command or statement, asynchronous RSUBMIT command or statements will be the default for the entire connection.

User ID and Password Naming Conventions

Each user ID and password is limited to 256 characters that follow these conventions:

Mixed case is allowed.
A null value, which is no value, that is delimited with quotation marks is allowed.
Quotation marks must enclose values that contain one or more spaces.
Quotation marks must enclose values that contain one or more special characters.
Quotation marks must enclose values that contain one or more quotation marks.
Quotation marks must enclose values that begin with a numeric value.
Quotation marks must enclose values that do not conform to rules for user-supplied SAS names. For details about rules, see SAS Language Reference: Dictionary.

Examples:

user=joe password=Born2run;
user=joe password='' # null space specified by contiguous quotation marks;
user='joe black' password='Born 2 run';
user='joe?black' password='Born 2 run';
user='apexdomain\joe' password='2bornot2b' # Win NT user name;
user='"happy joe"' pw=_prompt_;
user=_prompt_;
userid="myuserid" password="{sas001}c2Vydm1hY2g";

Examples

Example 1: Sign-on Using a SAS/CONNECT Script

The OPTIONS statement specifies the server-ID, and the FILENAME statement identifies the SAS/CONNECT sign-on script. The SIGNON statement initiates the connection. The TCP/IP access method is assumed by default.

options remote=rhost;
filename rlink 'external-file-name';
signon;

Example 2: Secured Sign-on Using an Encoded Password

The USERNAME= and PASSWORD=options in a SIGNON statement ensure a secured sign-on. At sign-on, the user is prompted for a user name and password, which is automatically supplied in its encoded form. For details, see the PASSWORD= option.

signon user=_prompt_ password="{sas001}MVNoYXJl";

Example 3: Creating a Sign-on Windows Command File

If you use MP CONNECT, you might want each server session to execute on a different disk. You can use the SASCMD= option to specify a command file that contains a command to change to a specific disk for the server session to run on.

An example follows of creating a Windows script named mysas.bat :

set userdrive=%1
%userdrive%
mkdir \sassdir
cd \sassdir
"C:\Program Files\SAS\SAS 9.1\sas" -nosyntaxcheck 
-work "mywork" %2 %3 %4 %5 %6 %7 %8 %9

To execute the command file, specify its name as the value for SASCMD=.

signon sascmd="mysas.bat sysjobid";

Example 4: Signing On to Two Server Sessions for Remote Processing

You want to run SAS programs on two server sessions and download data to your client session. The configuration follows:

The client session runs under UNIX.
A server session named WNT runs an unsecured spawner under Windows NT.
A server session named TSO runs under z/OS.

From the client session, you can submit the following program from the Program Editor window in interactive or non-interactive line mode:

1  options comamid=tcp;
signon wnt;

   /******************************************/
   /* initiates connection to a z/OS server host           */
   /******************************************/
2  filename tsoscr '!sasroot/misc/connect/tcptso9.scr';
signon tso cscript=tsoscr;

3   /******************************************/
     /* submit statements to a Windows NT server    */
     /******************************************/
rsubmit wnt wait=no;
   statements to be processed by Windows NT server
   
endrsubmit;

4   /******************************************/
   /* submit statements to z/OS server */
   /******************************************/
rsubmit tso wait=no;
   statements to be processed by z/OS server
endrsubmit;
5  waitfor _ALL_ wnt tso;
   /******************************************/
   /* ends both connections                  */
   /******************************************/
6 signoff tso cscript=tsoscr;
signoff wnt cscript=winscr;

The client signs on to the server session WNT.

The client uses a SAS/CONNECT script to sign on to the server session TSO.

The WNT server session asynchronously processes the statements that are enclosed by the RSUBMIT and ENDRSUBMIT statements.

The TSO server session asynchronously processes the statements that are enclosed by the RSUBMIT and ENDRSUBMIT statements.

The client session waits for both RSUBMIT statements to complete.

The client uses scripts to sign off both server sessions.

Example 5: Using MACVAR to Test for a Successful Sign-on

The following example illustrates that the macro variable from a successful sign-on will be used if an unsuccessful attempt is made.

/******************************************/
/* signon successful, rhost1 will be      */
/* set to 0 to indicate success.          */
/******************************************/
signon rhost macvar=rhost1;

/******************************************/
/* signon fails because we have already   */
/* signed on to this server session,      */
/* so rhost2 will be set to 2 to          */
/* indicate this, but rhost1 will         */
/* still be the MACVAR associated         */
/* with rhost.                            */
/******************************************/
signon rhost macvar=rhost2;

rsubmit rhost wait=no;
   data a;
   x=1;
   run;
endrsubmit;

/******************************************/
/* rhost1 is still the default and        */
/* will indicate the progress of any      */
/* subsequent RSUBMITs.                   */
/******************************************/
%put &rhost1;

Top of Page