Communications Access Methods for SAS/CONNECT and SAS/SHARE Software

SAS/CONNECT

Local Host Tasks

User or Applications Programmer

To connect a Windows local host to a remote host, perform these tasks at the local host:

Be aware of security considerations for Windows hosts.
Specify the communications access method.
Specify a remote host name.
Sign on to the remote host.

Security Considerations for Windows

Windows NT Security Considerations

Windows NT is a secure operating system, requiring that you supply a valid user name and password in order to log on. When you connect with the DECnet access method, you supply this information by including Access Control Information (ACI).

When connecting to a remote system, you can supply ACI information explicitly with the REMOTE= option. However, doing so requires that you either type your user name and password each time you connect or that you enter permanently your user name and password into the SAS program.

If proxy access is enabled on both the local and the remote nodes, and the user name is valid on both systems, DECnet uses your user name for the default ACI. Any connection you make logs you onto the remote system with the same user name that you used to log on to the local system.

If proxy access is not enabled, or you want to connect to the remote system as a different user, you must supply ACI with the value of the REMOTE= option.

You also can configure a remote Windows NT system to supply a user name for connection requests that do not contain ACI. It is possible to force a system to not send ACI. However, it is more likely that you will receive a connection request without ACI from a Windows 95, Windows 98, or Windows 32s system.

See Specifying the Remote Host Name for instructions about defining a default user name on Windows NT. The user name must be valid on the Windows NT system on which it is defined.

Note: Defining a default user name for incoming requests can compromise security. Because anyone can connect using the default id, it should not be a privileged user name, and it should be allowed to have access to sensitive data. [cautionend]

Windows 95, Windows 98, and Windows 32s Security Considerations

Windows 95, Windows 98, and Windows 32s are not secure operating systems. Because it has no concept of user name, DECnet cannot use a user name as the default ACI. You can supply ACI in the REMOTE= option just as you can with Windows NT.

However, the Pathworks software for Windows 95, Windows 98, and Windows 32s allows you to enter a default user name and password for each remote node that you want to connect to. The Network Control Program (NCP) node database contains the node definitions for remote nodes. The NCP DEFINE NODE command lets you associate a user name and a password for each node. This user name and password must be valid on the node for which it is defined.

If you do not supply ACI when you connect to a remote system, the DECnet access method uses the default ACI that is stored in the NCP node database. If no default ACI is defined for the node, then no ACI is sent. The remote system must then be configured to supply a default incoming user name; otherwise, the connection will fail.

You declare the host name, user name, and password of the remote host at the local host by using the following syntax:

DEFINE NODE node-address NAME node-name 
       USER access-information
       PASSWORD access-information

Example:

DEFINE NODE 1.300 NAME RMTHOST USER bass 
       PASSWORD time2go

See your Pathworks documentation for more information about defining a Windows 95, a Windows 98, or a Windows 32s default user name.

To connect to a Windows 95, a Windows 98, or a Windows 32s remote host, supply the host name as the value for the REMOTE= option.

Note: Defining a default ACI for a remote node can compromise security. Because anyone using the Windows 95, the Windows 98, or the Windows 32s system can get access to that user name on the remote node, the default user name should not be a privileged id, and it should not be allowed to have access to sensitive data. To permit access to such data, SAS should prompt the user for a user name and a password each time the user tries to connect to the remote node. [cautionend]

Specifying the DECnet Communications Access Method

You must specify the DECnet communications access method to make a remote host connection. Use the following syntax:

OPTIONS COMAMID=access-method-id;

where COMAMID is an acronym for Communications Access Method Identification. access-method-id identifies the method used by the local host to communicate with the remote host. DECnet (an acronym for the Digital Equipment Corporation Networking architecture) is an example of access-method-id.

Example:

options comamid=decnet;

Alternatively, you may specify this option at a SAS invocation or in a SAS configuration file.

Specifying the Remote Host Name

To make a connection from a Windows local host to a remote host, use the following syntax:

OPTIONS REMOTE=ACI-information;

where ACI-information is represented as:

nodename"username password"::
        |"? ?"::
        |"username ?"::
        |"? password"::

If proxy access is enabled on the DECnet network, specify only the remote node name. Ask your network administrator if proxy access is enabled on the DECnet network. Proxy access precludes a need for you to assign your user name and password to the ACI. Otherwise, include the user name and password information in the ACI. Use one or two question marks, (?) or (??), to request that the local host be prompted for either user name or password or both.

Note: If a password is not required for an account, you may omit the password from the ACI. [cautionend]

The remote host name and the two question marks signify a request for the local host to prompt for user name and password. Because the specification of ACI (host name, user name, and password) is not a valid SAS name, you must assign the ACI to a macro variable.

Instead of hard-coding user name and password values, you may use prompting as a security aid.

Here are some examples of specifying ACI and using secure user names and passwords.

Example 1:

%let rmthost=monarch"? ?";
options remote=rmthost;

The remote host name is MONARCH, and the two question marks signify a request for the local host be to prompted for both a user name and a password. Because the specification of ACI (host name, user name, and password) is not a valid SAS name, you must assign the ACI to a macro variable, such as RMTHOST, as shown in the first line. Then, use the SAS macro variable to define the remote host, as shown in the second line.

