How to set up all macro variables and libraries for a new project

[jhaque]

some libraries and macros will be used for all programs through out the session.

where nd how to set up those global macro variables in SAS EG?

[jakarman]

It is not in EG  you have to do that at the Serverside part of the configuration.

You need an architecture and vision on your requirements and the installation. That includes ITIL Cobit "standard of good practice".

[ChrisHemedinger]

You can put these in a program within the Autoexec process flow in EG -- that's a per-project item.

To apply to all items, you can set code within Tools->Options->SAS Programs, "Submit SAS code when server is connected" -- specify your statements in there.

See also this article:

Using Autoexecs with SAS Enterprise Guide

Chris

[SASKiwi]

If the libraries are to be shared across multiple SAS EG users working with a remote SAS server, then it is worth considering defining them in SAS metadata via SAS Management Console. This avoids having to code the required LIBNAME statements altogether.

Also if you are sharing SAS macros consider setting up a SAS AUTOCALL macro library, the most convenient way to manage them.

[jakarman]

You have to be clear about what you are doing, the first thing is, are you going:

1.1-  to do an isolated department approach (not really strategic)

1.2- an enterprise approach with the expectation of a long term usage.

In this case you will see two hierarchies, that are an:

1.2.a organizational one.    This can be found in the bisecag as SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (organizational) and

1.2.b a work (project) related one SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition.  claims to be having a functional approach but is showing divisions (organizational)

             Changing that word divisions into projects(or sas-applications) you are having a real functional approach.

As the organizational structure is commonly very dynamic my vision is you need to do both of them.

For projects you can follow a similar structure on the OS-level as in the SAS metadata level. There will be always data on the OS parts when going for advanced data processing. 

Having a RBAC (Role Base Access Control) proces in place with an IDM (Indentity Management) support you are getting aligned with those.

I like the blogs of Gregory Nelson he is seeming to have the same kind of opinions as me.

The admin role changed a lot. A day in the life of a SAS Administrator: Understanding the roles we play - SAS Users being more of advisory than a technical one.

Having a grand design vision on how to manage projects (sas applications) you can go for more details.

There are a lot of discussions at what place configurations should be made. The opinions are often based on a persons background.

In a enterprise approach you are wanting a central managed (auditability traceability) one.  You are getting into:

2.1 Some adhoc work is allowed it should by supported well as being the first visible for user-acceptance  . 

     Seeing the EGP (Eguide) methods on the desktop as the "solution" is not correct.     

     Of course people grown as selfservice ones not cooperating with IT-staff will like the desktop only one.

2.2 Manage the configuration by doing some within the SAS-metadata administration. 
     With a RDBMS DBA background this is often the only visible (removing redundancy as paradigm) way as similar to that RDBMS catalog.

     The world of a DBA is often limited not wanting to see OS files Bi Analtyics and all other topics outside his RDBMS reference world.

     For SAS macros formats (sas system options) and filenames are not managble from this point. There options for libnames

2.3 Manage the configuration by doing some at the OS-level administration and SAS configuration.

      There is a whole bunch of them see: SAS(R) 9.4 Intelligence Platform: System Administration Guide, Third Edition    

Nice is the post about the libname choices: Pre-assign SAS libraries? If so, which method? - SAS Users 

For a lot of usual used circumstances  I believe you will good at the method of "pre assigned by external configuration".

The reason is that it will give you more freedom to get compliant with release management and other processes.

There are implementation errors by sas, they are described in some notes

38040 - Setting umask and ulimit values for SAS® sessions on UNIX and Linux  there are some new options to set perms on a programmatic way in code.

   What is needed is a design concept for storing managing business project files.  

50345 - Changing the current working directory for the SAS® Workspace Server . This is more a signal to some sas design mistake you should review.

A design mistake by sas is the construct at the SASApp indicated as server-context in the admin-guide.

Looking in those folders you will find directories that indicates sas is expecting the business project data/code to be placed in those subdirectories.

It says every SASApp server-context has a 1-1 relationship with a project/business sas application,   Needing more projects is needing more SASApp's. An enterprise will uses many projects.

The problems:

- code and data are different type of artifacts being managed  different

- code and data can have different technical ownerships. Anyway it is not SAS-institute owning (accountable) the customers business environment.

- code and data can have different technical resource requirements. Anyway it is not very sensible to share those with the sas installation and sas configuration.

For having a shared environment you could think of the default SASApp server-context serving that one and configure other server-contexts for each project / sas business application.                  

Modifying config_usermods files accordingly will give a solution to your request.

With well setup file systems and a structured way on your OS level you can solve the mentioned design issues by using soft-links (Unix) or the link command (Windows).