NOTE: The APPEND & INSERT System Options

Did you spot the APPEND system option? And his compatriot INSERT? Both are extremely useful when you have a chain of configuration files. By default, the most recent specification of a system option (such as SASAUTOS) is the one that SAS will use. INSERT and APPEND allow you to add values to these options, either at the beginning (INSERT) or at the end (APPEND).

The full list of options to which INSERT and APPEND can be applied is: FMTSEARCH, HELPLOC, MAPS, MSG, SAMPLOC, SET, SASSCRIPT, SASAUTOS, or SASHELP.

So, for instance, if you have an installation-wide configuration file that specifies the standard SAS macro library concatenation, and you have an application-specific configuration file that needs to specify the application-specific macro library, you no longer need to repeat the standard SAS libraries in the app-specific config. Instead, you can just INSERT the app-specific library at the head of the concatenation and thereby de-couple your app-specific config file from the installation-wide config.

The SAS 9.2 Language Reference: Dictionary provides the low-down detail.

NOTE: SAS abbreviations

I'm familiar with little pop-up tips in many development environments for many languages. These tips spot that you're about to type a call to a function (for example) and show you the template syntax for the function. I didn't realise until recently that this was possible in SAS too.

I frequently struggle to remember the parameter order for the TRANWRD function - it seems counter-intuitive to me - but no longer because my abbreviation pops-up a prompt whenever I begin to type TRANWRD.

NOTE: SGF 2010 in Social Media: Archive

I got stuck whilst trawling though old tweets regarding this year's SAS Global Forum (SGF). I very quickly hit the following message from Twitter: Older tweets are temporarily unavailable. Repeated visits haven't resulted in a different outcome. But I have found a solution.

One of the last messages that's actually available revealed the solution: TwapperKeeper. It's a bit of a strange name but in essence it's an archive for tweets. So, if you visit http://www.twapperkeeper.com/hashtag/sgf10 you'll find an archive of SGF tweets. And you can create your own archives too. Looks useful. Give it a try and let me know...

NOTE: Stored Process Server vs Workspace Server - What's the difference?

A favourite interview question of mine is: Compare and contrast SAS 9's stored process server and workspace server. This question is very good at revealing whether candidates actually understand some of what's going on behind the scenes of SAS 9.

I ask this question of developers as well as administrators and architects. Whilst some developers don't need to know this behind-the-scenes information, the fact that a developer has an inquiring mind and has made the effort to find the information tells me something positive about that person. And, I'm not certain that developers don't need to know how their code is executed...

NOTE: SAS Editor Shortcuts (DMS only)

I stumbled across a very interesting paper the other day. Not only was it written (with others) by my old friend John (H) King but it spoke about something I've never explored before: customising the Display Manager (DMS). The paper is entitled "Automagically Copying and Pasting Variable Names" and was presented at Coders' Corner at this year's SAS Global Forum (SGF) in Seattle.

The paper describes two methods that use some less well known base SAS techniques that let you easily build tools to accomplish common tasks. One method lets users right-click on a file in a SAS explorer window and then select a task from a menu. The other lets you assign a key that, when pressed, gives you or your users a way to specify a one or two-level filename and then run a particular task on the file. Both methods give you an easy way to accomplish virtually any task, process or analysis.

Recommended reading!

Developer Testing

When I took over a "failing" development team in a high-profile banking project in London, I introduced a simple form for handing-over code from the development team to the system testing team. Apart from details such as why the change was being made and how the code should be transported from Dev to Test environments (and properly installed), the form included a tick-box to say that developer testing had been done (and fields to specify where the test code and test output was archived). Prior to this the developers had complained of being pressured to hand-over untested code in a management rush to get development work "completed".

I told the team that I wanted the form filled-in honestly and openly. I told them that if they had done no testing because they had been pressured into delivering before they had time to test it, they should write this fact on the form and must not tick the "tested" box. I told them they had my full support if anybody came back to them and complained about the quality of the code after they'd not tested it due to management pressure. Of course, I also told them I wanted to be told if they felt they were being pressured to skip testing. And finally, I told them that I expected them to include appropriate time for appropriate amounts of testing in any plans they put forward.