Starting and Stopping SAS/CONNECT

Signing On to the Server

Sign On to a Server That Is Defined in the SAS Metadata Repository

About the SAS Metadata Repository

The SAS Metadata Repository is a collection of files that store metadata about SAS applications that execute in a SAS Intelligence Platform environment. In this context, SAS/CONNECT sign-on properties might already be stored as metadata in a metadata repository. Accessing a metadata server, you can continue to execute SAS/CONNECT applications in the traditional interactive and batch execution modes, but with the convenient access to configured sign-on properties. This access means that you do not need to specify SAS options for sign-on in your code. For details about the SAS Intelligence Platform, see SAS Intelligence Platform: Overview.

Access the SAS Metadata Server

Your client computer must be able to access the SAS Metadata Server in order to sign on to a SAS/CONNECT server that has been defined in the SAS Metadata Repository. You can access the SAS Metadata Server by specifying certain SAS system options. Here is an example:

options metaserver="max.apex.na.com"
metaport=8561
metaprotocol="bridge"
metauser="domain\joe"
metapass="*******";

In this example, a user submits the appropriate credentials to access the SAS Metadata Server, which runs on the computer max.apex.na.com .The bridge network protocol is used to communicate with the SAS Metadata Server via port 8561. For details about these system options, see SAS Language Interfaces to Metadata.

Sign On to the SAS Application Server

After you access the SAS Metadata Server, you can sign on to the SAS/CONNECT server component of the SAS Application Server. In the SAS Open Metadata Architecture, the metadata for a SAS Application Server specifies one or more server components that provide SAS services to a client. You must know the name of the SAS Application Server.

Before sign-on, you can see a list of the configured sign-on properties for the SAS Application Server. In this example, the name of the SAS Application Server is SASMain .

options metaserver="max.apex.na.com"
metaport=8561
metauser="domain\joe"
metapass="*******";
metaprotocol="bridge"
signon serverv="SASMain";

For details about SAS system options METASERVER, METAPORT, METAUSER, METAPASS, METAPROTOCOL, see SAS Language Interfaces to Metadata and SAS Language Reference: Dictionary.

The SERVERV= option in the SIGNON statement displays the properties of the SAS/CONNECT server component of the SAS Application Server, which is defined in the SAS Metadata Repository.

Note: If the client session is not configured to access the SAS Metadata Server, SAS displays a pop-up window in which you can configure access to the SAS Metadata Server. [cautionend]

Here is an excerpt of the output that is sent to the SAS Log:

1    options metaserver="max.apex.na.com"; 
2    signon serverv="SASMain"; 
NOTE: Server=                SASMain - Connect Server 
      Remote Session ID=     remhost
      ServerComponentID=     A5SXFC1R.AU000002  
      Remote Host=           max.apex.na.com 
      Communication Protocol=TCP 
      Port=                  7551 
      AuthDomain= DefaultAuth 
      Wait= Yes 
      SignonWait= Yes 
      Status= Yes 
      Notify= No

The output includes properties that control server sign-on and server session execution. These connection properties are saved and stored in the metadata repository via SAS Management Console. For details, see the SAS Management Console User's Guide or the online Help that is accessible from SAS Management Console.

After you view the sign-on properties, you can sign on to the server session. Here is an example:

signon server="SASMain";

A sign-on to the SAS Application Server that is named SASMain implies a SAS/CONNECT server sign-on.

Sign On to the Same Multiprocessor Computer

If your client computer is equipped with SMP, and if you want to run one or more server sessions on your computer, perform these tasks:

TCP/IP is used on SMP computers for OpenVMS, UNIX, and Windows. XMS is used on SMP computers for z/OS only.

Specify the Server Session

You can specify the server session in an OPTIONS statement:

OPTIONS PROCESS=session-ID;

You can also specify the server session in the SIGNON statement or command:

SIGNON session-ID;

session-ID must be a valid SAS name that is 1 to 8 characters in length. It is the name that you assign to the server session on the same multiprocessor computer.

Note: PROCESS= and CONNECTREMOTE= can be used interchangeably. For details, see CONNECTREMOTE= System Option. [cautionend]

For details about the SIGNON= statement, see Syntax for the SIGNON and the SIGNOFF Statements and Commands.

Use the SASCMD Option to Specify SAS

Use the SASCMD option to specify the SAS command and any additional options that you want to use to start SAS in a server session on the same multi-processor computer.

The SASCMD option can be specified in an OPTIONS statement:

