System Option for Displaying Macro Source Code on Log Only Once

[F_Pierantoni]

Due to cybersecurity restrictions, our SAS Site Administrators have enforced system options like SOURCE, SOURCE2 and MPRINT on every SAS session to make sure that every single line of submitted code is printed on the SAS Log.
Options SOURCE and SOURCE2 pose no particular problem.  But a locked-in MPRINT option has the unwanted effect of multiplying the number of lines of Macro Code being printed on the Log, every time a Macro is invoked.
Having a system option that displays the Macro Code only once (regardless of how many times the Macro is called in the program) would be very helpful to reduce the number of lines displayed on the Log.
MPRINT is a debugging option that works well as it does.
The new option could be named somewhat differently (maybe MLOG ?).

[Quentin]

MPRINT is not showing the macro code, it's showing the SAS code that the macro generates.  Each time a macro is called, it may generate different SAS code (depending on the parameters passed, the input data, global macro variables, etc etc.)  So if the admins want to be able to read the log to see all the SAS code executed (which I think is reasonable, I always leave MPRINT on), I don't think an option to show the results of MPRINT once per macro called would meet that need.

[F_Pierantoni]

Correct.  Thanks, Quentin.  However, the IT & SAS Admins do not really want to see every single line of code generated by the Macros.  They want to see the "code submitted".  And in the case of SAS Macros, especially the Macro code that is called via the Autocall (SASAUTOS) library, which is not normally displayed on the SAS Log (except using MPRINT).  And since there is no other option to show the auto-called code, they have imposed MPRINT on everyone (in addition to the already mentioned SOURCE and SOURCE2).  As a result of this, we now have some Logs containing thousands of lines, because some Macros get called several times in a program (especially batch programs using standardised Macros for specific functions).
I hope this helps clarify the issue.

[Tom]

If you are interested in where SAS autocall FOUND the macro definition file then there are different options for that.

MAUTOCOMPLOC -  Displays in the SAS log the source location of an autocall macro when the autocall macro is compiled.

MAUTOLOCDISPLAY - Specifies whether to display the source location of the autocall macros in the log when the autocall macro is invoked.

If they are worried that only knowing the file location of the the autocall macro is not sufficient detail then they should put the autocall library (libraries) under version control.  That way knowing the location and the run time should allow them to retrieve the version used.

[Quentin]

@F_Pierantoni sorry, I'm still confused.  Suppose this macro is in an autocall library:

%macro try(x) ;
  %if &x=1 %then %do ;
    data want ;
      set sashelp.shoes ;
    run ;
  %end ;
  %else %if &x=2 %then %do ;
    proc reg data=sashelp.class ;
      model weight=height ;
    run ;
    quit;
  %end ;
%mend ;

And suppose in my program I turn on MPRINT for the first run, and then turn it off for the second run. The log would look like:

1    options mprint ;
2    %try(1)


MPRINT(TRY):   data want ;
MPRINT(TRY):   set sashelp.shoes ;
MPRINT(TRY):   run ;

NOTE: There were 395 observations read from the data set SASHELP.SHOES.
NOTE: The data set WORK.WANT has 395 observations and 7 variables.

3    options nomprint ;
4    %try(2)

The log shows both macro calls (because SOURCE is on), it also shows the SAS code generated by the first macro call (because MPRINT was on), but it doesn't show the macro code.  Is the above log what you would want (without the need for you to turn MPRINT on and off?).  Seeing the MPRINT results from the first invocation tells you nothing about the results of the second invocation.   %Try(2) could be doing anything.

Without MPRINT, you see the 'code submitted' in the log if that can be interpreted as seeing the macro call that was submitted (to the macro processor).

With MPRINT, you see the 'code submitted' in the log if that is interpreted as seeing the SAS code that was submitted (after being generated by the macro).

I wonder if your IT group would be happier with a new option MAUTOCOMPILELIST, which would echo the source code for an autocall macro to the log, when it is compiled.

In the absence of an option like that, maybe IT would be satisfied if users would use the %INCLUDE statement to compile macros, rather than use the autocall feature.  Since you have SOURCE2 turned on, that would show the source code for the macro in the log. And if that is enough to satisfy IT, maybe you could leave MPRINT off.

That said, I don't think there is a problem with logs that are thousands of lines long.  If I'm reading a log, I'd much rather have a log file that is long, and has all the SAS code in it, than a shorter log where I have to look elsewhere (macro definitions, %include files, etc) to trace through the SAS code that was executed.  It kind of gives me the chills if I see a log file that has a macro call followed by several sets of notes about output datasets that are created, with perhaps a warning somewhere in the middle.  I feel like I'm in the end of Poltergeist.  "WHAT IS HAPPENING!!!?!?" But I recognize that's just my personal style.  Many folks like to turn off MPRINT for production runs, some people even turn off NOTES or SOURCE, which scares me even more. : ) 

[F_Pierantoni]

Thanks @Quentin !  
Your suggestion for "a new option MAUTOCOMPILELIST, which would echo the source code for an autocall macro to the log, when it is compiled" is what is needed.
We did explore the option of asking users to use the %INCLUDE statement before calling each Macro, but the idea was quickly dismissed, as there's no way of ensuring that all users will remember to do it.
We have hundreds of SAS users at different levels of their SAS journey, spread across several business units and teams.  Centralised control of the SAS options was deemed the only way forward by the IT Security group.