BookmarkSubscribeRSS Feed

Add option(s) to disable EG from interjecting the code which sets certain macro variables , i.e. _CLIENT* and _SASPROG*.  Allow the particular project loaded in memory to have this option disabled by accessing it(them) from the menu under File > Project Properties. 

 

By "code which sets certain macro variables" I'm referring strictly to the LET statements that EG adds to each program node which effectively augment the SAS environment with values generated by EG. 

 

Also wanting that when one is using File > Export > "Export all Code in Project", that the generated macro variables would also be excluded.

10 Comments
paulkaefer
Lapis Lazuli | Level 10

Would this option exclude all system variables, including &sysdate?

I'm curious why this would be useful; can't you just ignore these variables?

PhilC
Rhodochrosite | Level 12

Good question.. And may be I need to edit my request, so thanks for the immediate response.  I want to refer to the macro variables that EG sets by interjecting code before the running of the user's code in each node.  You see evidence of these variables by looking at the logs of each node that have been ran in a project.

 

As for the purpose, it is because, sometimes, I wish to develop SAS code in the EG environment, but my customer wants the developed SAS code in a text formatted SAS file.  These variables are great and useful, but I often find myself exporting the project code then taking a regular expression editor and removing the extraneous EG macro variables that EG interjects.  So I'm asking to make it an option to remove them, or not to add them.

paulkaefer
Lapis Lazuli | Level 10

So it sounds like you are typically saving code in a .egp file? Why not just open each node and do a "save as" .sas file? You can certainly use EG to edit code stored in .sas text files.

 

.egp files can be useful and all to keep things in one place, but there are advantages to being in the habit of storing code in text files, as I've written about.

PhilC
Rhodochrosite | Level 12

If I had such disrespect for EG I would skip it all together.  But there's far too much intelligence and wonderfulness in EG to not use it.  I only want to make it more flexible (as if it needs more flexibility) But some of my ideas have be adopted by the EG development crew, so I express by gratitude by continuing to share.

Quentin
Super User

EG (and DI studio, and lots of the other clients) typically add a good amount of generated code.  Not only these macro variables, also ODS statements, options statements, goptions, magic string at the end, etc.  What would you think of an EG option which is "don't generate any SAS code."  If you selected that option, it would be your responsibility to code everything youself (like in Display Manager).  But your code might also be more portable.

 

Personally, I have been annoyed that the number of global macro variables the newer clients create, but I've also used them plenty.  For the most part, I want to be able to develop in EG and then move code to a DI job or a stored process or even a PC SAS job.  Having the ability to turn-off EG generated code might help me avoid accidentally relying on some EG-only feature.

PhilC
Rhodochrosite | Level 12

thanks for the support

paulkaefer
Lapis Lazuli | Level 10

@Quentin, I prefer this suggestion. This could also benefit auto-generated code from the point-and-click features, i.e. Filter and Sort and Query Builder. I frequently will adapt code generated from these, but typically clean out some of the "other stuff" that gets added.

PhilC
Rhodochrosite | Level 12

I see you Paul, and EG tasks are basically auto-generated code created at the user's request...  and that's my point -- allow the user to request or disable a feature of EG which is implemented by auto-generated code.  The auto-generated code surrounding EG's ODS features I can live with...  or it might be worthy for another post to ask for a setting to set the current project's default output options for all newly created nodes, or a way change all to be the same...  it's whole other SAS ware ballot.

paulkaefer
Lapis Lazuli | Level 10

Great points, @PhilC. Happy to upvote this. Definitely see how this could also apply to DI Studio... can be confusing to see the autogenerated code for the first time, and sometimes it's difficult to dig through what's generated to find the places that are user-defined.

 

I agree, a system option would be nice. If nothing else, it could hide what's system-generated for all intents and purposes. So there would still be a way to see it if you wanted, but to your point, viewing and exporting the user-contributed code would exclude it.

Casey_SAS
SAS Employee
Status changed to: Under Consideration

Thanks Phil - This suggestion has been added to be reviewed for potential inclusion into a future release