BI Tools

Tips and tricks for building information maps, OLAP cubes, reports, and dashboards

BI Admin

Learn your way around a SAS BI installation.

Visual Analytics

Learn your way around the SAS Visual Analytics tool

Coding & Data

Extract, transform, and load your data into the SAS BI toolset

Stored Processes

Create and design stored processes like a rock star

Home » BI Admin, Coding & Data

SAS Coding: Scattered Data Might Need CPORT Procedure Help

Submitted by on 2013-12-15 – 5:52 PM 2 Comments

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?  Yeap … 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.]

sas environment setup

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?

sas cport procedure example

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.

sas cport example

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 = <libname>
  file =<fileref|'filename'> ;
run;

[Update 12-24-2013:  I noticed that SAS used the CPT file extension for these files.  I used DAT because it was an example. ]

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.

sas cimport procedure

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 = <libname>
  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 with CPORT/CIMPORT procedure?  Tell me in the Comments below.

Never miss a BI Notes post!

Click here for free subscription. Once you subscribe you'll be asked to confirm your subscription through your email account. You email address is kept private and you can unsubscribe anytime.
The following two tabs change content below.

Tricia Aanderud

Director of Data Visualization at Zencos Consulting
Tricia Aanderud is a SAS Business Intelligence and Visual Analytics consultant based in Raleigh, NC who works for Zencos Consulting. She has written several books about SAS, presented papers at many SAS conferences, and has been using SAS since 2001. Contact her for assistance with your next project.

Tags: , ,

2 Comments »

  • Tricia says:

    Jaap:

    Wow … you really do understand the challenges. I’m glad that the simple CPORT/CIMPORT worked for my issue. After I wrote the post, I read something about Proc Migrate. I was not aware of it so I am happy that you talked about it and your experience.

    I’m happy to know that others have seen the UTF-8/Latin1 issue! A customer I worked with last year had the issue. In a stored process the users were allowed to add cut and pasted content to the window. The users would write content in MS Word (to make use of the spell check ) and then paste it into the STP. Of course the STP didn’t know what to do with the encoded content. Lucky for me there was resident JavaScript expert who was able to correct it.

    Always appreciate your insight Jaap!

    Tricia

  • Jaap Karman says:

    Tricia,

    Nice to see you having the challenge I am mostly working on. It is underestimated to do it smart and easy in a way users do not have to think about it.

    CPort-Cimport has disadvantages. It can go back to V6 format.
    http://support.sas.com/documentation/cdl/en/movefile/63050/HTML/default/viewer.htm#p1xlqyolnjpoatn1npjh7wtbuv1i.htm
    With upgrading there is not problem wiht that you will find it in “proc migrate”.

    Noting “proc migrate” it also contains RLS as in some conversions it is needed. That is. With SAS/Connect (Share) can regress files to older versions transparently. Originally SAS/Connect was synonym to CEDA.

    It has segregated as you can store now for a different OS than you are running.
    http://support.sas.com/documentation/cdl/en/lrcon/65287/HTML/default/viewer.htm#n050121c5g0n2an1is3vohjstojx.htm

    Would be simple by having thatm but wait the next thing is encoding.
    You can run SAS a single-byte multi-byte latin-1 and UTF-8, former UTF-16 UTF-32 are different. Would you think datasets created by different encoding would be easily re-used. The last experience … (SAS 9.3) nada nada. Chaning between UTF_8 and Latin-1 even is blocking SAS/connect.
    Editing a SAS file in UTF-8 DBCS. It is adding a BOM-indicator to it as default.
    XML-file with a BOM indicator are not processed by the java-parts but are not giving any error-signal.

    Scattered Data ..
    Nice Header