See the documentation for the RENAME dataset option. ... View more

The documentation for PROC REG says VAR lists variables for which crossproducts are to be computed, variables that can be interactively added to the model, or variables to be used in scatter plots. So you probably need a VAR statement here (as the ERROR message suggests BTW.) As an aside: why can't these error messages say which variable? Should be pretty much known ... ... View more

Doc's RCMD suggestion is worth following. Try to pass both STATUS and LOCSTAT commands to the FTP process in order to have both the server and client settings displayed. (At least that's what I would try next. Not having used SAS's FTP access method I don't know whether you will get the messages though.) ... View more

As I see it (can't test unfortunately) your macro generates the rename statements with semicolons between the elements, i.e. it syntactically terminates the rename statement after the first rename pair. Remember to be careful with semicolons in macro generated statements, especially in macro generated statement parts. ... View more

Additionally the WHERE statement can be augmented ( by using WHERE ALSO). A technique that is sometimes (or for some people) easier to read/understand than complex AND constructs. Sample code snippet: [pre] where age gt 12 and age lt 15 ; where also weight gt 60 and weight lt 80 ; [/pre] ... View more

This seems to indicate that ReportTime is a character variable in your dataset, while your first attempts compared that to a SAS datetime and so to a numeric value. (I say "seems" as I can't test/verify for the time being) ... View more

Paige is right. And if - for some reason you didn't specify - the original observation order needs to be preserved then add some kind of observation number up front, then proceed as Paige suggested and finally sort the remaining observations back. ... View more

O.k., I guess I see. You have a mixture of input styles in your input statement. The first part ("input projid") is referred to as "list input", a technique where you just name the variables without assigning an explicit informat. The other part "input ... startdate date9. enddate date9." is referred to as "formatted input". As SAS processes the input statement it moves it's internal column pointer ahead. With formatted input the column pointer points to the column right after the (in)formatted value. In your case that means "enddate" begins with the blank separating your date values. This makes enddate having an invalid value. Possible solutions: a) manually move the column pointer by one column [pre] input projid startdate date9. +1 enddate date9. ; [/pre] b) search for and read the sections on the "colon modifier" in the input statement documentation [pre] input projid startdate : date9. enddate : date9. ; [/pre] Quote from 9.1.3 documentation: For a numeric variable, this format modifier reads the value from the next non-blank column until the pointer reaches the next blank column or the end of the data line, whichever comes first. ... View more

When referring to a "log Error" it would be most helpful to post the relevant log parts as well. (Just from a quick glance I can't see anything wrong with your code. Only thing I would change: move the options statement ahead of the data step). ... View more

If by 'specific' you mean that you exactly know the option's name then I prefer things like [pre] %* display selected options on log ; %put %sysfunc(getoption(linesize,keyword)) ; %put %sysfunc(getoption(pagesize,keyword)) ; [/pre] If you change these options within a SAS session (be it foreground or background) temporarily, good practice is to do it somewhat like [pre] %let _ls = %sysfunc(getoption(linesize,keyword)) ; %let _ps = %sysfunc(getoption(pagesize,keyword)) ; options linesize=200 pagesize=100 ; /* hypothetic values */ %* do some SAS things here ; options &_ls &_ps ; [/pre] Alternatively you could use procedures OPTSAVE and OPTLOAD to front-end temporary modifications. ... View more

Thanks Tommy, so you have a SUN 64 system, 4 CPUs, running SAS 9.2. Coming from the mainframe side I can only say that the SORTSIZE value seems rather low to me. Do not these SUN systems have an overwhelming amount of memory available? If 83886080 actually means somewhat around 80MB then I think that value is extremely low causing SORT to do some heavy disk I/O. But then, I'm a mainframer, so we better wait for the operating system specific experts to wake up and get in front of their keyboards. ... View more

... but the work with the resulting datasets which are much smaller but take longer to process. "The work with the resulting dataset" this is where we need more information. What does that mean? Your macro logic does create SAS code consisting of data steps and procedure invocations most certainly. Seeing the created code and seeing the SAS NOTE messages along with resource consumption related informations such as those that get reported when options like FULLSTIMER (it has some newer name but AFAIK it still works) are active would help us and ultimately you a big lot more. So please set options SOURCE SOURCE2 NOTES FULLSTIMER and repost the log parts that relate to "the work with the resulting datasets". Kind regards Robert ... View more

As there are operating systems that allow for quite some SORT tweaking please post what operating system you are using and also what version of SAS you are using. And also how many CPUs you have available and whether option THREADS is active or not. Please post the result of [pre] %put OS &sysscp &sysscpl ; %put SAS &sysver ; %put CPUs &sysncpu ; %put THREADS: &sysfunc(getoption(threads)) ; proc options group=sort; run; [/pre] ... View more

Holger's code snippet is constantly being truncated, so most of it can only be seen by using the "Quote Original" button when composing a reply. (Hint: there's a connect to oracle involved). @holgerfb: suggest you read http://support.sas.com/forums/thread.jspa?messageID=27609毙 and repost your code snippet in a more readable way. Do use the Preview window. ... View more

You could solve this programmatically by a) putting DATA1 into a hash with TIME as key b) iterate over DATA2 using both time values to find the relevant hash elements and doing the mean calculation Others having SAS at their hands might chime in with some ready-to-use code. (Note that this solution largely depends on the size of DATA1. If it is a very big dataset consider defining/using DATA1 as a dataset indexed on TIME). ... View more