I think you will need to adjust your axis statement to accomodate the outliers. You can do this dynamically by reading in the dataset before you run the GPLOT step, and finding the min and max value seen in the data.  Then pick a by value that makes sense, and write the min, max and by values  to macro variables to be used in your axis statement. HTH, --Q. ... View more

Hi, One of my pet peeves with GPLOT is that it happily excludes data that is outside of the axis range, with only a mere note that data have been excluded from the plot. So: data a;   input x y;   cards; 1 50 2 150 3 50 4 150 ; run; symbol i=join; axis1 order=(0 to 100 by 25); proc gplot data=a;   plot y*x/vaxis=axis1; run; Returns a straight horizontal line, with only the log notes to indicate something went wrog: line. 158  proc gplot data=a; 159    plot y*x/vaxis=axis1; 160  run; NOTE: 2 observation(s) outside the axis range for the y * x request. Seems odd to me that SAS will happily adjust title size, axis labels, etc, automatically, but won't adjust the axis range if you've defined one that is too small.  I don't know of a nice solution, other than to specify an axis range which includes all of your data. --Q. ... View more

Oh, I see what you are trying to do.  I don't think PC File Server can help you get the output report file back to the windows world.  As I understand it, PC File Server is a SAS/ACCESS engine that is useful when trying to read/write data.  I don't see how you could use it on an ODS statement to send your output destination file back to windows.  But if I'm wrong, someone will correct me.... -Q. ... View more

Hi, I'm confused as to what you are trying to do.  I don't think you should need to use the PC File Server.  I can submit below on linux, and it runs fine: ods tagsets.rtf file="~/test.rtf"; proc print data=sashelp.class; run; ods tagsets.rtf close; If you are using proc template to create a tagset, that should work fine to (as long as you create the tagset on linux). Can you explain a bit more, or give an example of the code you are trying to run? --Q. ... View more

Nice introduction to the benefits of user functions. Just a note that often the SAS macro language can provide similar functionality. So in this case, if your desired code was:   input(compress(put(datepart(<date/time field>),yymmdd10.),'-'),8.) Your macro could be: %macro makedate(field);   input(compress(put(datepart(&field),yymmdd10.),'-'),8.) %mend makedate; Used like: DATA _null_;        SET work.funcInput;        dateDimPK = %makedate(TRANSACTION_DTTM);        put ID= TRANSACTION_DTTM= datetime20. dateDimPK=; RUN; Not a criticism of your post.  Always more than one way to skin a cat. ... View more

It's protected by Copyright.  Ron's books are great, and well worth the price! http://www.amazon.com/SAS-Statistics-Example-Ron-Cody/dp/1607648008 or search conference proceedings, he is generous enough to write a lot of papers and shares them with the SAS community freely: http://www.lexjansen.com/ --Q. ... View more

Hi, The argument for CALL EXECUTE is a character expression. In SAS, when you want to build a character expression from text literals and variable values, you use the concatenation operator ( || ) or concatenation functions. So your first example fails for the same reason that the below fails: data _null_;   set sashelp.class;   a='%global zzz'name';';   put a=; run; And below succeeds: data _null_;   set sashelp.class;   a='%global zzz'||name||';';   put a=; run; Does that help? --Q. ... View more

My Apologies Andre, I completely misread your question.  And in a haze this morning mistook your question about AUTOEXEC, thinking it was about autocall libraries (SASAUTOS).  Sorry for the confusion. That is my punishment for reading SAS posts before being fully awake! --Q. ... View more

HI Andre, The auto exec option wants a FILEREF pointing to a directory of code,, not a libref. Odd but true. if you change to using a FILEREF, does that help? -Q. ... View more