OPTIONS SASCMD="SAS-command" | "!SASCMD" | "!sascmdv" | "host-command-file";

This option can also be specified directly in the SIGNON statement or command:

UNIX Example:

SIGNON name SASCMD="!SASCMD -memsize 64M -nonumber";

z/OS Example:

options sascmd=":memsize=64M nonumber";

The -DMR option is automatically appended to the command. If !SASCMD or !SASCMDV is specified, SAS/CONNECT starts SAS on the server by using the same command that was used to start SAS for the current client session.

Note:

Under the UNIX and Windows operating environments, !SASCMDV shows the SAS invocation. Under OpenVMS, !SASCMDV shows a symbol.
In order to execute additional commands before SAS is invoked, you can write a script that contains the SAS start-up commands that are appropriate for the operating environment. Specify this script as the value in the SASCMD= option.

For details, see SASCMD= System Option, and Syntax for the SIGNON and the SIGNOFF Statements and Commands.

Examples: Signing On to the Server Session

Example 1:

In the following example, TCP is the access method, SAS1 is the name of the server session, and SAS_START is the command that starts SAS on the same multi-processor computer.

options comamid=tcp;
signon sas1 sascmd='sas_start';

Example 2:

In the following example, OPTIONS statements set the values for the COMAMID= , SASCMD=, and PROCESS= options. The SASCMD= option identifies SAS_START as the command that starts SAS. The PROCESS= option identifies the server session on the same multi-processor computer. Because the SASCMD= and the PROCESS= options are defined, only a simple SIGNON statement is needed.

options comamid=tcp sascmd="sas_start";
options process=sas1;
signon;

Sign On Using a Spawner

Ensure That the Spawner Is Running on the Server

Before you can access the spawner, the spawner program must be running on the server. For details, see the topic about spawners in Communications Access Methods for SAS/CONNECT and SAS/SHARE.

Note: The system administrator for the computer that the spawner runs on must start the spawner. The spawner program on the server cannot be started in the client session. [cautionend]

Specify the Server and the Spawner Service

The name of the server can be specified by using an OPTIONS statement:

OPTIONS REMOTE=node-name[.service-name | .port-number];

The name can also be specified by using the SIGNON statement or command:

SIGNON node-name[.service-name
| .port-number];

node-name is based on the server that you are connecting to. node-name must be a valid SAS name that is 1 to 8 characters in length and is one of the following:

the short computer name of the server you are connecting to. This name must be defined in your Domain Name Server (DNS) or in the HOSTS file in the operating environment that the client session runs under.
a macro variable that contains either the IP address or the name of the server that you are connecting to.

For UNIX and OpenVMS only:

The process for evaluating node-name follows:

If node-name is a macro variable, the value of the macro variable is passed to the operating environment's GETHOSTBYNAME function.
If node-name is not a macro variable or the value of the macro variable does not produce a valid value, node-name is passed to the GETHOSTBYNAME function.
If GETHOSTBYNAME fails to resolve node-name, an error message is returned and the sign-on fails.

Note: The order in which the GETHOSTBYNAME function calls the DNS or searches the HOSTS file to resolve node-name varies based on the operating environment implementation.

You specify service-name when connecting to a server that runs a spawner program that is listening on a port other than the Telnet port. If the spawner was started by using the -SERVICE spawner option, you must specify an explicit service-name. The value of service-name and the value of the -SERVICE spawner option must be identical. Alternatively, you can specify the explicit port number that is associated with service-name.

Example 1:

REMHOST is the name of the node on which the spawner runs, and PORT1 is the name of the service that is defined in the client session. The client service PORT1 must be assigned to the same port that the spawner is listening on.

signon remhost.port1;

Example 2:

In the following example, the macro variable REMHOST is assigned to the fully qualified name of the computer on which the server runs. This server has a spawner running that is listening on port 5050. The server session that is specified in the SIGNON statement uses the node name REMHOST and the service name 5050, which is the explicit port value.

%let remhost=pc.rem.us.com;
signon remhost.5050;

You can also assign a specific port number by including the port number in the definition of the macro variable:

%let remhost=pc.rem.us.com 5050;
signon remhost;

Specify a Sign-On Script or a User ID and Password

You can use a sign-on script to sign on to the spawner, or you can sign on to a spawner without a script. If you do not use a sign-on script and if the spawner is running secured, you must supply a user ID and password to sign on to the spawner.

Note: (Windows only) If you use SSPI, supplying a user ID and a password is unnecessary. For details, see the topic about SSPI in Communications Access Methods for SAS/CONNECT and SAS/SHARE [cautionend]

