BookmarkSubscribeRSS Feed
Chickenhouse
Calcite | Level 5

Hi all,

We have 4 SAS environments in our organisation.  DEV, ST, SIT and PROD.  We are about to do a migration so I'd like to remove the use of explicit server names from our SAS Code.  This is particularly helpful for jobs that copy data between 2 environments.  There's an additional complication in that we have 2 environments on 1 physical server. 


Our servers are running on Windows 2008.


We do have "shares" setup on the server so you can point to specific folders based on the share, but different environments have different share names. So in Prod we use RAP but Dev and ST are on the same server so they have shares named RAP_Dev and RAP_ST.

My plan is to request our IT guys to create a CNAME record on the DNS server.  But I would like to be very explicit in my request to avoid confusion.

So a set of typical libname statements might be

Dev Server

libname temp_data "\\vempsas1001\RAP_Dev\temp_data";

ST Server

libname temp_data "\\vempsas1001\RAP_ST\temp_data";

SIT Server

libname temp_data "\\vempsas1003\RAP\temp_data";

Prod Server

libname temp_data "\\pempsas1005\RAP\temp_data";

I would like to be able to use these instead.

Dev Server

libname temp_data "\\SASDEVSRV\temp_data";

ST Server

libname temp_data "\\SASSTSRV\temp_data";

SIT Server

libname temp_data "\\SASSITSRV\temp_data";

Prod Server

libname temp_data "\\SASPRDSRV\temp_data";

Then I could set up a macro variable in autoexec.sas (or some config file) that would refer to the current environment by default.

Eg

%let env = DEV;

would be in autoexec.sas

Then you can use

libname temp_data "\\SAS&env.SRV\temp_data";

in the code.

What CNAME statements would I need to set up to be able to do this?

I've googled for examples of this but have not been able to find any so any help would be greatly appreciated.

Thanks,

Travis

7 REPLIES 7
SASKiwi
PROC Star

I think there is a problem with what you are proposing. CNAMEs are simply aliases for physical server names. You still have the problem of inconsistent folder shares. I suggest changing your shares as I have highlighted in bold so then you can reference them by your macro variable:

Dev Server

libname temp_data "\\SASDEVSRV\Dev\temp_data";

ST Server

libname temp_data "\\SASSTSRV\ST\temp_data";

SIT Server

libname temp_data "\\SASSITSRV\SIT\temp_data";

Prod Server

libname temp_data "\\SASPRDSRV\PRD\temp_data";

Regarding CNAME statements. In my experience IT folks know how to do this so you don't need to tell them how to do their job.

Chickenhouse
Calcite | Level 5

Hi,

Thanks for your help.  If the CNAME can only be done at the server level then yes I guess its a standard job for the IT guys.

Of course giving each environment it's own share name fixes the problem.  So I guess in our case we set up two CNAMEs for the same server that holds DEV and ST.  Then use the share to distinguish our data folders.

I could even make the macro

%let env = \\SASDEVSRV\Dev; 

to simplify coding.

I guess now my issue is how to determine which environment I am in, within the autoexec.sas (is that the right place).  Can I check the port number to distinguish between Dev and ST?

Thanks,

Travis

SASKiwi
PROC Star

What I've done is query the SAS App context by checking the SAS option metaautoresources - see PROC OPTIONS. This records the value SASApp for example if that is the name of your 'top' level SAS server.

Your second SAS server might then be called SASApp2. This is the common naming convention but of course this can also be customised. METAAUTORESOURCES will tell you what yours is. 


Chickenhouse
Calcite | Level 5

I've set things up as you've suggested.  It works great for libname statements etc.

Now I've got another issue.

I've found some code that uses the &SYSHOSTNAME macro variable.

    %if &SYSHOSTNAME. = VEMPSAS1001 %then

        %do;

How can I use the alias SASDEVSRV in a similar way?

SASKiwi
PROC Star

I used a low tech solution for this and created an AUTOEXEC program on each server that defined a macro variable: %let Server_CNAME = SASDEVSRV;

There is an EG macro variable that may be useful _SASHOSTNAME, but isn't available in other SAS environments like batch, stored processes etc.

jakarman
Barite | Level 11

Your problem is about a segregation of servers shares and your goal is not having any differences in your business code.

What you can do is having a location defining your environment setting (some/scripts sas macros). 
Have every machine being defined and give it your logical definition settings. (something functional als your idea of cnames).

Than use that logical logical setting you are fully in control to get the results for physical namings. When doing this at the OS level (environment var) you can use those in the physical namings of libraries/filenames (data) with an exclamation point. When you ant to use libname / filename concatenation having the advantage of avoiding versioning questions (code) you can do that also.

With a mainframe background having thight release management and version processes this kind of structure is more easy to understand oppose to the PC cowboy approach.

Having the DTAP for code / data in place the next one is the metadataserver and the segregation of RBAC roles organizational and by business applications using the appservers and metadata-controls
How advanced do you want to have it. The advanced approach is fulfilling common regulator requirements. No you do not find this as a concept documented by SAS institute (failing in alignment). 

---->-- ja karman --<-----
jakarman
Barite | Level 11

@saskiwi   lowtech and highly sophisticated as it is KISS

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 2557 views
  • 4 likes
  • 3 in conversation