An Idea Exchange for SAS software and services

Comments
by Regular Contributor
on ‎01-17-2018 11:07 AM

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

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

by Regular Contributor
on ‎01-17-2018 01:03 PM

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.

by Regular Contributor
on ‎01-17-2018 01:07 PM

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.

by Regular Contributor
on ‎01-17-2018 01:17 PM

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.

by PROC Star
on ‎01-17-2018 01:17 PM

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.

by Regular Contributor
on ‎01-17-2018 01:18 PM

thanks for the support

by Regular Contributor
on ‎01-17-2018 01:21 PM

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

by Regular Contributor
‎01-17-2018 01:33 PM - edited ‎01-17-2018 01:35 PM

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.

by Regular Contributor
on ‎01-17-2018 01:48 PM

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.

by SAS Employee Casey_SAS
on ‎02-26-2018 09:26 AM
Status changed to: Under Consideration

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

Idea Statuses
Top Liked Authors