PROC PRINTTO log truncated in background execution

[Gauss212]

Hi everyone,

I'm using SAS Studio Release: 3.81 (Enterprise Edition).

A colleague of mine is experiencing an issue related to log redirection in a long-running program executed in background. We have a main program (pgm1) that includes another program (pgm2) using:

/*pgm1*/
%include "pgm2.sas";

The original code is for internal use, so the example below is a simplified replica of the structure.

In pgm2, the log is redirected using PROC PRINTTO:

proc printto log="xxxxxx\log_file.txt" new;
run;

data test1;
  a=1;
run;

data test2;
  a=1;
run;

%macro p();
  data test3;
    a=1;
  run;
%mend p;

%p();

data test4; 
  c=1; 
run; 

data test5; 
  p=1; 
run; 

proc printto; 
run;

The full code runs for approximately 5 hours and the behavior differs depending on how the program is executed:

• when executed normally (not in background), the log file is created correctly and contains all the expected content;

• when executed in background mode, the log file appears truncated. Specifically, the first data steps (test1 and test2) are correctly written to the log file, but starting from the macro execution (%p()) no additional log content appears in the redirected log file.

We would like to understand:

• whether this could be related to background execution handling;

• if there are known buffering or flushing differences with PROC PRINTTO in background mode;

• whether macro execution might interact differently with log redirection in long-running background sessions.

Additionally, we are not using any system options like NONOTES or NOSYMBOLGEN in the code

and we see unusual log messages when running in background, such as:

• NOTE: %INCLUDE (level 1) ending.

• 8927 options nonotes nosource nosyntaxcheck;

• SYMBOLGEN: Macro variable GRAPHTERM resolves to GOPTIONS NOACCESSIBLE;

Has anyone experienced similar behavior or can suggest a more robust approach for managing log redirection in long-running background programs?

Thank you! 

[Quentin]

I think I would start by looking for the code for the OPTIONS statement that is turning off notes and source:

8927 options nonotes nosource nosyntaxcheck;

Is that the last thing you see in the log?

Is that options statement coming from your macro? User-written code? Is it being automatically generated by Studio?

It's definitely possible for a macro to turn off logging and forget to turn it back on at the end.  But I can't think why that would only happen with a background submit.

[Gauss212]

Nowhere in the code are these options (NONOTES NOSOURCE NOSYNTAXCHECK) present. They have never been inserted in the main program, the macros, or the included files.

If you know, is it possible that, since the job runs for several hours and is executed in the background, SAS automatically disables some log options, causing the log file to be incomplete? If so, would it be useful to insert options notes; at strategic points to force the log to be written?

[Tom]

Do you have any other indications that the SAS code is actively running?  Perhaps the program has crashed (or gone into an infinite loop) and that is why nothing is being written to the log.

Try changing startup options that writes to the log are flushed to the disk immediately.  That might allow you to see what is the last step that is actually running.

https://communities.sas.com/t5/SAS-Programming/How-to-force-updates-to-SAS-Log/td-p/413993

Also with "background" execution I would assume that means it is running the job directly from the .sas file (instead of having code submitted by your front end tool such as SAS Display Manager or Enterprise Guide or SAS/Studio).  In which case the lengths of the lines in the .sas file might be an issue.  If a line gets truncated you might end up with unclosed quotes for example that might make the program hang.  Personally I try to make sure that no lines of code in the .sas file is longer then the 65-70 character limit that humans can read without moving their eyes side to side.

[Gauss212]

So, you’re saying that even lines longer than 70 characters could cause errors in background execution? That’s strange, because when not running in background the log is created normally.

To investigate further, I could try using options fullstimer;, but in any case, the final outputs are still being generated correctly.

[Tom]

LInes longer than 70 will only cause problems for humans reading the code which could lead to unbalanced quotes, etc that they do not see.  But that is probably not your problem if the same code runs properly in other situations.

Lines longer than whatever default LRECL SAS uses to read the codef ile from SYSIN could cause problems.  But you state the program actually runs and only the log file is missing.  So that is probably not your problem.

Here are other things to check.

• Is there some system process that is removing files from the location where PROC PRINTTO writes the file.
• Are you sure you are looking at the file that PROC PRINTTO is writing to?  Perhaps some difference in the execution environment is causing it to place that file somewhere else.
• Are you running multiple versions of the program at the same time?  If so then make sure that they are not all trying to write to the same LOG file.