BookmarkSubscribeRSS Feed
dcastore
Calcite | Level 5

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:

%macro _eg_conditional_dropds;

%macro _eg_WhereParam;

%macro_sas_pushchartsize;

%macro_sas_popchartsize;

%macro em_usedatatable;

%macro ExtendValidMemName;

%macro enterpriseguide;


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+?


Thanks,

Deanna

12 REPLIES 12
ChrisHemedinger
Community Manager

Deanna,

You can find most of these in the SAS initialization log, visible via this technique:

Uncovering the hidden parts of the SAS log - The SAS Dummy

Chris

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
dcastore
Calcite | Level 5

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.

Peter_C
Rhodochrosite | Level 12

If macros are compiled through the autocall routines the source location will be revealed by system option MAUTOLOCDISPLAY

ChrisHemedinger
Community Manager

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.

Chris

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
Kurt_Bremser
Super User

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?

ChrisHemedinger
Community Manager

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.

Chris

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
Kurt_Bremser
Super User

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.

ChrisHemedinger
Community Manager

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.

Chris

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
Quentin
Super User

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....

--Q.

BASUG is hosting free webinars Next up: Jane Eslinger presenting PROC REPORT and the ODS EXCEL destination on Mar 27 at noon ET. Register now at the Boston Area SAS Users Group event page: https://www.basug.org/events.
Peter_C
Rhodochrosite | Level 12

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).

peterC

dcastore
Calcite | Level 5

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?

Thanks!

jakarman
Barite | Level 11

@Chris, I followed this discussion coming in late Smiley Wink.

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.

---->-- ja karman --<-----

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 12 replies
  • 4555 views
  • 1 like
  • 6 in conversation