SAS Coding: Scattered Data Might Need CPORT Procedure Help

My computer is a hot mess! I have datasets and code everywhere. I’m serious … you name it … there is not a hard drive, thumb drive, and even a DVD in my office that doesn’t have data on it. I call it Scattered Data Syndrome and I had to do something before I kicked a stray dataset across the room and broke the printer.

Who knew this seemingly simple task would be related to PROC DATASET not working. Gasp? What? Yep … cross environment data access (CEDA) issues are all I got for Christmas, kids!

It’s Scattered Data Syndrome

Forget about big data issues – I had scattered data issues. It’s a syndrome common to those who created everything on the fly with no thought of reuse. After several years of creating examples for blogs, user conference papers, and customers – I realized that my computers were a minefield of SAS code, SAS datasets, Enterprise Guide projects, and what have you. People would ask for examples that I knew I had created before, but could not locate. Thus I would recreate the example, which was basically a waste of time.

Lady, What You Need is a File Server

I have multiple SAS environments available for demo purposes. This blog is a good example of demos that I create. To keep multiple environments going, my IT department (aka husband Ken) has set up several virtual environments that run various environments for quick access.

After hearing all my scattered data drama, Ken decided I needed a central storage location and he created a file server. All of the environments can reach it. As I create new demos, I decide if I want to add the data through a metadata library. Not all of these environments are needed, for instance, I also have a SAS 9.2 (not shown) that I if I need to test how something worked before.

This drawing shows the final environment along with how it is backed-up to an external hard drive and Sugar Sync. I backup code but not data – mainly due to the file size. Plus most of it is sample data that I can recreate or access from elsewhere. In SAS 9.3+, the metadata is backed up with automagically. [Here’s another clever way.]

Oh, Why Can’t Windows Fit My Budget?

I like Windows but Ken prefers the Linux Red Hat-based CentOS 64 system. After discussing purchasing yet another Windows license – it seemed smarter to continue with Linux. Unknown to me … this is where the topic of this blog post actually started.

Oh the Horror! Session Encoding Does Not Match

I was really pleased to learn the SAS Global Forum 2014 accepted by paper about SAS Add-In for Microsoft Office (AMO). The paper covers 7 different examples of how to get more value out of AMO. It is a lot work to put together that many examples, so of course I wanted to reuse older examples. BGKPI was a dataset I had moved from my Windows-based system to the Linux-base file server.

All I really needed to do was rename the variables so it would be more clear how I was using it in the example. But look what happened when I tried to use the Datasets procedure to do it. Curses! – ”Cannot be updated because encoding does not match session encoding!” Ugh .. what does that even mean?

In the prior step I had used PROC CONTENTS to review the dataset and SAS issued a note that it has identified a dataset native to another operating system. SAS lets me know it used the Cross Environment Data Access (which require more resources) to handle the dataset. [More about cross environment data access and its limitations.]

This is no issue if I want to view the data or even use it in a data step. Since I was not able to use the datasets procedure on the data set – it was a disaster. Considering the other 100 datasets were also Windows-based – seems like I needed a better solution.

Solving the Issue with the CPORT Procedure

How do you change a dataset format? Well you just need the handy-dandy CPORT procedure. It is similar to how zipping a file with WinZip works. WinZip compresses files and places them in a ZIP file. The ZIP file can then be transported to another system where the user can unzip the files into a new directory. However, CPORT converts the data for the operating system where it is being extracted – very nice.

Using the CPORT Procedure

In the following figure, I used the CPORT procedure to combine the files in the MY_LIB library into an output file called Z_DATA2MOVE.DAT file. You can see the resulting file was placed alongside the other datasets.

Here’s the basic code you need. In the above figure, notice that I included the LIBNAME and FILENAME statements to be more clear about what I was doing. If you have a metadata library or a BASE library it works either way.

 proc cport   lib =   file =<fileref|'filename'> ; run;

There are other options available to CPORT, such as limiting the compression or only selecting a single file. You can explore those topics on your own. [ More about the CPORT procedure.]

Using the CIMPORT Procedure

Now, I need to get the data into its new location, which only required a CIMPORT procedure. It is basically the same code with just a slightly different procedure name: CIMPORT.

Here’s the code for reference. Notice that in the figure above that I used a meta data library but I had to turn on the METAOUT option. Also notice that I placed the incoming file in a different location where I had manually moved it using FTP.

 proc cimport   lib =   file =<fileref|'filename'> ; run;

There are other options available with CIMPORT that you can learn about here. Here’s another write-up about transporting SAS libraries from University of Massachusetts.

Now for My Next Task

I can imagine other uses for CPORT/CIMPORT, such as sharing files with others or just having a way to compress files for storage. But now I need to get busy with a SGF paper!

What ideas do you have or have you used? Tell me in the Comments below.