SIGNON Statement and Command

Initiates a connection between a client session and a server session.
Valid in: client

Syntax

SIGNON <options>

Optional Arguments

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"
Requirements: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.

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:For complete details about creating and using authentication domains, see the SAS Intelligence Platform: Security Administration Guide.

SAS Management Console: Guide to Users and Permissions 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.
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:CMACVAR= option in the RSUBMIT statement
CONNECTREMOTE=server-IDserver-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.
Example:
signon emp1 sascmd="!sascmd"; 
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.
Example:
%let sashost=hrcomputer1.dorg.com; 
signon sashost;
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.
Example:
%let sashost=hrcomputer1.dorg.com; 
signon sashost.sasport;
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.
Example:
signon hrcomp1.2267;
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.
Example:
%let sashost=hrcomp1.dorg.com 2667; 
signon sashost;
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.
Example:
signon hrcomp1._ _2267;
Alias:CREMOTE=, PROCESS=, REMOTE=
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.
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.
Alias:CSTATUS=, STATUS=
Default:YES for synchronous RSUBMITs. NO for asynchronous RSUBMITs.

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.
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.
Alias:CWAIT=, WAIT=
Default:YES
Interactions:

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.

Synchronization Points

CONNECTWAIT System Option

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=
Interactions:If multiple CSCRIPT= options are specified, the last specification takes precedence.

When you use the CSCRIPT= option, do not also use the NOCSCRIPT option. If you use NOCSCRIPT and CSCRIPT=, sign-on is canceled.

SASSCRIPT= System Option

FILENAME statement in SAS Statements: Reference and the companion that is appropriate for your operating environment.

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.
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.
Alias:SYSRPUTSYNC=
Default:NO
Interactions:If the CSYSRPUTSYNC system option is specified, the SYSRPUTSYNC= option takes precedence over the system option.

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.

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.

Synchronization Points

Example:Example 8: Forcing Macro Variables to Be Defined When %SYSRPUT Executes for an example of how to prevent SYSRPUTSYNC= option overrides.
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.
Interactions: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.

SAS/SHARE User's Guide

Example: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;
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.
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.
Default:KEEP
Interactions: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.

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.

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.

Note:Do not simultaneously use the asynchronous RSUBMIT and the PROC PRINTTO statement and redirect output. 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.

MOD option in the FILENAME statement, which varies by operating environment. See the SAS Companion that is appropriate for your operating environment.

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.
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(default) 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.
Interactions:When you specify the NOTIFY=“e-mail-address” option, you can also specify the SUBJECT=“subject-title” option.

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.

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. This behavior assumes that the NOTERMINAL system option has not been specified.

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.

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.

AUTOSIGNON System Option

LOG= and OUTPUT= options

SUBJECT= option

SAS system options that support e-mail configuration: EMAILHOST, EMAILPORT, and EMAILSY in SAS System Options: Reference.

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. Use the output from the PROC PWENCODE statement as the value for encoded-password in the appropriate statement.
Note: The encoded password is case-sensitive. Use the entire generated output string, including the key.
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=
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.
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.
OpenVMS Specifics: 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.
Check process limit quotas and privileges.
OpenVMS Specifics: 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
OpenVMS Specifics: 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;
Restriction:For z/OS, a command file cannot be used. Therefore, use a semicolon followed by options for the server's SAS invocation.
Requirement:SAS commands that contain spaces must be enclosed in double quotation marks.
Interactions:If the SASCMD= system option is already specified, the SASCMD= option that is specified in SIGNON takes precedence over the system option.

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

SYNTAXCHECK= and NOSYNTAXCHECK= system options in SAS System Options: Reference

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

COMAMID= System Option

RSUBMIT Statement and Command

NOCSCRIPT option

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.
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.
Requirements:Enclose the name of the SAS Application Server in double or single quotation marks.

If the specified SAS Application Server does not contain a SAS/CONNECT server component, the server sign-on fails.

Interactions: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.

SAS Management Console: Guide to Users and Permissions 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.
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.
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"
Requirements:Enclose the name of the SAS Application Server in double or single quotation marks.

Interactions: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:SAS Management Console: Guide to Users and Permissions 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(default) 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
Interactions:If the SIGNONWAIT system option is also specified, the SIGNONWAIT= option takes precedence over the system option.

If SIGNONWAIT is specified as a system option and the SIGNONWAIT= option is not specified, the system option will apply to the SIGNON statement.

If SIGNONWAIT=NO is specified, the USERID= and PASSWORD= options cannot be set to _PROMPT_.

To find out if sign-on has completed, use the LISTTASK statement in the RSUBMIT statement or the CMACVAR= option in the SIGNON statement.

LISTTASK Statement

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.
Interactions: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.

RSUBMIT Statement and Command

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
Interactions:If TBUFSIZE= is specified as an option in the SIGNON statement, it takes precedence over the TBUFSIZE= system option.

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.

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.

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.

If TBUFSIZE= is not specified as a system option or as an option in the SIGNON statement, the default is used.

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=

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: Concepts.
ID and Password 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';

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:
1options comamid=tcp;
   signon wnt;

   /******************************************/
   /* initiates connection to a z/OS server host  */
   /******************************************/
2filename 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                  */
   /******************************************/
6signoff tso cscript=tsoscr;
signoff wnt cscript=winscr;
1The client signs on to the server session WNT.
2The client uses a SAS/CONNECT script to sign on to the server session TSO.
3The WNT server session asynchronously processes the statements that are enclosed by the RSUBMIT and ENDRSUBMIT statements.
4The TSO server session asynchronously processes the statements that are enclosed by the RSUBMIT and ENDRSUBMIT statements.
5The client session waits for both RSUBMIT statements to complete.
6The 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;