AFHood Analytics Group – Blogs

Have you ever wanted to know when your code completes? Or maybe you want to automate the report to include sending an email?

Regardless, SAS is happy to send that email for you. The easiest way to do this is through the SMTP access method via filename statements.

Example:

filename sendemail email ‘toaddress@email.com’ subject=’This is a test email.’ from=’fromaddress@email.com’;

data _null_;

file sendemail;

put ‘Hi,’;

put ‘This is a email sent from SAS’;

run;

This is only a simple example. Here is another with an attachment.

filename sendemail email ‘toaddress@email.com’ subject=’This is a test email.’ from=’fromaddress@email.com’ attach=’/somesascode.sas’;

data _null_;

file sendemail;

put ‘Hi,’;

put ‘This is a email sent from SAS’;

run;

Email attributes can also be set in the data step through the EM_ directives.

filename sendemail email ‘toaddress@email.com’ ;

data _null_;

set somedataset;

put ‘!EM_TO! ‘ email_addr;

put ‘!EM_SUBJECT! ‘ subscription_name;

put name ‘ ,’;

put ‘This message was generated by a SAS data set’;

put ‘!EM_SEND!’;

run;

There are times when we find ourselves needing to move many datasets within a library to another location. One of many ways to do this is with the Proc Copy procedure.

The elements of a Proc Copy procedure are as follows:

proc copy in=source_library out=target_library memtype=all;

select dataset1 dataset2 dataset3;

run;

The memtype option allows you to specify what kind of member you want to move. This is optional and if you leave it off, SAS will default to ALL. Here are you available choices for this option.

ACCESS – access descriptor files (created by SAS/ACCESS software)

ALL – all member types

CATALOG – SAS catalogs

DATA – SAS data sets

FDB – financial database

MDDB – multidimensional database

PROGRAM – stored compiled SAS programs

VIEW – SAS data views

Additionally, the select statement can be left off as well. Doing so will select all datasets that meet the memtype requirements. It might be worth noting that all datasets copied will have a timestamp equal to the runtime of the procedure not equal to the source dataset.

If you have data management challenges, give us a call. We will help you design a solution that meets your needs.

This is a great practice that we picked up from the guys over on SAS-L. It is a way to create temporary variables in datasteps that are dropped before being written to the output dataset.

data output_dataset (drop=_:);

set input_dataset;

_temp_var = <some code here>;

new_variable = <some more code here.. probably something to do with the _temp_var>;

run;

The variables beginning with the underscore (“_”) will be dropped before being written to the output dataset. It doesn’t matter if there is one temp variable or 1000. As long as they begin with an underscore, they will not make it to the output dataset.

If you use this drop statement without creating any temporary variables you will get a warning.

Here is one for your collection. This one is a little out of the “basics” realm and into the wierd and unusual.

Let me begin by explaining what this is and what you may use it for. First, this is SAS’s ability to write to a file and then execute that file in SAS or on the command line. For my examples, I will be using SAS on Unix. So we tell SAS to output to a file and then give the commands to execute that file.

So, you might ask, why would I use this? Well, my most recent real world example is a nightly refresh of a very large reporting structure. The architecture is as follows. There are a large number of standard reports/tablse that need to be refreshed. I have a SAS project that retrieves the most recent list of refreshes and builds a shell script for each. The code then executes the scripts 10 at a time until all are done. Each script it builds checks the load on the database to ensure we aren’t killing it and that we can get a connection for the next round of reports. As the reports complete, we kick off the next round until all are refreshed. This allows the process to “spawn” processes and manage them in a way that is reasonable to the enterprise and database.

So, lets begin by talking about how you create a shell script in SAS. To do this, we will use a dataset in the following syntax:

data _null_;

file test_file.sh;

put “projects=( &proj_list )” ;

put “DATE=/usr/bin/date” ;

put “for num in ${projects[@]}” ;

put “do” ;

put ‘echo “working on project number $num – `$DATE`” ‘ ;

put “done” ;

put ‘echo “all work done!” ‘ ;

run;

After we have successfully created the file, we can now kick it off to run. On a side note, I like to add the output of the file to the current log.

filename kickoff pipe “. /test_file.sh &”;

data _null_;

infile kickoff;

input;

put _infile_;

run;

The leading “.” on the filename command tells Unix to execute the script regardless of its permissions. The “&” after the filename tells Unix to execute the command outside of this session or screen.

I hope this overly simplistic example is helpful. You can only imagine how complex this can get very quickly. It has been our experience that many organizations are exploiting this to build production systems with SAS. This functionality separates the SAS experts from the “analysts”. Using this functionality makes in extremely important to document your code. As you begin to add variables and “include” statements, things get fuzzy very quickly.

If you have a code base that utilizes this functionality and you need assistance, please don’t hesitate to let us know. We are ready to help support your organization.