12-19-2016 11:46 PM
I want to retrieve the source code of a compiled macro, and this macro is compiled without source & secure option specified.
I tried to retrieve the code using:
options mstored sasmstore=mylib; libname mylib "mypath"; filename maccat catalog 'mylib.sasmacr.secure.macro'; data _null_; infile maccat; input; list; run;
and the output in log is:
CHAR ....E.......%AHGwinorunix=WIN.... 33 ZONE 000040001000244476667766735440000 NUMR 500050001000518779EF25E98D79E0000 CHAR &............... 16 ZONE 2000000000000000 NUMR 6000300030000000 CHAR &............... 16 ZONE 2000000000000000 NUMR 6000400050000000 CHAR ....E... %AHGpipe(.dir %AHGaddslash(&dir)..sas .b. ); %AHGpm(rcpipe);.... 81 ZONE 000040002222224447676206672244466676676226672127672160223222222444762767676230000 NUMR 30005000000005187090581492051871443C1388649297E313082209B0000051870D82309059B0000
This format is not readable.
Could anyone give me some hints on how to retrieve the source code from compiled macro?
Or try to format the above code into readable SAS program?
12-19-2016 11:56 PM - edited 12-19-2016 11:58 PM
Please try the mfile option with filename and mprint. The syntax is as follows, when you run it, the file mysasfile.sas will be created and in this the source code of the compiled macro will be saved.
filename mprint 'c:\mysasfile.sas';
options mprint mfile;
your macro code ;
12-20-2016 03:02 AM
I'm afraid your method does not work for me.
I'd like to see the source code rather than the code beening compiled.
12-20-2016 01:02 AM
If your compiled macro was not created with the SOURCE option then unfortunately there is no way to retrieve it:
12-20-2016 04:46 AM
No, that is a really good examplpe of why to avoid proprietary file formats. We had the same thing, years of vendors sending us code hidden in black box compiled catalogs. When 64bit SAS came along these became inaccessible, hence any use of them now has to be re-programmed from the start. So take this as a learning exercise, always use plain text easily transportable file formats that are not tied to any software. We specifically put in all our contracts this now and don't work with those companies who hide things in compiled catalogs or other methods.
12-20-2016 05:38 AM
But you would agree that this isn't really a SAS issue as SAS allows to store the source code with the compiled macro or alternatively also provides the SAS Autocall facility where you don't need to pre-compile the macros at all.
12-20-2016 05:55 AM
Well, yes, but also no. They do offer methodologies to utilise this in a process and retain the open mentality. However, for the most times I have seen catalogs used, it is to hide code. This may just be a thing in my industry, but its only in recent years that vendors have been more accepting of not hiding their code. Even now, some of what we are sent is hidden in catalogs, and its makes it next to impossible for us to decipher what is going on. With the use of CDISC standards going forward, and the need to provide methodologies, this will have to change.
So yes, its not SAS directly, but those compaines who use the tech in this manner. But then you get in to the the cyclic argument of which is the problem, the gun, or the people buying them?
Moving on from there, functions are even worse. The code is hidden and the calls to them maskerade as normal functions, not even a % to indicate difference.
12-21-2016 03:45 AM
As a general policy I never use SAS compilation options such as macros as I've never found enough advantages to outweigh the disadvantages - like you have found.