04-22-2014 04:48 PM
I am trying to find the location of all source code for ALL Enterprise Guide macros. I assume its in a library somewhere both locally and on the Workspace server, but I cannot seem to locate. Tech Support is still trying to get me the info as well...was hoping that someone here might be able to direct me to them.
Some of the macros I am referring to are:
I know I can get the source code by exporting the SAS code from within EG, but I am looking for the entire library of where these macros exist, of which I believe there are 70+?
04-22-2014 04:56 PM
You can find most of these in the SAS initialization log, visible via this technique:
04-22-2014 05:25 PM
Thanks for you reply Chris! Yes, I have seen the initialization log before and it does appear to have the macros I am looking for, although I am not certain it contains all of them.
I am interested in finding out where the source resides that gets run upon initialization. The macros are stored on the Workspace server and I've looked for clues in all the autoexec.sas file, ie, /apps/SAS/metadata/Lev1/SASApp/WorkspaceServer/autoexec.sas but I am still not finding the source.
I guess I was expecting to find a library similar to the SAS9.3 macro library under /apps/SAS9.3/SASFoundation/9.3/sasautos where all the macros reside.
04-23-2014 07:59 AM
The source for these macros is built into SAS Enterprise Guide, and isn't visible from the file system. Since EG relies on these macros regardless of SAS version or location, EG submits the macros when it connects to ensure that they are defined.
04-23-2014 08:56 AM
I just went through the Application Data tree in hope of finding an xml where the source may reside, but found nothing. Are these macros actually contained in the EG binary?
04-23-2014 08:59 AM
Yes, they are. If you want the source, another method you can use is File->Export All Code from a project. The macro source should be prepended to any SAS program that you export from EG, so that the macros resolve in another target environment.
04-23-2014 09:03 AM
Is there a sound reason for doing that? My first thought was "OH.MY.GOODNESS."
Putting code into a binary sounds awfully, ah, don't want to be rude here, unusual.
04-23-2014 09:24 AM
There is a reason. And yes, I believe the reasons are sound, but that could be a subjective judgement.
These macros are essential for EG to function properly, just like any EG program code that is shipped. If these were placed "loose" on the file system, it might invite modifications by sites/end users which could result in difficult-to-diagnose problems. (Actually, these are learned lessons from an older approach some might remember with the EGAuto.sas file.) So yes...the files are bundled as part of the binaries so as to discourage that.
We can't rely on the macros to be shipped as part of a SAS autocall library, since EG runs against multiple versions of SAS and -- out of the box -- does not require an EG-specific "server component" to be installed. So all of this macro logic is bundled with the client.
However, end users still have visibility into the macros via the initialization log and Export Code options that we discussed here. And, if a site does want to "inject" a customized version of a macro, it's possible via one of the many methods to add "autoexec"-style code into the EG process.
04-23-2014 11:03 AM
Thanks for the background and history, Chris. It's an interesting balance.
On the one hand, as a developer I feel like the macros belong to "me", so I like having all the source code in autocall library. And it's useful to review them. When I was just learning BI stuff, I was thrilled to realized %STPBEGIN is just an autocall macro. Reading through it helped tremendously as I tried to understand all the global macro variables created by various clients that are essentially parameters to %STPBEGIN. So very happy to have a way to review the macro definition.
On the other hand, while I feel "entitled" to see the source code for a macro, R folks would say it's odd that I don't feel entitled to see the source code for a PROC. And even with the macro language, I have come to accept that the difference between what SAS provides as an autocall macro (available for me to peak at, e.g. %Lowcase) and what is provided as a macro function (where I can't see the source code, e.g. %Upcase), is sometimes seemingly arbitrary
And at the same time that many developers would want more open-ness from SAS (sharing source code for autocall macros as a general rule), there has been plenty of push from developers for SAS to provide new features that allow us to hide our macro definitions from others, in applications we build with SAS. And SAS has obliged.
And of course the more that SAS makes open to users/developers, the more stuff that usees/developers can enhance, and break. Until ODS, a user couldn't call up and say "PROC REG is broken" and have the root cause be that they broke it by breaking a template....
04-24-2014 03:44 AM
As all macros are compiled into the same global zone I like to beware of the others(those I don't create).
In this context, it might be sufficient to be advised that the macros submitted from SEG binaries have names with a common prefix and that they might create or depend on global macro variables in a particular list.
however such documentation will have to be created by reviewing these macros, to be revealed in such a contrived way.
one classic(sas9) way to expose the source of macros located through AutoCall is system option mAutoLocDisplay. Of course that has its limits too (macro code submitted directly like these SEG macros are not AutoCall -ed).
04-23-2014 04:43 PM
Thank you to all who responded. Of course, its not the answer I was hoping for to hear that the macros are part of the binary EG code, but now makes sense why I was not able to find them. My thought now is to use the SAS initialization log file to pull out all the source code for the macros. One final followup question...are there other EG macros that are not in the SAS initialization log file?
04-24-2014 08:36 AM
@Chris, I followed this discussion coming in late .
As you want to think in a service being delivered by SAS that is used by their customers to build their (sas) applications, it would by good practice to have the communication area being well defined. Call it SVC, SMB or whatever when it is implemented by SAS-macros also fine. The requirements for a good cooperation are:
- Let it be well documented in what is there and what the expectations are. that is including the used names avoiding accidental collisions.
- When recommendations how to use this SAS service, are not followed, what to do about that.
As the documentation is missing the question to review the involve source (sas macro-s) is quite legitimate.
I can see your frustration with the use of egauto.sas (EG 4.1) being used to solve configuration issues at the server side. That is not intended use. For the freaks still existing as "Enterpriseguide.sas" found in the install directory EG 5.1. Yes agree should not be used for that kind of purposes as there are enough documented ones.
For running EG projects there are enough challenges to solve with migration projects. As there are:
- Metadata defined objects (libraries / fields / STP etc.)
- Workspaces server (and others) configuration setup
- internal stored absolute paths in the zipped XML file that makes the EGP project.
All this are dependicies nobody will really like being aware of the impact.
The real issue behind is IMHO some missing goals on cooperation and trust on the technical parts related to these tools.