How to embed all SAS code into SEG project?

[Haris]

I know how to embed individual SAS code links in SEG.  Is there a way to tell SEG to embed all SAS code at once?

Conversely, is there a way to Save As all embeded SAS code into separate SAS code snippets?  I know I can save the entire SEG project as one giant SAS code module and I can save each code module as a SAS code.  But can I point SEG to a folder (in my case it's Windows) and have it use the existing module names to create separate SAS code files with *.sas extensions?

What I am trying to do is to import multiple SAS programs into SEG.  These are all parts of the code system used to run annual reports.  I need to make changes to those modules, run the new report based on the previous report's code and then save the updated code to a new location preserving the structure of the previous report.  I really don't want to merge all those multiple SAS code modules into a single giant SAS code module.

Also, I thought there was an OPTION for changing what happens when SAS code is opened in SEG.  By default, external SAS code is linked.  I thought I remembered an option to automatically embed rather than link the code.  Can's seem to find that option in SEG 7.11.  Am I imagning things?

Thanks in advance.

[Astounding]

It sounds like the tool you are looking for is %INCLUDE:

options source2;

%include '\path\to\one\program.sas';

%include '\path\to\another\program.sas';

Any of the files can be updated, and the same project then would %INCLUDE the updated code.

[Haris]

Not sure what you are thinking, Astounding. %INCLUDE has nothing to do with embedding. I already use %INCLUDE to assemble individual SAS modules into the final execution sequence.

[Astounding]

Sorry, my bad.

[Haris]

No biggie. Thanks for trying, anyways.

[TomKari]

Probably through the Automation facilities, but it'll definitely take some effort.

Tom

[emera86]

Dear @Haris,

Did you finally found a straightforward way to solve this? I was just looking for the same piece of advice...

Thanks for your help!

[Haris]

Regretfully, no.

[SASKiwi]

I'm curious to know why you want to embed a group of SAS programs in a SEG project? Is it to add to an existing project?

If your EG project consists only of manually-developed code then what benefits do you see in doing this?

[Haris]

This is for running about 100 SAS programs twice a year with minimal updates/edits to the code.  We do archive each code set every report cycle though.

Thing is, four somewhat different programs feed from the same stock code and each program makes their own small tweaks.  That's why I would like to be able to break the link to all programs at the source so that each programmer would not need to worry about affecting other programs.

Yes, our SEG projects are 90% manually developed SAS programs but SEG is so much prettier than Base SAS.  Various auto-completion and look-up options make things so much easier to manage.  Log summary Explorer makes navigating and exploring the logs much faster.  We also store Excel, Word, PowerPoint and PDF documents in the SEG projects making for easy quick navigation and organization of these rather massive projects.  

There are other benefits but the ones above are the main ones that come to mind.  And finally, I have not opened base SAS in about a decade so I don't even know where things are in base SAS any more.  In SEG I feel like I am in the 21st century.  Bases SAS is 70s 🙂

[SASKiwi]

@Haris - interesting perspective. We too exclusively use EG, but only to manually develop programs that are not embedded. All programs are version-controlled outside of EG in MS Visual Studio with Team Foundation Server. That includes Excel spreadsheets containing reference data. It looks like you are using EG projects in a similar way to our use of a version control tool.

EG is primarily used for development and testing purposes where sometimes EG tasks come in handy. We use the Log Summary explorer too. Job runs are done exclusively in batch mode using SAS Management Console where we use the LSF scheduler. Hence the reason we don't use EG projects as these can't be run outside of EG. We keep all batch logs as an audit trail of what we have done.

Always good to hear about other ways of working with EG. Thanks for that!

[Haris]

Nice, Kiwi! Thanks for sharing.
We don't have any formal version control outside of saving the code and the log corresponding to each run. Low-tech non-IT solution here. Log saving is done manually after the execution of every program which is not the most efficient way to handle it. We do use %INCLUDE extensively to assemble sets of programs into a single Master program and run a single LOG.
If you know how to program in SAS, SEG tasks seem less efficient based on our experience. What SEG tasks do you find useful for a proficient SAS programmer?
One more capability of SEG that we utilize is the AUTOEXEC workflow. Our programs use macro variables extensively. Macro variables differentiate among the various programs that we base on the same SAS Code. Well, those macros, when placed in the AUTOEXEC workflow, become SEG-project-specific. This enables us to do different things running the same programs. I don't know if base SAS can do that automatically.

[Patrick]

@Haris 

save program as.. allows you to store your code as external .sas files keeping only links to these programs in the EG project. I guess that's actually already something you're doing.

You will need to use a path which is accessible for multiple users (either on the server or then on a shared drive everyone maps the same way to their local machine or accesses it via UNC path).

You will need to store the .sas files on the SAS server/in a location accessible by the SAS server.

Once you've got the external .sas files you can implement another program in EG which just does %includes to the programs you need to run as a set. You can of course have multiple such programs in EG defining multiple different sets of code to be run.

The path in the %include statement must be as it looks like from the SAS server side.

Wouldn't that give you the flexibility you're after?

[Haris]

I am not sure I follow what you are proposing.  I am looking to import about 100 stand-alone SAS programs from a shared network location into an SEG project and embed them all into that project.  I want to be able to edit the programs in SEG without changing the originals.  I don't think your proposal accomplishes that.  Am I missing something.

[Patrick]

@Haris 

"I am looking to import about 100 stand-alone SAS programs from a shared network location into an SEG project and embed them all into that project.  I want to be able to edit the programs in SEG without changing the originals."

Then first create a copy of these 100 programs into another folder on the network and then open the programs from this folder.

Doing it this way won't actually import the code into EG but create links to the code which you then can use as if the code were directly stored in EG.

Now for the versioning of your external code (the .sas programs):

You could have the code EG links to in a folder called "current" and you then create copies of this code into folders with a date component in the name.

If you don't change the names of the .sas files then whatever version of the .sas file is in your current folder is what EG will link to.