Example 2:

%let rmthost=monarch"bass time2go"::;
options remote=rmthost;

This example is similar to the preceding example, except that the ACI contains a literal user name and password instead of two question marks (??), which specify a prompt for a user name and a password.

Example 3:

c:> set rmthost=monarch"bass time2go"

This example is entered in a DOS window. The first line shows how to assign the remote host MONARCH the user name BASS, and the password TIME2GO to the variable RMTHOST.

Example 4:

options remote=monarch::;

Because proxy access is assumed, only the host name MONARCH is needed.

Alternatively, you may specify this option at a SAS invocation or in a SAS configuration file.

Signing On to the Remote Host

To complete your sign on to the remote host, enter the SIGNON statement, as follows:

signon;

Note: Sign-on script files are not needed on a Windows local host with the DECnet access method because DECnet connects to a spawner that runs on the remote host. [cautionend]

Although no errors are produced if you specify a script file, you do waste processing time. If you defined the RLINK fileref before establishing a connection, when you sign on, SAS/CONNECT processes and loads the script file that is identified by the fileref, but the DECnet access method will ignore the script.

If you do not want to omit the RLINK fileref but you want to avoid wasting processing time, use the NOSCRIPT option in the SIGNON and SIGNOFF statements, shown as follows:

signon noscript;
.
.
.
signoff noscript;

Local Host Example

The following example illustrates the statements that you specify in a Windows local host SAS session to connect to a remote host by using the DECnet access method.

%let rmthost=rhost"bass time2go"::;
options comamid=decnet remote=rmthost;
signon;

A macro variable is used to assign the remote host name RHOST, the user name BASS, and the password TIME2GO to the alias RMTHOST. The OPTIONS statement specifies the DECnet access method and the macro variable RMTHOST as the remote host. The SIGNON statement performs the sign-on process.

Remote Host Tasks

System Administrator

To allow a connection from a local host, perform these tasks at the remote host:

Know about DECnet network drive restrictions.
Start the PC spawner program.
Optionally, set several remote host options.

Network Drive Restrictions in Windows NT Environments

As a Windows NT security feature, DECnet prohibits users from accessing remote network drives from a remote session on a Windows NT remote host. This feature was inherited by SAS/CONNECT when it uses the DECNET access method on the Windows NT platform. This restriction may be addressed in a future release of Windows NT or Pathworks. If you need to access a network file, then copy the file to a local drive and access it there. For more information, see the Microsoft Development Library and the Windows NT Knowledge Base articles # Q124184, Q132679, and Q122702.

Starting the PC Spawner Program

You must invoke the PC spawner program on the Windows NT, the Windows 95, and Windows 98 remote host to enable local hosts to connect to it. The spawner program resides on a remote host and listens for SAS/CONNECT client requests for connection to the remote host. After the spawner program receives a request, it invokes the remote SAS session.

For Windows NT only, setting the -SECURITY option in the PC spawner invocation command secures the spawner.

The spawner then verifies the user name and the password that are assigned to the ACI.

See PC Spawner Program for information about starting the spawner on the remote host.

Setting Options at the Remote Host

Although sign-on script files are not used for the DECnet access method, you may set remote host options at the remote host.

It is recommended that you set these options:

NO$SYNTAXCHECK

allows the continuation of statement processing at the remote host regardless of syntax error conditions.

This option is valid as part of a configuration file, at a SAS invocation, or in an OPTIONS statement.

NOTERMINAL

specifies whether a terminal is attached at SAS invocation. If NOTERMINAL is specified, requestor windows are not displayed.

Set NOTERMINAL at the remote host so that no terminal is associated with the remote session. NOTERMINAL prevents SAS from displaying error messages and dialog boxes on the remote host, which requires user intervention.

This option is valid as part of a configuration file or at a SAS invocation.

See SAS Language Reference: Dictionary for details about this option.

NOXWAIT

Note: Applies to a Windows remote host only. [cautionend]

specifies whether you have to type EXIT at the DOS prompt before the DOS shell closes. Set NOXWAIT at the remote host to prevent SAS from displaying a dialog box on the remote host. Such a display requires that you explicitly type EXIT at the remote host and gives the appearance that the REMOTE SUBMIT command is hung.

This option is valid as part of a configuration file, at a SAS invocation, or in an OPTIONS statement.

See SAS Language Reference: Dictionary for details about this option.

Remote Host Example

In order to allow a local host to connect to a Windows remote host, a PC spawner program must be invoked from the remote host. The spawner program is invoked with the DECnet access method by using

\sas\connect\sasexe\spawner  -comamid decnet -file spawnsas.bat;

The SPAWNSAS.BAT file is used to set the configuration on the PC. The SPAWNSAS.BAT file content is

@echo off
sas -config config.sas %1 %2 %3 %4 %5 %6 %7 %8

The following example illustrates the configuration file entries for a Windows remote host:

-no$syntaxcheck
-noterminal
-noxwait

Chapter Contents
Previous
Next
Top of Page