@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. ... View more