Execution with "altlog" while disabling log in a job

[ThomasH]

Dear all,

I am facing an issue I cant currently find a resolution for - maybe you know the trick?

While executing a huge job I am partially disabling logging to avoid huge log files. This is done via

filename junk dummy;
proc printto log=junk; run;

and turned back on via

proc printto; run;

Now the job is executed via

sas -sysin test.sas

It writes the log file as expected.

Now I want to create an additonal log file to another directory with

sas -sysin test.sas -altlog mylogfile

but using this completely ignores the disabling of the log file in the job and suddenly the log gets very large.

Is there another way to call the sas job or to disable the log to work in conjunction with -altlog?

Thanks a lot and cheers,
Thomas

[Peter_C]

only by writing less to the log.
Why is it so large?

[ThomasH]

Hi,

because it iterates multiple times through a set of jobs.

Thomas

[Peter_C]

in most environments I have seen, multiple jobs each have their own SAS log.

No amount of "saved disk space" will solve the problem when something goes wrong. If anything should go wrong, you'll need all the diagnostics you can get!

If you are running SAS on a windows platform, enable file compression. Typically a SAS log will compress to a tenth of it's original size

good luck
PeterC

[ThomasH]

Peter,

not having a log in certain situations is not my problem. The jobs are included in a loop so they are logged INTO the root job output and THIS log gets huge. So much for the details.

Question still is how to store the (partially diabled) log output to a second directory without having -altlog ignore my proc print to dummy.

I havent found anything in the documenation so far.

Thanks,
Thomas

[ThomasH]

Alright, slowly getting there.

Using something like
options NOMPRINT;
options NONOTES;
options NOSYMBOLGEN;
options NOOVP;
options NOMFILE;
options NOSOURCE;
options NOSOURCE2;
options NOMLOGIC;

disables everything that is written to the log, except MPRINT - why? 🙂

Lines like these are left:

MPRINT(ETLS_RECORDCHECK): set work.etls_contents (obs = 1);
MPRINT(ETLS_RECORDCHECK): call symput("etls_recordsBefore", left(put(nobs,32.)));
MPRINT(ETLS_RECORDCHECK): run;
MPRINT(ETLS_RECORDCHECK): proc datasets lib = work nolist nowarn memtype = (data view);
MPRINT(ETLS_RECORDCHECK): delete etls_contents;

Thanks,
Thomas

[Peter_C]

probably some invoked macro or %included code includes
option mprint ;

If you only wish to avoid huge log files, then look at the LOGPARM option.
With invocation option -logparm "ROLLOVER=1M" the logfile is opened afresh when it becomes 1 megabyte.
There are other options and values causing log roll over on change of date or time or different log file sizes.

See SAS9.2 documentation of LOGPARM at
http://support.sas.com/documentation/cdl/en/lrdict/62618/HTML/default/a002303556.htm and the links to this option on your platform


and I would really encourage you to reinstate options NOTES and SOURCE, and unless "support" is really unneccessary, MPRINT.

hope it will help
PeterC

[ThomasH]

Hello Peter,

thanks for the hint - there actually is a statement option mprint; used which I did not code but is inserted automatically into the code by DI Studio.

%macro etls_setDebug;
%if %str(&etls_debug) ne 0 %then
OPTIONS MPRINT%str(;);
%mend;

Need to find out where this comes from 🙂

UPDATE for everyone with similar issues:
%let etls_debug=0;
in the autoexec file does the job

Thank you!
Thomas

Message was edited by: ThomasH Message was edited by: ThomasH