To solve this issue I usually encapsulate the step that uses the password inside of a macro. That way you can turn off SYMBOLGEN, MLOGIC, MPRINT, MACROGEN while you are expanding the password. You can store the passwords in a dataset or file and restrict access to the file using your operating system. Something like this: %macro oracle(passwordfile); %local userid password optstore; %let optstore = %sysfunc(getoption(symbolgen)) ; options nosymbolgen ; data _null_;    infile "&passwordfile" ;    input userid &$20. password &$20. ;    call symputx('user',userid);    call symputx('password',password); run; proc sql ;    connect to oracle (user="&user" password="&password" path="mydatabase"); options &optstore; %mend oracle; ... View more

We tried using this, but it does not really solve the problem. Anyone with access to SAS can use that "encrypted" password to access the database. ... View more

The example in the program is calling the symget function directly in the select statement of the SQL. Does not need to wrap it in a SYSFUNC call.  Did you try just removing the %SYSFUNC() wrapper around the SYMGET function calls so that it looks like in the paper you found? ... View more

data_null_ was asking what your actual application for this technique is. Perhaps if you explain what you want to be able to do that currently think could have been done by this technique someone can see another way to solve the actual problem. You can go right by make three left turns,  but usually it is easier to just turn right. ... View more

I do not think you can do that.  If your code did not include macro control statements it should work. How about creating a sub macro and then passing in the name of the submacro? %macro doloop; %do i=1 %to 3; data _null_;run; %end; %mend doloop; %let x=doloop; %macro mm; %&x ; %mend mm; options mprint; %mm; ... View more

Are you just talking about the TAGSORT option on PROC SORT? http://support.sas.com/documentation/cdl/en/proc/61895/HTML/default/viewer.htm#a000146878.htm ... View more

You do not need to use SYMGET.  Just reference the macro variable.  Replace: WHERE uid eq %sysfunc(symget('abc_username')) AND pwd eq %sysfunc(symget('abc_password')) with WHERE uid eq "&abc_username" AND pwd eq "&abc_password" Note the quotes so that the compiler will see that the terms on the right hand side of the EQ operator are strings and not variable names or constants. Symget is only useful when running in a data step and you want to get the current value for a macro variable that you might have updated since the data step was compiled by using a CALL SYMPUT statement. ... View more

I am not sure why people use PROC EXPORT to create text files. The data step is in many ways easier and more flexible. ... View more

Remove the quotes from around the name of the symbol.  When using %SYSFUNC() (and macro functions in general) you do not need to put quotes around strings. To the macro processor everything is a string. ... View more

So you do NOT have two date fields. The first dataset has a number like 19,400,420 that you want to interpret as the date 1940/04/20. To convert it use bthdate = input(put(pthdate,z8.),yymmdd8.); format bthdate yymmdd10.; Also I am confused about dataset two.  You say the format is MMDDYY10., but the dates you listed are have day before month. ... View more

Do you need the intermediate datasets with the numeric suffix? If not then why not just use a data step?  Why do you need a macro? data all_data;   set RF300l3.wacom_main;   where curve_id in (&Curve_id); run; ... View more

You just got some extra characters into your program. The error message is that it did not understand the PROC statement.  So of course it does not understand the other statements that only apply when running PROC EXPORT. ... View more

Look at this thread. http://bbs.cdisc.org/bbs/forums/thread-view.asp?tid=3473 ... View more