Macro variable not resolved - ONLY in scheduled jobs. Works fine when manually run.

[sc5]

Hi!

There's this bit of code in a few report scripts that works perfectly fine when run manually, but crashes every other month when run as part of an automated scheduled job. 

This job calls multiple scripts sequentially one after another and this bit of code exists in each of those scripts. The first script works fine in the automated run, but all other scripts that follow fail. But again, running them all sequentially manually works. 

data _null_; 

mth_start = intnx('month',today(),-1,'B');

mth_end = intnx('month',today(),-1,'E');

call symput('mth_s', put(mth_start,date9.));

call symput('mth_e', put(mth_end,date9.));

run;

%put &mth_s;

%put &mth_e;

In the logs it says WARNING: Apparent symbolic reference MTH_S not resolved. 

And then when the macro variables are called later on in Proc SQL WHERE clauses, the scripts just fail. 

Any advice on how I can fix this?

EDIT:

Every script has that piece of code in it. 

So the main script is like 

%include "mydir/report_1.sas";

%include "mydir/report_2.sas";

%include "mydir/report_3.sas";

and each of those scripts has the code snippet in them. 

Thank you!

[SASKiwi]

My guess is that each of your scripts is run in its own SAS session hence it won't know about macro variables created in the first script / SAS session. Running the scripts in one SAS session would solve the problem. However since you haven't provided any details regarding how your scheduled job is structured, it is a bit hard to offer further guidance.

[sc5]

Thanks for replying!

Every script has that piece of code in it. 

So the main script is like 

%include "mydir/report_1.sas";

%include "mydir/report_2.sas";

%include "mydir/report_3.sas";

and each of those scripts has the code snippet in them. 

[SASKiwi]

We would need to see a snippet of the SAS log from the scheduled job from the start until the macro error to understand what is happening.

[Tom]

---

@sc5 wrote:

Thanks for replying!

Every script has that piece of code in it. 

So the main script is like 

%include "mydir/report_1.sas";

%include "mydir/report_2.sas";

%include "mydir/report_3.sas";

and each of those scripts has the code snippet in them. 

---

Is "mydir" a fully qualified path?  For example if SAS is running on Unix does it start with / ?

Does the path mentioned exist on the machine where SAS is running?

Does the user that is being used to run the job have permission to read the SAS programs?

[sc5]

Yup, all of that is fine. 

I didn't want to include company name info, but it's basically in the format

%include "d:\mydir1\mydir2\report_1.sas";

It's a windows server. 

there's absolutely no issue with the path names. It successfully calls these scripts and starts running them, we have hundreds of jobs that run successfully in the same format, etc. 

The issue is *after* these scripts are called, in the middle of each script's execution, *only* with macro variables not resolving, and *only* when run as part of the scheduled run. 

Thank you for replying!:)

[Tom]

Did you review the full logs of the entire SAS session to find the FIRST error?

Did you try setting the SOURCE2 option (or add the /SOURCE2 option to the %INCLUDE statement) so that you can see the statements that are being executed?

Another thing to double check is the lengths of the lines in those %INCLUDE files.  I have seen situations where long lines are truncated.

Another thing to double check is if the files have physical tab characters in them.  When you submit SAS code from the Program Editor window in SAS Display Manager the tabs are automatically converted into spaces for you.  But when you use %INCLUDE to read the files that does not happen. So the program might execute differently.

[Tom]

Note that the %INCLUDE command also supports the IgnoreDosEof option.

IGNOREDOSEOF

is used in the context of I/O operations on variable record format files. When this option is specified, any occurrence of ^Z is interpreted as character data and not as an end-of-file marker.

[Tom]

Note that you can do the same thing without the data step. 

%let mth_s = %sysfunc(intnx(month,%sysfunc(today()),-1,B),date9.);
%let mth_e = %sysfunc(intnx(month,%sysfunc(today()),-1,E),date9.);

[Kurt_Bremser]

When you say it crashes every other month, then you need to look there. Something that goes active only in odd or even months.

[Quentin]

Can you post the log (at least the log snippet for the code shown)?  Your program has that DATA step, followed immediately by the two %PUT statements?

I would look for an error in the log prior to this point.  When scheduled jobs run, SAS will (by default) enter syntax check mode when an error occurs.  If an error occurred earlier in the session, and SAS entered syntax check mode, then the DATA step would not execute, so the macro variables would not be created.  But I believe the %PUT statements would still execute.

The code you showed is fine, so the problem must be somewhere else.

[Patrick]

In case the data step you shared is within a macro, the macro variables created could be in local scope.  If that's the issue then try with below amendments.

[sc5]

I'll try this, thank you! 🙂

The data step is within a macro, but the macro variables created are also being used within the same macro function and failing to resolve.

[SASKiwi]

BTW, if there is a prior error in your program, your DATA step creating the macro variables won't execute, so your macro variables wont be created. You might want to check that possibility.