SAS/SHARE User's Guide

SAS/CONNECT Programming Considerations

You can use SAS/SHARE with SAS/CONNECT to extend your access to SAS files and hardware resources. With SAS/CONNECT, a user who is running a SAS session on a local host (for example, UNIX or OS/2) can access files on one or more remote hosts, which can be any other operating system environment that supports a SAS session and SAS/SHARE.

The two major functions of SAS/CONNECT software are data transfer and remote processing. Data transfer enables a user to move data across hardware platforms as well as across releases of SAS software. Remote processing enables a user to send SAS statements to the remote SAS session for processing; all output and messages generated from that session are directed back to the local SAS session for display. However, remote processing has limitations. For example, you cannot perform interactive tasks, such as a PROC FSEDIT session, while using SAS/CONNECT.

You must use SAS/SHARE software with SAS/CONNECT software if SAS files that are used by the remote SAS session are accessed through a SAS/SHARE server. SAS/CONNECT software provides the connection between the hosts and the ability to run SAS statements in the remote environment; SAS/SHARE software allows concurrent use of the shared data.

The following example illustrates the necessity for SAS/SHARE in a SAS/CONNECT session. Say that Sasha uses the same data accessed by John and Maria in the example in Chapter 3. Sasha needs to create a report from DATALIB.FUEL. He typically uses SAS/CONNECT to establish the connection from his local workstation to the host system that clients John and Maria log onto directly, which is the host that the SAS/SHARE server runs on. Because the library that contains the data that he needs is accessed through a server, Sasha must also use SAS/SHARE to access that data from his remote SAS session. He connects to the remote host and uses the RSUBMIT command to remote-submit the following SAS statements to the remote SAS session:

options comamid=tcp;
%libdef(datalib);
proc print data=datalib.fuel;
   where area='TEX3' and profits<=0;
   title 'Losses in Texas, Area 3';
run;

In this example, Sasha uses the OPTIONS statement to re-set the communications access method to TCP/IP, which is used by the REMOTE engine to communicate with the server.

The LIBDEF macro generates a LIBNAME statement to access DATALIB through the same server that John and Maria use. Sasha's remote session connects to the server and then executes the PRINT procedure to produce his report. The report is displayed in his SAS session on the local workstation. Except for certain interactive limitations that are imposed by SAS/CONNECT, Sasha can remote-submit the same SAS program steps to read or write the data in DATALIB that other users use when logging onto the remote host directly.

CAUTION:: Do not remote-submit the SERVER procedure when using SAS/CONNECT software. Although the server runs in the remote session, the local session waits until the remote-submitted statements have been run, so that the local session is occupied until the server terminates.

As a further example of using SAS/CONNECT and SAS/SHARE together, consider Sasha's next project. He needs to update a set of production costs that are maintained in SQL/DS tables by another division. The SAS/ACCESS views for these SQL/DS tables are stored in a data library on a CMS host that is accessible through a server. These views enable Sasha and other users on the remote host to process the SQL/DS tables in their SAS sessions. Because the views are accessed through a server, users can create new SAS/ACCESS views while the existing views are in use.

Sasha remote-submits a LIBDEF macro to access the library that contains the SAS/ACCESS views for the SQL/DS tables. He then uses a MODIFY statement in a DATA step to update the PRODCOST view's underlying SQL/DS table. For more information about the MODIFY statement, see DATA Step Processing.

%libdef(sqldsvws);
data sqldsvws.prodcost;
   modify sqldsvws.prodcost;
   if part='0420' and units<=10 then
      do;
         if _iorc_=0 then remove;
         else put 'Could not remove cost record '
            recid;
      end;
run;

Note that Sasha is able to update the view's underlying SQL/DS table because the LIBNAME statement that is generated by the LIBDEF macro specifies NO as the value of the RMTVIEW= option. Setting RMTVIEW to NO causes the SAS/ACCESS view to be interpreted in Sasha's remote SAS session rather than in the server session. For more information about the RMTVIEW= option and interpreting views, see Interpreting SAS Data Views.

For more information about using SAS/CONNECT software, see the SAS/CONNECT User's Guide.

Chapter Contents
Previous
Next
Top of Page