SAS/CONNECT 9.2 Driver for Java

Connection Properties and Telnet Connection Information

The property values used by a SAS/CONNECT driver for Java program in connecting to a Telnet daemon (or the spawner) map directly to the Telnet connection information that is passed when manually establishing a remote SAS session via Telnet. This page describes the relationship between the prompt/response pairs you define as connection properties and the Telnet connection information that is passed when manually establishing a connection.

Note: In the case of SAS/CONNECT driver for Java applets, the connection property values are specified through the use of connection parameters in the applet HTML file.

Telnet Example

To better explain how the SAS/CONNECT driver for Java properties are used to start a remote SAS session via Telnet, let's look at what happens when this operation is done manually.

The user wants to run SAS/CONNECT on a remote host named myhost. Myhost has a Telnet daemon running and listening on a port. If the user telnets to myhost, the sequence of requests from myhost and responses from the user might look like the following:

Login: myuserid
Password: mypassword

There may be additional textual information sent from the
remote Telnet session indicating the user has logged on. 

Hostname> sas -dmr -noterminal -nosyntaxcheck

SAS(R) TCPIP REMOTE LINK PORT=1763          SESSION ESTABLISHED.

The Telnet daemon provides the prompt for the user to log in. In this example, the login prompt is "Login:". The user responds with "myuserid". The password prompt is "Password:" and the user response is "mypassword". The command prompt is "Hostname>", and the user response is the command to start the SAS/CONNECT session: sas -dmr -noterminal -nosyntaxcheck.

The SAS session responds with a message that states which port it will use for communication with the client, "PORT=", followed by the port number (in this case, port number 1763).

Mapping Connection Properties to Telnet Connection Information

Just as the user receives certain prompts from the Telnet session and responds to them, the connection client (specifically, TelnetConnectClient or TunneledConnectClient) behaves the same way. It waits for certain prompts from the Telnet or spawner session (or from the tunnel feature's server programs) and then responds.

The prompt/response pairs you need depends on the connection daemon you are using. You can create all the prompt and response properties required to pass the information that your connection daemon requires, using the following format:

promptx: Where x is any number, and the value corresponds to the prompt you want to pass.
responsex: Where x is any number, and the value corresponds to the connection information you want to pass.

It is important that you label prompt/response pairs in numerical order, without skipping any numbers. For example, if you create a prompt5/response5 pair, but you do not define a prompt4/response4 pair, the prompt5/response5 properties will be ignored and the connection will fail.

Note: All but one of the connection properties is created using this format. One property, sasPortTag, is hardcoded to specify the port tag.

Extending the example provided above, the following illustrates how to specify the required connection information using three prompt/response pairs. In this case, we are using use connection properties to meet the most common requirements:

The user name prompt is specified using the prompt1 property; the user name response is specified using the response1 property.
The password prompt is specified using the prompt2 property; the password response is specified using the response2 property.
The command prompt is specified using the prompt3 property; the command response is specified using the response3 property.

The prompt/response pairs needed for this example are as follows:

(prompt1, Login:): The connection client uses this value to determine when it should send the user name response.
Note: The prompt1 value is a substring that the connection client compares with the message from the Telnet session. It must be a unique substring. If the complete Telnet message is "Login:", the value "in:" would be a valid prompt1 value because it uniquely identifies the login prompt. Please note that ":" would not be a valid prompt1 value because it is not a unique identifier. The connection client would not know what information to prompt the user for, and the connection to the remote system would fail.
(response1, myuserid): The connection client will send this response after it has received the user name prompt from the Telnet session.
(prompt2, Password:): The connection client uses this value to determine when it should send the password response.
Note: The prompt2 value is a substring that the connection client compares with the message from the Telnet session. It must be a unique substring. If the complete Telnet message is "Password:", the value "word:" would be a valid prompt2 value, because it uniquely identifies the password prompt. Please note that ":" would not be a valid prompt2 value because it is not a unique identifier. The connection client would not know what information to prompt the user for, and the connection to the remote system would fail.
(response2, mypassword): The connection client will send this response after it has received the password prompt from the Telnet session.
(prompt3, Hostname>): The connection client uses this value to determine when it should send the command.
Note: The prompt3 value is a substring that the connection client compares with the message from the Telnet session. It must be a unique substring. If the complete Telnet message is "Hostname>", the value ">" would be a valid prompt3value because it uniquely identifies the command prompt.
(response3, sas -dmr -noterminal -nosyntaxcheck): This is the complete response to the command prompt.
(sasPortTag, PORT=): This uniquely identifies that the SAS session has completed initialization and allows the connection client to parse the port value from the message.
Note: The sasPortTag value must be the substring that immediately precedes the port value. While the substring "ESTABLISHED" uniquely identifies the message, it does not immediately precede the port number and the connection client will fail to establish a connection to the SAS session.

Top of Page