Note: If you connect to a spawner, you can sign on by using a script unless the spawner is started by using the NOSCRIPT option. If the NOSCRIPT option is set, you cannot use a script. If there is no script, you do not assign the fileref RLINK in a FILENAME statement. As an alternative, you can specify the NOSCRIPT option in the SIGNON statement. For information about the spawner that you are connecting to, see the topic about spawners in Communications Access Methods for SAS/CONNECT and SAS/SHARE. [cautionend]

Specify a Sign-On Script

If you are signing on by using a script, you must specify the script that you want to use. The script file is executed by the SIGNON statement or command. By default, the script prompts for user ID and password.

To use one of the sample script files that are provided with SAS/CONNECT for signing on and signing off, assign the fileref RLINK to the appropriate script file. As an alternative, you can specify the CSCRIPT= option in the SIGNON statement. The script is based on the server that you are connecting to. The location of the sample scripts varies according to operating environment. For default locations, see Using a Script to Start and Stop SAS/CONNECT.

To specify a script, use the FILENAME statement.

UNIX Example:

FILENAME RLINK '!sasroot/misc/connect/script-name';

script-name specifies the appropriate script file for the server.

The following table lists the scripts that are supplied in SAS software:

SAS/CONNECT Sign-on Scripts for TCP/IP
Server	Script Name
TSO under OS/390	tcptso.scr
TSO under z/OS, SAS 9 or later	tcptso9.scr
z/OS (without TSO)	tcpmvs.scr
z/OS (using full-screen 3270 Telnet protocol)	tcptso32.scr
OpenVMS	tcpvms.scr
UNIX	tcpunix.scr
Windows	tcpwin.scr

Specify a User ID and Password

If you sign on to the spawner without using a script and the spawner is running secured, you must specify a user ID and a password in the SIGNON statement.

Note: (Windows only) If SSPI is available, you can submit the SIGNON statement without a user ID and password. If SSPI is not available and you are signing on to a secured spawner without using a script, you must specify a user ID and password. For details, see the topic about SSPI in Communications Access Methods for SAS/CONNECT and SAS/SHARE. [cautionend]

SIGNON USER=user-ID | _PROMPT_ [ PASSWORD=password | _PROMPT_ ];

Note: When you specify USER=_PROMPT_, the dialog box prompts for a user ID and a password. [cautionend]

For details, see SIGNON Statement and Command.

Sign On by Using the Spawner

A client connects to a UNIX server by using a spawner and without a script. In the SIGNON statement, RMTHOST.SPAWNER specifies the node RMTHOST and the service SPAWNER. This server specification presumes that a spawner is running on the node RMTHOST, and that the spawner was started by using the service SPAWNER. Specifying USER=_PROMPT_ causes a dialog box to appear so that a user ID and a password can be provided.

Example:

options comamid=tcp;
signon rmthost.spawner user=_prompt_;

If Necessary, Change an Expired Password (z/OS Spawner Only)

A password expiration policy is usually established by the system administrator of the z/OS operating environment. During sign-on, a message is displayed to alert you to the need to change an expired password:

Password expired/invalid, enter new password:

You can enter a new password during sign-on only if you are using a script file for sign-on.

Note: You could also change the password in a Telnet login to the operating environment. [cautionend]

For details about tasks for a client sign-on to a z/OS server session using a spawner, see Communications Access Methods for SAS/CONNECT and SAS/SHARE.

Sign On Using a Telnet Daemon

Specify the Server

The name of the server can be specified in an OPTIONS statement:

OPTIONS REMOTE=node-name;

The name can also be specified directly in the SIGNON statement or command:

SIGNON node-name;

Specify a Sign-On Script File

When signing on by using the Telnet daemon, specify a sign-on script. The script file is executed by the SIGNON statement or command. By default, the script prompts for user ID and password. For details, see SIGNON Statement and Command.

Example: Signing On to the Server Session

You specify the statements in a client session that runs under UNIX to use the TCP/IP access method to connect to a z/OS server. The FILENAME statement identifies the script file that you use to sign on to a server. The script file contains a prompt for a user ID and a password that are valid on the server. The COMAMID= option specifies the TCP/IP communications access method for connecting to the server RMTNODE, which is specified in the REMOTE= option.

UNIX example:

filename rlink '!sasroot/misc/connect/tcptso.scr';
options comamid=tcp remote=rmtnode;
signon;

Top of Page