About Kurt_Bremser

Kurt_Bremser · ‎06-03-2014

First, you need to sort the dataset by ID and Date. Then you do data want (keep=ID first_date last_date first_value last_value); set have; by ID; retain first_date last_date first_value last_value counter; if first.ID then do; counter = 0; first_date = Date; first_value = Value; end; counter + 1; if last.ID and counter > 1 then do; last_date = Date; last_value = Value; output; end; run;

Kurt_Bremser · ‎06-03-2014

This works in AIX: sed -e's/oldttext/newtext/g' oldfile>newfile The command in the single quotes is what you would do manually in vi You can of course issue this command from inside SAS with the X statement or the SYSTEM() function or the CALL SYSTEM() routine.

Kurt_Bremser · ‎06-03-2014

Hi all. I want to set up server-side logging for (mainly) all the Enterprise Guide users, so we can check what actions are done, and which tables have been accessed at a certain time, and by whom. I have come to the point where a separate log file is written by every single SAS workspace server instance (coded with YYYYMMDDhhmmss in the filename). But in the default configuration, these logs only show what's happening during startup and shutdown, but not what the user actually does in EG. I now want to populate these log files with more or less the same logs that are shown in EG in the Log tab of the nodes in the project, without filling the files with unnecessary clutter. Has anybody done this already and can give me a quick "cookbook"? SAS version is 9.2 on AIX.

Kurt_Bremser · ‎06-03-2014

Come on, SAS as a streaming text editor? For all things, on a UNIX system??? Do you always hammer in your screws and try to eat soup with a fork? UNIX was designed as a text-handling tool. There is a host of text manipulation tools like, eg, awk.

Kurt_Bremser · ‎06-03-2014

Then you could use a macro variable to name the sheet like that: %let query_name=sasuser.check; proc export data = &query_name outfile = "C:\Documents\test\Alerts.xls" dbms = excel replace; sheet = "&query_name"; run; or %let libraryname=sasuser; %let query_name=check; proc export data = &libraryname..&query_name outfile = "C:\Documents\test\Alerts.xls" dbms = excel replace; sheet = "&query_name"; run;

Kurt_Bremser · ‎06-03-2014

What is the "query name"?

Kurt_Bremser · ‎06-03-2014

When the "warnings" do not change the value of &SYSCC (and SAS technical support can't come up with a better solution), then some method that checks the log will be necessary. You could run each model in a different batch job, producing individual logs, and check these with tools like grep Or you could wrap it all in a single program, use PROC PRINTTO in each iteration to let each step write into a separate external file, and check this log with a DATA step.

Kurt_Bremser · ‎06-02-2014

Do not write a semicolon after the macro invocation. That semicolon breaks your if condition because it is not part of the macro invocation but part of the "normal" program code. if %anotherloop(start=0,stop=1) opendate_2 < actual_inception_date;

Kurt_Bremser · ‎06-02-2014

With a macro: data mydataset; merge %macro datasets; %do i = 1 %to 27; step&i %end; %mend; %datasets ; by myvar; run; But you don't need that, as others already said, the set1-set27 solution works at least in 9.2.

Kurt_Bremser · ‎06-02-2014

You can either: - use proc format to specify a custom label for all the values you intend to cover - generate a lookup table with the labels and join your dataset with it - use the same lookup table as input for a hash object and use that in the data step

Kurt_Bremser · ‎06-02-2014

The data step variables are set to missing only when the complete data step enters its next iteration (think of the jump from "run" to "data"). Between "data" and "run" (or whatever begins the next SAS program step) the variables keep their values, no matter how many SET or OUTPUT statements you have.

Kurt_Bremser · ‎06-02-2014

You can check for the state of the %syscc macro variable after each iteration and set it to zero at the start of the next.

Kurt_Bremser · ‎06-02-2014

I would recommend to combine that with a migration in the SAS release. That way you can set up a completely new server in the VM, do the install from scratch and set up your whole infrastructure and test it without any interruption in the production environment. Once the new installation works satisfactorily, you "only" need to roll out the new EG and reroute the web applications to the new server. When SAS was only Base SAS, the backup-restore option worked perfectly, but today the whole system has gotten so complex that that fails almost every time. Also keep in mind that creating a new setup lets you fix logical errors (or bad naming conventions) that you made in the previous version

Kurt_Bremser · ‎06-02-2014

If your SAS system runs on UNIX, the diff command will be your friend.

Kurt_Bremser · ‎05-28-2014

To overwrite all the files that constitute the MDDB, the load process needs exclusive access. When the OLAP server serves a report from that table, it prevents that exclusive access. One solution is to stop the OLAP server for the time that is needed to update the MDDB's.

Online Status	Offline
Date Last Visited	12 hours ago