The SASIOLA libname engine is now delivered with most SAS software orders so that we can load LASR environments remotely from separate SAS environments. For example, maybe you have an existing SAS “ETL” machine that you use to access your source environments and load your target environments. With the SASIOLA libname engine, you can now use this machine to load your distributed LASR environment as well.
In addition to SASIOLA, another technology comes to mind when we talk about reading and writing between separate SAS environments, SAS/CONNECT. The natural question is, “Can I utilize SAS/CONNECT to load LASR from separate SAS environments?” Yes, you can.
Remote SAS datasets can be accessed via SAS/CONNECT Remote Library Services (RLS), but RLS is considered inefficient for large data especially when any transformation is required. A better approach is to utilize SAS/CONNECT’s Compute Services to transform the data and Data Transfer Services to move the data into LASR via the LASR SAS server machine. This is a particularly effective strategy with data that is too large for the LASR SAS server’s local disk (while small enough to fit when distributed across the entire LASR hardware array).
Below is an example using DI Studio. DI Studio’s ability to control SAS processing on multiple hosts (by generating SAS/CONNECT code) is actually one of my favorite features in the SAS stack of products.
As the picture shows, the final job only contains two transformations — one to perform the join on the remote SAS server and one to transfer the output of the join into LASR on the SAS VA Server.
To make this all work, both machines — the remote SAS server as well as the SAS VA server — need SAS/CONNECT installed, licensed and configured. Additionally, the SAS metadata environment that DI Studio is using needs to have both SAS machines (and their libraries and tables) registered in metadata. In the picture below, we can see such a metadata environment with a VA SAS machine named SASAppVA (sasserver01) and a remote SAS machine named SASAppEBI (sasserver05).
And if you don’t have DI Studio, the code is pretty easy to write too.
OPTION SET=GRIDINSTALLLOC="/opt/TKGrid";
OPTION SET=GRIDHOST="sasserver01";
libname lasr1 sasiola port=10010 tag='hps';
/* Connect to the remote server */
options comamid=TCP;
%let local = remotesassrv 7551;
data _null_;
signon local user=xxxxx password=XXXXXX
noscript;
run;
/* Transform the data on the remote server */
rsubmit local sysrputsync = yes ;
libname basedir "/sas94/data";
proc sql noprint;
create table Complete_Cars as
Select *
From basedir.Cars1 a
basedir.Cars2 b
on a.car_id = b.car_id;
Quit;
/* Transfer the data to LASR on the VA SAS Server */
proc download data=basedir.Complete_Cars
out=lasr1.Cars_LASR;
run;
endrsubmit;
Note that all transformation is done on the remote host, not the LASR SAS Server. Also note that the data loaded from the remote location straight into LASR. There is no staging on LASR SAS Server.
7 Comments
Would MP/Connect work too?
MP/Connect would work fine. Remember, however, that MP/Connect is just SAS/Connect running on a single machine. So, you can define multiple SAS/Connect servers on the same host and then have them pass data between themselves using the technique described above. However, all of the SAS sessions would be physically running on the same machine. So, a "remote" load wouldn't really be remote.
Very interesting article. We have a similar situation with a customer: Remote Server is an SPDS 4.52 over SAS 9.3 (O.S. Windows) and we need to load this data to LASR Server (SAS VA 6.4 over 9.4 - O.S. Linux). Both sides have SAS/Connect
Considering versions of software that customer has, it`s posible to apply procedure depicted in this article to solve the requirement?
Another Question: Our customer has two metadata servers, one for SPDS over 9.3 and other to SAS VA over 9.4, How can adapt your solution to this case?. Thanks in advance for your help!
If you want to use DI Studio, you'll have to define both SAS application servers (the 9.3 one and the 9.4 VA one) into one of the two metadata servers. I think it would be better to add the 9.3 application server to the 9.4 metadata server. Both the workspace server and the connect server would need to be defined. Then you'd have to get SAS/Connect working between the two. And from there, you would just build the job in DI Studio like it looks in the picture. If you just want to use code, then you just have to get SAS/CONNECT working between the two machines and use the code provided as a template. Good luck
Thanks a lot. I thought I saw an answer about first question; this disappeared?
No problem. I don't know why my first response disappeared. Here is what I said: I don't see any reason why it wouldn't work as written. VA 6.4 is compatible with SAS 9.4 while you're remote machine is 9.3 but the code is running from the VA SAS machine which has the newer 9.4 software which should have no trouble RSUBMIT-ing to and downloading from a SAS 9.3 machine.