Compile already existing Macros SECURE

[DoLoopLover]

Hello,

I have some SAS-macros stored in a folder. I wand to compile some of these macros with the option SECURE without editing the original macros, because this would require re-validation.

To %include the macros to the work-folder and write then to a new catalog works, but then the code is readable in the log-file.

Has anybody a solution? Thanks,

[RW9]

You could store the macros into a catalog, and hide them that way:

http://www2.sas.com/proceedings/forum2008/101-2008.pdf

Is there a particular reason to do this?  The reason I ask is that a lot of third parties do that with our code, and the recent switch from 32bit to 64bit has made it all stop working - thats hundreds of projects, no source, nothing working.  It is a very good example of why the whole closed source mentality is bad for everyone from cost through to traceability.  If you don't trust someone with your code don't give it to them, but the worse option is to give them something which might work, but might not.

[DoLoopLover]

Hello RW9,

thank you for your solution, unfortunately this does not solve my problem.

I understand your concerns and agree with you. I prefer open source code! If I should like to use/steal a foreign code it could be done by editing the first line of the macro and SECURE the code. In my current project we send all programms to our sponsor, so that the outputs can be re-run. To give them the project specific programs is no problem, but we would like to hide our generic macros. 

As discribed I would like to compile already existing macros. The macros in our company run through an extended validation. With the solution in your link I have to edit the first line of the macro and therefore re-validation is needed and the version controle will change the version number of the macro. This, I would like to avoid. So up to now the macros are not stored in any macro catalog, but the folder is assigned in a global programm.

Thank you for your effort. Has anybody a solution without editing the macros. Maybe %include and write then from WORK to a new catalog?

Thanks a lot!

[Patrick]

@DoLoopLover

I'm 110% with @RW9 that locking away code is almost always not a good idea and I don't know of many reasons where I'd consider such an approach justified.

You can suppress SAS log by redirecting the output to a dummy destination using PROC PRINTTO.

You still need to add the SECURE option to the macro definition as else options like MLOGIC will write the inner workings of the macro to the log whenever the macro executes and no matter in what catalog it resides.

And here a code sample how to write SAS log to a dummy destination.

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

%macro one /secure;
  %put something;
%mend;

proc printto log=log;
run;
filename nirwana clear;

options mprint mlogic;
%one;

[DoLoopLover]

Hello Patrick,

thank you for your sugestion. The sponsor should not see, after re-running of the calling programms the code of our generic macros. So this solution does not solve my problem.

[Tom]

You cannot add the SECURE option to the %MACRO statement without modifying the source code.

If you just want to compile the macros without listing the source code then just add the NOSOURCE2 option to the %INCLUDE statement.  Let's make an example source code file.

filename code temp;
data _null_;
  file code ;
  input ;
  put _infile_;
cards4 ;
%macro util1;
  %put Running &sysmacroname ;
%mend util1;
;;;;

Then we can compile the macros using %INCLUDE without showing the source code.

10   ;;;;
11
12   %inc code /nosource2;
16   %util1;
Running UTIL1

[Tom]

I am really not sure I understand the point of this request.

Are you sending the customer the SAS logs and you do not want your macro code to appear in the logs?  Then just run the programs in a way that the macro code does not appear in the logs.

Are you giving the customer a working SAS program and you want them to be able to run the program but not see the program?  That seems much harder and is probably not worth the effort.  If you trust them enough to give them the program then trust them not to violate your copyright.

[RW9]

Hi @Tom

I understand this problem all too well.  Its common in my industry to outsource study work.  To this end the vendor is contracted to produce some outputs which go into documents for the regulatory bodies.  Now there is a debate ongoing of who owns the IP on the development of these, if you speak with the vendor, they will insist that they wn the IP on their code used in the programming and that the sponsor is paying for outputs, whereas from a sponsors point of view we pay for the whole process.  This has been ongoing for decades, and vendors want to hide the generic code they use for similar tasks.  What this however leads to, as in my situation, is hundreds of older studies for which we need to go back to no longer produce the outputs (32/64bit) and we cannot see what the code does, hence we have to start again.  Thankfully though it seems regulators are now starting to ask for code and logic and such like so vendors will need to start removing this type of thing.  In projects I work on I put in the contracts that working, plain text code should be provided throughout and drop any who don't.

As for OP, the only real way to hide the code is to compile it into a protected catalog.  You can do this pretty simply, by branching with your version control software and then adding the necessary extra few lines in - the text compare can then be used as validation.  However I would really advise against it, I don't see any situation where your proprietary proc report macro is worth the hours of rework 10 years down the line when it no longer works.

[DoLoopLover · Accepted solution]

Thank you very much RW9. Your input helped a lot to point out possible difficulties .

After some discussions with my coleages and concerning the effort, we decided to provide the current macros to the sponsor as plain text code.

[RW9]

Yay, chalk one up for the open source revolution!