I've just learned PROC FCMP from this page:
http://support.sas.com/documentation/cdl/en/proc/61895/HTML/default/viewer.htm#a003181727.htm
The function works fine locally, so I wonder if I can use this proc remotely. In my point of view, as long as I change the output library for this function, it could be used in remote server. Here's my code:
proc fcmp outlib=rwork.funcs.trial;
function study_day2(intervention_date, event_date);
n = event_date - intervention_date;
if n >= 0 then
n = n + 1;
return (n);
endsub;
options cmplib=rwork.funcs;
run;
rsubmit;
data _null_;
start = '15Feb2008'd;
today = '27Mar2008'd;
sd = study_day2(start, today);
put sd=;
run;
endrsubmit;
For the 1st section, I get a notice that the function has been saved in the RWORK library:
NOTE: Function study_day2 saved to rwork.funcs.trial.
However after running the 2nd section, I get this error:
ERROR 68-185: The function STUDY_DAY2 is unknown, or cannot be
accessed.
Is there a way to fix this issue? Thanks!
Assuming you want to program this way (compile the function on your local machine and run it remotely), and you have a machine connected over SAS/CONNECT that is the same operating system and bitness (64/32 bit) as your local machine, you need to run options cmplib=rwork.funcs; in your rsubmit (except you likely need to change it, assuming rwork refers to your remote work directory, to options cmplib=work.funcs;).
rsubmit;
options cmplib=work.funcs;
data _null_;
start = '15Feb2008'd;
today = '27Mar2008'd;
sd = study_day2(start, today);
put sd=;
run;
endrsubmit;
That option isn't for proc fcmp, as you seem to think based on where you located it. It is telling SAS where to look when using the function. (The outlib option in proc fcmp is what is needed to store it there.)
If your remote server is a different OS or bitness than your local machine, you can't do this, and would need to put the entire section of code in the rsubmit.
Related
I need to get the current running SAS program's name and file path into local variables. I accomplished that using the SAS_EXECFILEPATH and SAS_EXECFILEPATH commands. I ran this through windows SAS and it worked.
But when i tried to run this on the server in batch mode, it failed. I then tried the &_SASPROGRAMFILE parameter, which ran fine on SAS EG, but fails when I trigger it on the server in batch mode.
Is there a possible way to accomplish this in batch mode on the server?
You might be looking for %sysfunc(getoption(sysin)) (Usage Note 24301: How to retrieve the program name that is currently running in batch mode or interactively), if you start the program with sas -sysin path/to/file.sas.
I know this is delayed but you could generate a macro that calls on the right code depending on if you are running the program in the editor or in batch mode. Art Carpenter created a great macro that solves this issue.
%macro ExecPrg;
%if %sysfunc(getoption(sysin)) ne %str() %then %do;
/* Batch Execution */
%sysfunc(getoption(sysin))
%end;
%else %do;
/* Interactive Execution */
%sysget(SAS_EXECFILEPATH)
%end;
%mend execprg;
I was trying to inquiry data from TAQ, daily trade database. In SAS, I did the following but sas complained that, "Library does not exist." I am sure that the path is correct.
%let wrds = wrds.wharton.upenn.edu 4016;options comamid = TCP remote=WRDS;
signon username=_prompt_;
*************************************************************************;
libname ct'/wrds/nyse/sasdata/taqms/ct';
rsubmit;
The log said:
NOTE: Libname CT refers to the same physical library as TAQMSE.
WARNING: Library CT does not exist.
NOTE: Libref CT was successfully assigned as follows:
Engine: V9
Physical Name: C:\wrds\nyse\sasdata\taqms\ct
rsubmit;
NOTE: Remote submit to WRDS commencing.
But when I first login into the wrds server, I saw the path, and the first engine gives the path of the library which I wanted to use. What did I do wrong in order to set up the library?
NOTE: Libref TAQMSEC was successfully assigned as follows:
Levels: 5
Engine(1): V9
Physical Name(1): /wrds/nyse/sasdata/taqms/ct
Engine(2): V9
Physical Name(2): /wrds/nyse/sasdata/taqms/cq
It appears as though you are trying to reference a remote library in your local session. Try running the following AFTER the remote library has been assigned in the rsubmit; block (so, after the endrsubmit; statement):
libname CT (TAQMSEC) server=WRDS;
I am learning the RSUBMIT newly and I discovered that when I do a rsubmit with data statement, it doesnt take a local libray in the set statement?
How can we process this?
my code
signon server;
rsubmit;
data x;
set loca.mydata ;run;
endrsubmit;
this throws error saying
ERROR: Libref loca is not assigned.
should the set statement dataset also be present in the remote library?
When you rsubmit some code you're basically sending it off elsewhere to get processed meaning none of your local assignments are present on the remote server.
One way to use your "LOCA" library would be to reassign it once you've r-submitted the code:
signon server;
rsubmit;
libname LOCA "<path here>";
data x;
set loca.mydata; run;
endrsubmit;
A second method would be to share the library between the sessions using inheritlib:
signon server;
rsubmit inheritlib=(LOCA=R_LOCA);
data x;
set R_LOCA.mydata; run;
endrsubmit;
In the both cases you'll also need to retrieve your dataset "WORK.X" from the remote server. Both methods I've shown will also allow you to do this.
I have SAS code that reads my password from an external .txtfile and establishes connection with odbc . When i run the following code in SAS, it works fine
filename pw "C:/xxxx";
data _NULL_ ;
infile pw ;
input pw : $50. ;
call symputx('pwd',pwd);
run;
libname xxx odbc user=myUser password=&pwd. dsn=myDsn schema=mySchema;
proc sql;
connect to xxx(dsn=myDsn user=myUser password=&pwd.);
However when I create a batch file to run it from Windows task scheduler or run it from SAS Enterprise Guide I get Apparent symbolic reference PWD not resolved
Why is this happening ? How to deal with this issue ?
Because your call symputx is not correctly defining it, at least based on the code you pasted.
data _NULL_ ;
infile pw ;
input pw : $50. ;
call symputx('pwd',pw);
run;
That would be the correct syntax (or change the input statement to read pwd). Look at your datastep's log, it should have a warning pwd was uninitialized.
If you pasted the code properly, I would still look to your data step's log, and see if any rows were processed. mjsqu may be correct in that you may not have visibility to the directory (if this is on a server and you're not accessing a server-visible directory), or some other issue may present as a result of you being in a different environment.
You have a typo. My guess is that your original variable was named pwd and you tested your code and it ran fine and then you renamed it. If you close your sas session and try rerunning it I bet it fails.
Try changing to this:
filename pw "C:/xxxx";
data _NULL_ ;
infile pw ;
input pw : $50. ;
call symputx('pwd',pw);
run;
I am using AIX 6.1 with SAS 9.1.3
I have a program running in PC SAS 9.1
The program will rsubmit to unix.
Now, I convert the program to be totally running in AIX 6.1
The program fails very strangely.
After investigation, it is due to the %sysrput
Here is a simplified version of the program:
options mPrint mLogic symbolGen ;
%macro combine( startdate= , fullprefix= );
data _null_ ;
call symput( 'plength',compress(length(compress("&fullprefix."))));
run;
data _null_ ;
length balance 8. ;
balance= 1 + &plength.;
run;
%mEnd;
data _null_ ;
call symput( 'refdate', put(today(),date9.));
run;
%put &refdate.;
* -- If I forget to comment out the sysrput, the plength cannot be resolved -- ;
%sysrput refdate=&refdate.;
%put &refdate.;
%combine( startdate= "&refdate."d, fullprefix=a_filename_prefix );
(Sorry that the wordings are not meaningful, I just want to do a demo.)
Actually, in AIX, I should not use %sysrput
I just forget to comment it out.
But, if I forget this, there would be error in the plength macro variable in the balance= statement. This is very strange.
To solve, simply comment out the %sysrput is ok.
But, does anyone know why the %sysrput will cause failure in a macro variable in the macro ?
Alvin SIU
It's hard to tell from your simplified version of your question, but if you are asking why the macro variable plength is not present after your macro executes, it is because you must define it as global in your macro code itself. In other words:
%macro combine( startdate= , fullprefix= );
%global plength;
...
%mend;
And yes, if you use the %SYSRPUT command from a SAS session not under control of SAS/CONNECT, you will get a SAS ERROR; and getting a SAS error will put your non-interactive session into "syntax-check" mode, in which case the remaining statements in your program will not execute completely.
This last bit is a common misunderstanding when converting code from a SAS/CONNECT environment to "plain old SAS". When you use SAS/CONNECT, the "server" side of the connection is started with the "-NOSYNTAXCHECK" option.
After investigation with some little testing. maybe this is the answer.
Actually, I will use OPTIONS ERRORABEND in all batch SAS program to stop the SAS in case of error. This works for many errors and functions just perfectly.
The %SYSRPUT statement do give out error message saying ... options DMR ...
But the program does not abend stop here.
It does not give any message saying ... OBS=0 ...
It just go on.
So, I just 'think' that this is some minor error just like LIBNAME a non-exist directory and SAS will continue 'normally'.
(BTW, I think that the SYSRPUT error has turn on SYNTAX CHECK mode silently, without any notification nor hint.)
The next %PUT statement is normal, same value as previous one.
This mislead me that the program is running normally.
The next statements are also normal. There are many SYMBOLGEN, MPRINT and MLOGIC messages.
So, this further mislead me that the program is running very very normally.
After the call symput plength statement, there is a NOTE: Numeric values have been converted ...
This further mislead me the program is running normally.
Until now (after so many look-like normal messages), there is a NOTE saying SAS set option OBS=0 ...
(Maybe this NOTE will appear only after the RUN statement.)
This OBS=0 message is actually the hints which tell SAS is using SYNTAX CHECK mode.
Maybe this OBS=0 is caused by the SYSRPUT error. But, because there are so many look-like normal messages after the SYSRPUT error, I just overlook this OBS=0 message.
Actually, the call symput is so simply and should not cause any error.
This just further complicate the situation.
As SAS is in SYNTAX CHECK mode, this is why causing the look-like error in the plength variable in the balance statement.
This is the whole story.
Anyway, in order to prevent to enter into this complicated and misleading situation, just remember to comment out all the %SYSRPUT will do.