Find your services file and open it in a text editor, such as Notepad or Ultraedit (or you could even use the SAS program editor.) You do NOT want to use a word processing application like MS Word or WordPerfect. The services file is a simple text file and needs to remain so. You need to append the following line at the end of your file:
mcdcshr 8012/tcp #--SAS/Share server on mcdc2
The name mcdcshr is the handle that allows applications to associate this entry with requests to utilize the service. 8012 is a port number and tcp is a communications access method, two items that are required to complete access to the service. You don't really have to know how or why this works. The # indicates a comment and the characters that follow are just to help you remember what this entry is for.
You need to save the file with the new line added. Then you will need to reboot your machine to cause it to be read and processed by your operating system. You only have to this once, unless we decide to change the port or the name of the server.
If you want to access the server from a Unix system you need to add the same entry to the services file on the Unix box. This is much more likely to be something that you will need help with from your Unix system administrator. Users typically would not be authorized to modify the services file on a Unix system.
%let mcdc=mcdc2.missouri.edu;Now to point to this server you will use the name mcdc.mcdcshr . The part before the period references the machine (SAS knows to look for a macro variable and resolve it to get the IP address); the part after the period identifies the specific server running on that machine (platform). It is also used to locate the entry in your services file in order to get the port and tcp access method information.
To actually access data on the server you have to code a special form of the SAS libname statement. This form looks like the following example:
As with any libname statement the word following libname is called the libref. What this statement usually does is associate a path (directory) with this libref value. The usual syntax requires that the path be specified in quotes following the libref, but there is no such path specified here. The reason for this is that the way we have configured this specific mcdcshr service we do not allow nor require the path to be specified (some SAS Share servers do allow/require it). This server has been configured to work with a fairly long list of pre-defined libname/libref definitions. These librefs generally correspond to the subdirectories of the /pub/data public data directory. You can only use the service to access these pre-defined data libraries and you can only do this by using the predefined name.
libname pums2000 server=mcdc.mcdcshr sapw=<password-goes-here>;
For example, to access the 1990 Public Use MicroSample data stored in the pums90 subdirectory of /pub/data you have to use
libname pums90 server=mcdc.mcdcshr;
Why "pums90"? What not "pums1990", or simple "pums"? Because the libraries and librefs have already been pre-defined. "pums1990" was not defined. It turns out "pums" was, as an alias (or alternate) name for pums2000. So coding
libname pums server=mcdc.mcdcshr;
is similar to the same statement but using the pums2000 libref.
Note that we included a password parm in the first sample libname statement shown above, but note on the ones after that. It turns out that you only have to specify this password once per batch program or interactive SAS session. After that SAS remembers that you have passed that test and does not require you to specify the password again. So all you have to do is include a libname statement in your autoexec.sas file that has one of these libname statements specifying the sapw value. This not only takes care of giving you access to that directory but also means you never have to code the password on any other libname statement. Similary, you can code the %let statement that defines the value of mcdc as part of your autoexec, and then you won't have to worry about that either.
You can view the sas_shr_libs.sas file that is used to define all the available librefs/filetypes when using the mcdcshr server. We try to keep this list up to date, so that when new filetypes are added, a libname statement is added to that page. But sometimes there can be a short lag between when the new type is created and it gets defined on the server. Feel free to remind us to add the new entry if you find one that appears to be omitted.
(Remember, pums is defined as an alias, or alternate name, for pums2000). What if you wanted to see a list of the datasets within this directory? Just use the SAS Display Manager "dir" window. Type:
libname pums server=mcdc.mcdcshr;
and SAS will open a new DIR window and display the datasets. If you right-click on a file in the DIR window (sometimes you have to hold it down) you can then select the "View Columns" option. This will then open a window that gives you a nice Proc-Contents like description of the variables that comprise the dataset. If you prefer the direct method with a bit more typing you can skip the "dir pums" command and go directly to (i.e. enter the command)
which will result in the variable properties window opening with information about the moprecs5 dataset.
So what you have here is fast, convenient access to these data stored on a remote server (although how fact and how convenient can be a function of the speed of your Internet connection.) If it's a bit slow it can be very easy to create a quick sample of the remote file that you can then examine from your local machine. To get a local copy of the first 100 rows (observations) on the moprecs5 dataset, just sumbit this code:
Pretty simple. You can also copy the entire dataset over by omitting the "(obs=100)" spec, but then you have to have room on your local machine to store it. Since many of the datasets on the server can be quite large you need to be careful when doing this. A good strategy is to determine a subset of of rows and columns that you think you might want to use and just create a local copy of that extract. Something like:
data moprecs5; set pums.moprecs5(obs=100); run;
libname project 'c:\myprojects\pums2k'; data project.sample; set pums.mohrecs5(keep=puma hweight tenure .... /* choose variables here */ ); *---select rows/observations to keep using a where filter---; where puma in (...list of selected puma codes...) and tenure='1'; drop tenure; *--we had to keep it for use in the where filter but now we can drop it--; run;