BookmarkSubscribeRSS Feed
sc5
Obsidian | Level 7 sc5
Obsidian | Level 7

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!
10 REPLIES 10
SASKiwi
PROC Star

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
Obsidian | Level 7 sc5
Obsidian | Level 7

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
PROC Star

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
Super User Tom
Super User

@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
Obsidian | Level 7 sc5
Obsidian | Level 7

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
Super User Tom
Super User

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
Super User Tom
Super User

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
Super User Tom
Super User

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.);
Quentin
Super User

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.

 

 

hackathon24-white-horiz.png

The 2025 SAS Hackathon has begun!

It's finally time to hack! Remember to visit the SAS Hacker's Hub regularly for news and updates.

Latest Updates

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

SAS Training: Just a Click Away

 Ready to level-up your skills? Choose your own adventure.

Browse our catalog!

Discussion stats
  • 10 replies
  • 167 views
  • 0 likes
  • 5 in conversation