Hi, Ask another SAS person in your group where your config file is saved.  I think on unix there is usuall a config file for the installation, and you can have a personal config file (in your home dir maybe)? I think (not sure) to turn off the the turn off the results window you can add this line to the config file:   -NOEXPLORER There is probably a way to close the output window by using the config file too, but I don't know it.  You can try adding the line below to your program (or to an autoexec.sas file, which will run every time sas starts): dm "output; winclose;"; Not sure why you would want to close the output window and the results window.  If you just wanted to edit code and submit it (in emacs or vi or whatever), you are free to do that, without having to use SAS's interactive programming environement. For more on config and autoexec files, search lexjansen.com for either term.  Will return lots of papers written by SAS users. Good luck.  Welcome to SAS. --Q. ... View more

Hi, I agree with Tom.  Recently I've been doing date-times with the b8601dt format, which returns yyyymmddThhmmss.  (e.g. 20120611T083038 for 8:30 am on June 11 2012. I'm still new to stored processes. I've been playing with using &_prorgram and &_Username in the name of the file as well, and dumping all my stored process logs in one folder.  One caveat is that I think &_username may be a generic value if user is not defined in metadata.  Also been thinking about having a standard put statement at the stop of every stored process to write key values to the log (e.g. all user-specified parameters, maybe even just all macro variables).  So that later can parse logs to looks for trends in how users invoke different stored processes.  Or maybe just append these values to a dataset every time a stored process is invoked.... filename logfile "/logs/%sysfunc(compress(%scan(&_program,-1,/)_&_UserName._%sysfunc(datetime(),b8601dt))).log"; proc printto log=logfile new; run; --Q. ... View more

Thanks much everyone. Lots to respond to. @Chris and @Cynthia, appreciate your weighing in that INSERT feels safe. Glad to hear it.  And appreciate Cynthia warning me against being bold enough to completely redefine sasautos.  Seems like better to respect the SAS admin. : ) @Tom re SASEvenvironment/SASMacro, Thanks for the hints as to where I should look for SASEnvironment/SASMacro.  You are correct, /SASEnvironment is a subdirectory of the current working directory.  Because we have the X statement enabled, It was easy for me to find the working directory with just "x PWD;" whch revealed the working directory for my session in the server is [SAS-config-dir]/Lev1/SASApp.  In there I see /SASEnvironment/SASFormats , /SASEnvironment/SASMacro , and /SASEnvironment/SASCode.  I think /SASFormats is for format catalogs defined on the server (see e.g. http://support.sas.com/kb/40/103.html, which describes how this directory gets added to fmtsearch in the default install), and /SASMacro is the default server autocall library (for admins to add macro definitions that should be available to every sever session).  In my case, both are empty.  It looks like /SASCode has code for scheduled DI jobs. So this helps me understand Cynthia's point: if one day my admin did start adding macro definitions, I would want to them to be available to my programs.  So completely redefining sasautos to exclude this directory would be a mistake. @Tom re whether best order for sasautos search is  (/project /corporate /SAS_supplied) or (/SAS_supplied /corporate /project), I'm a believer in the former.  When I was responsible for setting up an install a year or so ago, I looked to SAS-L for some advice on this.  I was convinced after a few emails that (/project /corporate /SAS_supplied) is the better option.  Main points being that if you use the (/SAS_supplied /corporate /project) approach, any time there are additions to either the SAS_supplied or corporate macro libraries, you risk breaking your user's programs if there is a collision in macro names.  People don't like when their programs work one day and not the next.  So I think it's better to give the user's code priority.  This puts more power in the hands of users, even allows them to redefine/hijack corporate standard macros if they want. Of course the name collision still can cause confusion (I look at the code for project X and assume the call to %MAC is the corporate standard %MAC, not knowing that it has been redefined), but at least the program works.  The thread is: http://listserv.uga.edu/cgi-bin/wa?A2=ind1101c&L=sas-l&D=0&O=A&P=36772 . Thanks again. --Q. ... View more

Actually just realized SAS recently made pre-pending easier without needing Peter's lovely macro.  You can put insert on the options statement.  This doesn't seem risky for BI, does it?   1 %put %sysfunc(getoption(sasautos)); SASAUTOS 2 options insert=(sasautos="c:\mymacros"); 3 %put %sysfunc(getoption(sasautos)); ('c:\mymacros' SASAUTOS) ... View more