Version: SAS Enterprise Guide 7.1
Programmers have defined a bunch of global macro variables.
e.g.
%let example = 4;
The question is how to check whether/where the defined macro variables are used in other Programs (even in different process flows).
As long as you haven't run the code in a session the macro variables don't exist in this sessions and you can't query the workspace for existence of any such macro variable.
The macro variables only exist in your code (somewhere in the EG project) as an "idea" - and though the only way of retrieving such macro variables would be to analyze the code.
EG projects (.egp) files are archives (which you can open with a tool like 7-zip). You then find a bunch of XML's in this archive which define the EG project and all the code.
Sooo.... If you really want to analyze EG project code, you would either have to export all this code out of EG into a .sas file OR you analyze the XML's in the .egp archive (you could eventually use the filename ftp engine to get access via SAS to these XML's and analyze stuff programmatically). ...But: In case the actual SAS code is not directly contained in the .EGP project but is only a reference to an external .sas file then you would also have to implement a process which then accesses this external code.
In the end of the day: The problem you're facing is imho more a design issue and you should try and resolve the issue on a design level (=implement proper and fully documented code).
Export entire EG process and search the code?
Definitely not ideal.
Check PROC SCAPROC as well. But programs could have conditional logic which may cause the results to not be 100% correct.
As long as you haven't run the code in a session the macro variables don't exist in this sessions and you can't query the workspace for existence of any such macro variable.
The macro variables only exist in your code (somewhere in the EG project) as an "idea" - and though the only way of retrieving such macro variables would be to analyze the code.
EG projects (.egp) files are archives (which you can open with a tool like 7-zip). You then find a bunch of XML's in this archive which define the EG project and all the code.
Sooo.... If you really want to analyze EG project code, you would either have to export all this code out of EG into a .sas file OR you analyze the XML's in the .egp archive (you could eventually use the filename ftp engine to get access via SAS to these XML's and analyze stuff programmatically). ...But: In case the actual SAS code is not directly contained in the .EGP project but is only a reference to an external .sas file then you would also have to implement a process which then accesses this external code.
In the end of the day: The problem you're facing is imho more a design issue and you should try and resolve the issue on a design level (=implement proper and fully documented code).
Good news: We've extended SAS Hackathon registration until Sept. 12, so you still have time to be part of our biggest event yet – our five-year anniversary!
Check out this tutorial series to learn how to build your own steps in SAS Studio.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.