Tag Archives: SAS

The Last NESUG

I attended NESUG 2013 in Burlington, VT earlier this week, along with some colleagues. One announcement at the end of opening session caught us off-guard – that NESUG 2013 was to be the last NESUG. NESUG 2014, which had been originally planned to take place in Philadephia, is now canceled, as are all other NESUG conferences going forward. The committee sent out a follow-up email to their opening session announcement in which they detailed the reasons for the announcement. SAS has been a major sponsor of the conference since its inception, contributing both funding support and a large number of displays and presenters to the conference. Apparently SAS notified the committee on August 29th that they have chosen to reduce funding for all the annual regional conferences, choosing instead to focus on industry-specific conferences such as PharmaSUG and more shorter, local events. Given this withdrawal of support, the committee determined that it could no longer hold the annual conference.

NESUG was the first of the regional conferences to be held this fall, so we are expecting news from some of the other regional conferences such as SESUG and WUSS later this fall as they decide whether they, too, will be unable to continue putting on their events. The regional conferences provided a cross-industry forum for users to gather locally and share programming techniques, discuss new procedures and SAS updates, and share their research projects with a tight-knit community. NESUG was a more intimate gathering than SAS Global Forum and for many first-time presenters, it was a smaller, less-intimidating conference, often within driving distance of home, at which to share their work. We will miss seeing the same faces year after year and are disappointed that SAS has decided to withdraw their support and seek another direction.

Updated: As of September 18th, the NESUG committee has posted more information on their site about their decision, along with some documents from SAS about their support of the regional conferences going forward.

SAS Withdraws Funding for Regional User Groups

At the opening session this week, the NESUG committee announced that NESUG 2013 would be the last NESUG. They sent a follow-up email the next day explaining the reasons behind this decision:

To the NESUG User Community:

On August 29, SAS informed us and the other regional user groups that they were significantly reducing funding support for annual regional conferences, including NESUG, beginning in 2014.

The NESUG Executive Committee met on September 3 to discuss this decision and to decide our response. We came to the conclusion that we, as volunteers, can no longer conduct a conference as successfully as we have for more than a quarter of a century. Therefore, the NESUG Executive Committee has voted unanimously to cancel all future conferences.

We want to thank our attendees, and especially the hundreds of volunteer presenters, session coordinators, registration desk volunteers, and others who so generously donated their time and talent to help the NESUG conference to set a standard of excellence for over a quarter of a century. We will miss you, but we encourage you to stay involved with the SAS community.

Regards,
NESUG Inc. “Of the user, by the user, for the user”

Daphne Ewing
Warren Stinson
Sue Douglass
Earl Westerlund
Lois Levin
Paul Gorrell
Lisa Eckler
Lisa Pyle
George Hurley

Creating AutoExec Code in SAS Enterprise Guide 4.3

For some users, metadata is already set up by their system administrator in Enterprise Guide so that libraries are automatically assigned; others are not so lucky. If you get tired of having to copy and paste or re-type your libname statement to manually connect to your libraries in Enterprise Guide all the time, you can create an “ad hoc” library in EG. This makes your life easier since every time you open EG, your ad hoc library is automatically assigned. You can also set system options, macros, or other code to run automatically every time you start the application.

To do this quickly and easily, follow these steps:

  • In SAS EG, go to the toolbar
  • Select Tools >> Options >> SAS Programs (left side of screen)
  • Click the check box for “Submit SAS code when server is connected”
  • Select “Edit” (same line as the check box above)
  • When the Edit box pops up, copy and paste the syntax below to automatically connect to your Oracle library (you must enter your own username, password, and schema):

    • libname mylib oracle user=xxxx orapw=xxxxx schema=xxxx path=pathname.com;
    options sastrace=’,,,d’ sastraceloc=saslog mprint symbolgen fullstimer;

    The next time you open EG, look for your “mylib” in the list of libraries on the left side of the EG screen. The above syntax sets up some system options that you may find useful, but you can modify to add additional libname statements, system options, and any other code that you want to run automatically on startup. See my previous post for more about some of these system options.

    Simple Random Sampling with Proc SurveySelect

    A common way to create a random sample of n=1000 in SAS is to generate a random number field for each observation using RANUNI or a similar function. The data set is then sorted on that field and the top 1000 selected as the sample.

    PROC SURVEYSELECT offers a simple alternative with just a few lines of code:

    proc surveyselect data=Customers
    method=srs n=1000 out=SampleSRS;
    run;

    The METHOD statement set equal to “srs” indicates that simple random sampling will be used. DATA= specifies the input data set, while OUT= specifies the output data set. N= is used to set the sample size, and an optional SEED= statement can be used if a particular seed is desired for generating the random number; otherwise the seed will default to the time of day from the computer clock. Default output will include the seed, selection probability, and sampling weight for each observation.

    Alternatively, if you want to get a little fancier and play around with various sample sizes for different markets, I like to use macro variables when setting some of the parameters:

    proc surveyselect data=work.total_elig_pop_&mkt
    method=srs n=&size out=ci_share.sample_&mkt._new;
    run;

    There are many other options available with PROC SURVEYSELECT which you can use for more complex sampling. Additional SAS survey procedures for analyzing data created using complex sampling methods are discussed in one of my conference papers. For more about macro variables and how they make your code easier to maintain, see 10 Steps to Easier SAS Code Maintenance.

    Granting SELECT Access to Your Tables

    If you have created a table in your own personal schema in an Oracle database, others do not have permissions to access that object. You may at some point wish to allow SELECT access to another user. To do this in SAS, you can use PROC DBLOAD as follows:

    proc dbload dbms=odbc;
    user=’yourusername‘;
    password=’password‘;
    dsn=database; /* this is the name of your ODBC Connection to the database. */
    sql grant select on yourschema.yourtablename to anotherusername;
    run;

    Or you can use explicit pass-through syntax to grant access:

    proc sql;
    connect to oracle (user=yourusername password=password);
    execute (grant select on yourusername.yourtablename
    to anotherusername) by oracle;
    disconnect from oracle;
    quit;

    Finally, you can do this directly in the Oracle database itself just by executing the following statement which is passed through in the syntax above:

    grant select on yourusername.yourtablename to anotherusername;