Architecting, installing and maintaining your SAS environment

Multiple SAS Work areas for multiple users/groups

Posts: 24

Multiple SAS Work areas for multiple users/groups

Hi All,

I am using SAS 9.3 and have the requirement for directing two group of users to use separate temporary saswork areas.

Could anyone please help me or guide me in acheiving this?

Look forward for your reply.

Thank you

Valued Guide
Posts: 3,208

Re: Multiple SAS Work areas for multiple users/groups

Posts: 24

Re: Multiple SAS Work areas for multiple users/groups

Thanks Jaap for the reply.

My concern is irrespective of tools. I have two saswork areas and want to point one set of users to use 'X' sas work area and the other set of users to 'Y' sas work area in sas 9.3 environment when they invoke their sas session.

They may use sas 9.3 tools such as Data Integration Studio or EMiner or Base sas 9.3 etc.

Is it possible to do so?

Trusted Advisor
Posts: 2,113

Re: Multiple SAS Work areas for multiple users/groups

It is reasonably straightforward.  A couple of ways

-- modify the call to sas to explicitly point to the require work area (look up the option -SASWORK for syntax).

-- modify the call to sas to point to different configuration files and change the location of SASWORK in there.

How you call SAS depends on your operating system.

Doc Muhlbaier


Valued Guide
Posts: 3,208

Re: Multiple SAS Work areas for multiple users/groups


The other reply was pointing in the dierction of the irrespectivity of tools. Therefore I made the reference.

Aside the version (9.3) It is very important to know the OS environment (windows/Unix) and the way of working (Desktop/ Client-Server - Server).

Within a Windows desktop environment it makes not much sense to think about segregated workfiles.

More Ram and faster IO (SSD) is easier and more profitable to incerase speed. You are the only user on the machine.

Do you want to have more workfiles the hardware (more dasd units) should be present and capable to get some profits, mostly that is the botteleneck..The -work options at a script to start or a own config-file will do. Pointing to a local dasd and not a remote fileshare is very advicable.  Iit normally part of "Mydocuments) user based.

Within a Windows or Unix Server environment a lot more users are being expected. They can interfere each other and also possible get into blocking issue by running out of resources. So monitoring and tuning the system should get attention.
As in most modern installations like SAS 9.3 are using the BI/DI server I mentioned the segregation in that environment. All the modern tools like Eguide AMO (Connect) are running with a registration / configuration in the App-server-context defined in the SAS metadata. Basically the _usermod files are te same as the old autoexec/config approach on the OS level.

It has become a nested approach now.

The SAS metadata hes been designed for grouping users according the Enterprise organization. That is conform your question.

There are some samples causing the misundertanding as it would be designed with tools in mind.. wrong...wrong ...

The education samples of SAS are using "Orion Star" fully based on grouping users according the organization. It is named Enterprise Intelligence Platform (EIP) for that.

Some exceptions with EIP could be there, as:

- Classic SAS (is bypassing SAS metadata) direct via the DMS approach or by batch executing (including the LSF based start)

- Classic SAS/connect as with 9.3 it still not controlled by SAS-metadatastrcutures
In those cases the old approach of dedicated autoexec and config as usermod setting can be solved within shell scripting. It will deliver the same functionality as the appserver (metadata) approach by that.


Within Unix the mountpoints are meant for isolation of files/data. You can define a lost of them with all their  own performance properties. Having the mapping names you can also group them to users (type of usage) as you like/want. 

The best hardware and connection would be advisable (performance troughput).

Within Windows(server) the IO approach is different as the split and rearrange of data is less architected on this point. With the virtualization level a part a lot should be made possible..  

---->-- ja karman --<-----
Posts: 24

Re: Multiple SAS Work areas for multiple users/groups

Hi Jaap,

Thanks for the explanation.

We are having about 1000 users using SAS 9.3

The tools are hosted on our unix sunsolaris server and desktop clients are installed on client's machine. So basically client-server architecture.

Earlier we used to have a single saswork area, but now we are dividing the users as per the projects and hence want to have two saswork areas,so that we can differentiate the usage between the two groups.

We have sasv9.cfg file  and also sasv9_local.cfg in sasroot. We have created the new saswork area with 100GB of space and want a set of users to use the newly created saswork area.

Can we update or provide any options in the sasv9.cfg file in order to achieve our objective?


Regular Contributor
Posts: 213

Re: Multiple SAS Work areas for multiple users/groups

Hi Abhijit,

For such number of users, I would recommend utilizing two separate -UTILLOC system option settings beside having two separate -WORK areas.

You can create a shell script that

1. Works out which WORK (export userWork=) & UTILLOC (export userUtilloc=) path to use based on User Id trying to launch it

2. Wraps the SAS executable command inside it, and specifies the -WORK $userWork -UTILLOC $userUtilloc invocation options.

Hope this helps,


Valued Guide
Posts: 3,208

Re: Multiple SAS Work areas for multiple users/groups

Hi Abhijt,

Ahmed is right to mention the utilloc option. It will isolate the IO caused by utilities like Proc SQL , Proc Sort using temporary data. That utilloc option has things like roundrobin selection,

The configuration is changing fast with a growing lot of instances and variations.
As Sun/solaris is an old name (oracle) now I assume a lot of historical grown practices. Your environment is C/S but can be of BI/DI style (use of Eguide Amo DI Miner etc) or the classic one,  SAS/Connect with SAS on desktops and Batch with eg LSF.

BI/DI style. (The structure is almost the same with 9.3)  

SAS(R) 9.4 Intelligence Platform: System Administration Guide (Overview of Configuration Files) These are the basic ones.

See the remarks to not change the old well known names but the _usermod versions of them.

The sasv9_local is a site specific one for all SAS processes on the machine including the metadata server and Object spawner server. It is better to use this one with that goal and not for user-segregation.    


SAS(R) 9.4 Intelligence Platform: System Administration Guide (Reference: Configuration Files for SAS Servers) These are the one for the APPlications-servers defined in the SASMETA dataserver.

You need to do the variations in the /Lev_/...._usermod....  files to segregate the users. You are needing several app-servers for that. It is configuration step. The challenge is adding appservers and a Portnumbering scheme

SAS(R) 9.4 Intelligence Platform: Application Server Administration Guide (Defining Multiple Application Servers)

The deployment wizzard  will also aad the directories on the OS level. Adding servers with SMC is possible but those directories are not created. There is no convention mentioned for the needed additional portnumbers. It depends on the complexity.

Just one convention: You can have a Multiple level environment. By this convention the last numer is the same as the used level.

SAS(R) 9.3 Intelligence Platform: System Administration Guide, Second Edition Port Numbering in a Multiple-Level Environment


With batch and some of the SAS/Connect options you need to make it scritped. (export etc... see Ahmed remark)

The most easy way is a Unix script (wrapper) with parameters and then the correct settings/config etc.

hmmmm ....

1000 users and Sun Solaris (single machine). I get the feeling you have some performance issues.

---->-- ja karman --<-----
Ask a Question
Discussion stats
  • 7 replies
  • 4 in conversation