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';
    return;
  endsub;
quit;
options cmplib=work.funcs;
data _null_;
  x="example %";
  rc=test(x);

run;

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

cval=example
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/tkmk.so(bkt_signal_handler+0x144) [0x7f71626873c4]
/lib64/libpthread.so.0(+0xf370) [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/libpthread.so.0(+0x7dc5) [0x7f71638e2dc5]
/lib64/libc.so.6(clone+0x6d) [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; 
RUN;

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"
RUN;

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_;
cards4;
INIT:
  scrn=screenname();
  path=pathname('sashelp');
  put "excecuted " scrn= path=;
Return;
;;;;
run;
proc build batch c=sasuser.batchaf;
  compile select=builder.scl;
run;

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).

Enjoy..



Tuesday, 16 May 2017

SAS 9.4 on CENTOS - ERROR: BRIDGE FAILURE - ERROR LOADING IMAGE

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

ERROR:  BRIDGE FAILURE - ERROR LOADING IMAGE
        MODULE: sasmotifsasvsub h.
                                   SUBSYSTEM: 8 SLOT: 11


Traceback:  
/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/libpthread.so.0(+0x7dc5) [0x7fb406b1ddc5]
/lib64/libc.so.6(clone+0x6d) [0x7fb40610f73d]

ERROR: Could not load /sas94/SASFoundation/9.4/dbcs/sasexe/sasmotif (38 images loaded)
ERROR: libpng12.so.0: 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: https://listserv.uga.edu/cgi-bin/wa?GETPW1
2 - Verify your email
3 - Subscribe to SAS-L  mailing list: https://listserv.uga.edu/cgi-bin/wa?SUBED1=sas-l



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!  

Monday, 12 December 2016

Look out - Locale Gotcha

As gotcha's go, this was a good one!

We had a report being generated with dates that were inconsistent with the source file (MMDDYY instead of DDMMYY), but only for certain records.  This was definitely related to the ANYDTDTE. informat, but the strange thing was - this issue only occurred when the report was generated by the Stored Process Server (it was fine in batch).

The ANYDTDTE. informat is driven by the locale setting but as per the chain of sasv9.cfg files we had -LOCALE en_GB defined for both servers.  So I checked the logs, and found something interesting..

One of our STP applications can be triggered from either Excel or a browser.  I could see that the same user had triggered two requests, less than a minute apart, one from excel and one from a browser (as evidenced by the value of the _HTUA variable)

Yet one session had _USERLOCALE=en_US and the other had _USERLOCALE=en_GB!!

As it turns out, the locale for a Stored Process session can change according to the context of the client - as described in this usage note.

So the fix is simply to add the following code (as per your desired locale):
options locale=en_gb;
But where?

I tried fixing this via the autoexec, but this had no effect (likely because the server is running before the request arrives) so instead I added it to the stp init program - which worked a treat.


I recommend adding this to your init program, unless you really do want your outputs to change according to the locale setting of the client application!

Friday, 18 November 2016

Importing flow: ERROR - An error occurred trying to connect the responsible parties for the imported objects. Reason: Can't find resource for bundle java.util.PropertyResourceBundle, key ResponsiblePartyHandler.InvalidSearchAttrib.txt

If you are getting the following message when importing a package containing a FLOW:

ERROR - An error occurred trying to connect the responsible parties for the imported objects.  Reason: Can't find resource for bundle java.util.PropertyResourceBundle, key ResponsiblePartyHandler.InvalidSearchAttrib.txt

Then as per this usage note, and as I just verified locally, it is because the Responsibilities metadata is not imported.  So if you set your flow properties as follows:


You will see that after export / import the metadata is gone:


The metadata therefore has to be manually added back following the import.  In our case, we never use this field, and the ERROR has not caused any problems thus far (many '00s of flow deployments).  Still, if anyone has any tips for avoiding the ERROR do please advise!