Configuring SPD Server on a Corporate Network

The example corporation maintains a network of computers. The corporate network contains a mix of computers and processing power: there are machines with multiple processors and large amounts of available disk space, smaller machines that are used for servers, and desktop machines for client users. Among the dedicated servers, we find

Because data for worldwide operations is stored in an SPD Server table on worldcpu, the Asia department periodically must access worldcpu. The Asia users want to extract worldcpu data to create SPD Server tables that will reside on their own departmental server, asiacpu. The Asia users can then access tables that contain only Asia data, and transfer that information to their desktops for further analysis.

The SPD Server system administrator runs the name server on the namecpu machine. Consequently, namecpu must be accessed by every machine in the network that wants to locate an SPD Server table. Additionally, the administrator must run a data server on the worldcpu and asiacpu machines. The following section discusses how the administrator should configure the servers in order to distribute the processing load.

Invoke the name server by using the -listenport option. The value that you specify for the option should be a valid TCP/IP port number. You will use the same port number when you invoke SPD Server on the worldcpu and asiacpu servers.

The libname.parm file that resides on the worldcpu server contains the following line:

LIBNAME=world pathname=/spds; 

This code instructs SPD Server to register the combination

(world, worldcpu, /spds) 

with the name server. Thereafter, when a SAS LIBNAME statement contains the domain name 'world' in combination with the appropriate name server, it will locate SPD Server tables in the directory /spds on the worldcpu server. The SAS LIBNAME statement that invokes the SPD Server engine and makes this association is

LIBNAME worldlib sasspds 'world' 
  server=namecpu.spdsname; 

When your network uses an SPD Server name server, the users do not have to remember which machine houses a particular domain. Users only need to remember that the SAS domain named 'world' contains the tables that they need. The machine that stores the domain can even change without the users' knowledge and the users' SAS programs will continue to run as before.

Invoke SPD Server, specifying namecpu as the value for the -nameserver option. The value for the "nameserverport" must match the port number that you used to start the name server on that machine.

The libname.parm file that resides on asiacpu contains the line of code:

LIBNAME=asia pathname=/spds; 

This line instructs the SPD Server running on asiacpu to register the combination

(asia, asiacpu, /spds) 

with the name server. When a SAS LIBNAME statement contains the domain name 'asia' in combination with the appropriate name server, it will locate SPD Server tables in the directory /spds on machine asiacpu. The SAS LIBNAME statement that invokes the SPD Server engine and makes this association is

LIBNAME asialib sasspds 'asia' 
  server=namecpu.spdsname; 

Note that the value that follows the LIBNAME server specification is the same in all these LIBNAME statements. The reason is that both SPD Servers use a common name service. Asia departmental users do not need to know the name of the machine that provides storage for their domain.

Assume a user in the Asia department needs to create an SPD Server table on the departmental server asiacpu. This task requires data to be extracted from an SPD Server table named alldata. The user knows that the alldata table resides in the domain 'world.' The user submits the following SAS code on a desktop SPD Server client:

 LIBNAME worldlib sasspds 'world' 
  server=namecpu.spdsname;
 LIBNAME asialib sasspds 'asia' 
  server=namecpu.spdsname;

 data asialib.mydata;
 set worldlib.alldata;
 where region='Asia';
 if country='Japan' then
     subreg=1;
 run; 

The submitted code extracts records from an SPD Server table named alldata that resides in the domain 'world.' The 'world' domain is stored on machine worldcpu in the directory /spds. Because the alldata table resides on worldcpu, and SPD Server processes certain SAS WHERE clauses, the search for the value 'Asia' is performed on worldcpu.

The SAS program runs on the Asia user's desktop machine. The desktop machine scans each row in the alldata table, looking for the string 'Japan'. If the string is found, the desktop client then forwards the row to the machine where the output table resides, which is asiacpu in this example.

Disk space for the output table mydata is allocated in the /spds directory on asiacpu. The processing work, transferring data received from the user's desktop machine to the SPD Server table, is performed by asiacpu as well.

The processing that was required to create the output SPD Server table was distributed across three machines. However, the user's desktop machine requires no permanent disk space, because SAS WHERE clauses execute on the machine that stores the source table. Only the selected rows that matched the submitted WHERE clause are sent over the network to the desktop client. This strategy significantly reduces network traffic, as well as the time that is needed to complete a SAS program.