Sunday, 6 August 2017

proc fcmp - file log put % bug

Having worked a lot with proc fcmp lately, I think it's fair to say that the procedure should be 'handled with care'

Here's an example of one of these weird / wonderful bugs (LIN X64, 9.04.01M3P062415):

proc fcmp outlib=work.funcs.pkg;
  function test(cval $);
    file log; put cval=;
    put 'also.. you can % see % this';
options cmplib=work.funcs;
data _null_;
  x="example %";


When you look at the log, the percent symbols are missing:

also.. you can see this

So this is strange, but it gets stranger.  If you don't have a clean session, you will also see parts of previous messages in the log.  For instance, if you now run the exact same above code again, you get:

cval=example % see % this
also.. you can see this

So the % symbols return, in a different place!   Now, whilst this is a strange bug, it only seems to affect messages sent to the log.  So not an issue right?

Wrong..  It seems that this can cause a fatal error:

ERROR: An exception has been encountered.
Please contact technical support and provide them with the following traceback information:
The SAS task name is [TKSRV ]
Segmentation Violation
Traceback of the Exception:
/pub/sas/SASFoundation/9.4/sasexe/sas(+0x15aa8e) [0x7f7163e73a8e]
/pub/sas/SASFoundation/9.4/sasexe/sas(+0x4cb0b) [0x7f7163d65b0b]
/pub/sas/SASFoundation/9.4/sasexe/ [0x7f71626873c4]
/lib64/ [0x7f71638ea370]
/pub/sas/SASFoundation/9.4/dbcs/sasexe/sasxkern(+0x7462e) [0x7f7151f4f62e]
/pub/sas/SASFoundation/9.4/dbcs/sasexe/sasxkern(ypslf+0xa2b) [0x7f7151f4eabb]
/pub/sas/SASFoundation/9.4/dbcs/sasexe/sasxkern(ypsllog+0x13c) [0x7f7151f51b9c]
/pub/sas/SASFoundation/9.4/sasexe/sastksrv(adjustline+0x59e) [0x7f714a60c1ce]
/pub/sas/SASFoundation/9.4/sasexe/sastksrv(sastksrv+0xec1) [0x7f714a60b531]
/pub/sas/SASFoundation/9.4/sasexe/sas(vvtentr+0x13d) [0x7f7163d656ad]
/lib64/ [0x7f71638e2dc5]
/lib64/ [0x7f7162ed476d]

Conclusion?  Don't send code to production that has proc fcmp writing character values to the log that may contain a % symbol!

Friday, 19 May 2017

Create / Compile / Run SCL in Enterprise Guide

The conundrum - I needed to run SCL on a windows machine without Base SAS (only EG) connecting to a Linux backend.

The obstacle - it is not possible to programmatically create an SCL catalog entry in batch mode.

The solution - read on!

Thankfully I did have access to a windows machine with Base SAS.  Taking inspiration from this post (thanks Robin) the steps were as below.  If you do not need to switch environments / operating systems, you can skip steps 2 and 3.

1 - Create an SCL Entry

Unfortunately, it is absolutely necessary to create an SCL file manually.  The good news is that you can do this just once, and write an entry that will simply %include any future SCL you send to it.  To create this file and corresponding catalog at the same time, use the build command:
This should open a window with the SCL entry.  Now add a single line of code (%inc fref;) and save the file.

What just happened?  We created an SCL entry in a catalog, which will run an %include statement from a fileref (fref) once compiled.

2 - Export the Catalog 

The catalog we created in step one (with one SCL entry and one line of code) now needs to be 'ported' to a transferrable format.  See CPORT:

PROC CPORT LIBRARY=sasuser FILE='C:\temp\trans.exp' memtype=catalog;
      select batchaf; 

The above file then needs to be manually (or otherwise) transferred to a location that the new environment can read from.

3 - Import the Catalog 

Can use EG for this!  In my case I also needed to remove the 'read only' attribute from the sasuser library.

libname sasuser "%sysfunc(pathname(sasuser))";
PROC CIMPORT LIBRARY=sasuser INFILE="/your/landing/area/trans.exp"

We now have our catalog available to use in the correct (binary) format.

4 - Run some SCL

The part we've been waiting for!  The steps here are to create our SCL (in fref), compile it and finally to run it (via proc display).

filename fref temp;
data _null_;
file fref;
input ;
put _infile_;
  put "excecuted " scrn= path=;
proc build batch c=sasuser.batchaf;
  compile select=builder.scl;

proc display c=sasuser.batchaf.builder.scl;run;

Of course this whole post is only relevant to you if you have SAS/AF installed on your server (check proc setinit for a ---SAS/AF entry).


Tuesday, 16 May 2017


The following came up when trying to launch sas on a recent Centos 7.3 install:

        MODULE: sasmotifsasvsub h.
                                   SUBSYSTEM: 8 SLOT: 11

/sas94/SASFoundation/9.4/sasexe/sas(+0x703ea) [0x7fb406fc43ea]
/sas94/SASFoundation/9.4/sasexe/sas(+0x70595) [0x7fb406fc4595]
/sas94/SASFoundation/9.4/sasexe/sasxfs(yustrt+0x265) [0x7fb3ea18c535]
/sas94/SASFoundation/9.4/sasexe/sasxfs(yuinit+0x1cb) [0x7fb3ea187a9b]
/sas94/SASFoundation/9.4/sasexe/sasxfs(yuropen+0x5ea) [0x7fb3ea18cfda]
/sas94/SASFoundation/9.4/dbcs/sasexe/saszu(xexprst+0x324) [0x7fb3e9756ea4]
/sas94/SASFoundation/9.4/sasexe/sas(vvtentr+0x13d) [0x7fb406fa06ad]
/lib64/ [0x7fb406b1ddc5]
/lib64/ [0x7fb40610f73d]

ERROR: Could not load /sas94/SASFoundation/9.4/dbcs/sasexe/sasmotif (38 images loaded)
ERROR: cannot open shared object file: No such file or directory

The clue was in the log, and the following command fixed it:

sudo yum install libpng12

Friday, 12 May 2017

SAS L is StiLL aLive

If you've ever done any moderate googling on a SAS topic you've probably unearthed a thread on SAS-L, quite possibly from several decades ago.  You'd be forgiven for assuming that this simply something that "used to exist' because - up until recently - that's exactly what I thought too.

Well - how wrong I was.  SAS-L is still alive and kicking.  The "L" stands for listserv, and is a mail server run by the University of Georgia.  It's basically a spamming service for SAS issues (am sure there is a better word for it though).

Getting started is as easy as 1,2,3:

1 - Sign up to the listserv service:
2 - Verify your email
3 - Subscribe to SAS-L  mailing list:

There is a ton of information on SAS-L on sasCommunity, and even a dedicated sugi paper.  So get involved - and you could be the next Rookie of the Year!

Thursday, 2 March 2017

Tabs v Spaces

Tabs or Spaces?  Does it even matter, so long as you / your team are consistent?  For many SAS developers the standard place to write code is the Program Editor - for which the default setting is to use tabs, else 4 spaces.

Interestingly - the generated code in Enterprise Guide and DI Studio uses 3 spaces.

My preference is 2 spaces, but what do you think is the most commonly used approach out there?

Uku Pattack has created a github page  which may settle (or inflame!) this classic Holy War.  It scans all github repos (over 1 star) for .sas files, and checks the tab vs space usage.  Here are the results:

So - which do you think was most popular?  The choices are:
  • 8 spaces
  • 4 spaces
  • 3 spaces
  • 2 spaces
  • Tabs
Head over to Uku's site to find out!