About ICI_SAS_Admins

ICI_SAS_Admins · ‎11-30-2017

Thank you for the suggestions. They led me to the answer as found in another posting https://communities.sas.com/t5/SAS-Enterprise-Guide/Syntax-Error-Quotes-in-Macro-Parameter-Generated-by-EG-Prompt/td-p/394370 The solution was to add the %unquote to the code as follows: %put &libby; libname pully %unquote(&libby); This is apparently due to Enterprise Guide adding something to the prompt as can be seen in another line of the log that I missed: 10 %LET libby = %nrstr(%")/sas/data/research/Retirement/Permanent Datasets/%nrstr(%");

ICI_SAS_Admins · ‎11-30-2017

I am submitting the following code using a prompt in Enterprise Guide 7.13 HF5 being sent to process on a Solaris 64-bit 9.4M2 Unix SAS server: %put &libby; libname pully &libby; The prompt appears to be resolving for the put statement but something weird is happening for the libname statement giving me the following log: 39 40 %put &libby; "/sas/data/research/Retirement/Permanent Datasets/" 41 42 libname pully &libby; ERROR: Libref in LIBNAME statement must be followed either by quoted string or engine name or semicolon; """ found. ERROR: Error in the LIBNAME statement. Can anyone explain why this is not working? -Shaun

ICI_SAS_Admins · ‎11-20-2015

We have a library of SAS stored processes registered in SAS folders. The current storage methodology has become cluttered and unmanageable. We would like to implement a new organization structure for the SAS folders. We are able to export a SAS package, delete the original stored processes and then import the SAS package into the new SAS folder. However, after doing this, any references to the original stored process in Enterprise Guide projects or SAS Add-in for Microsoft Office files generate an error message. It appears that even trying to change the name of the stored process without moving to a new SAS folder also causes errors. This leads me to believe that the reference to the stored process that is stored in the EG projects and the SAS AMO files is a text reference to the pathed location of the SAS object (in this case a stored process). I know that every object in the SAS metadata has a unique id. Is there a way to link the stored process to the EG project or AMO file by this id rater than by name and location? Is there some other way that I can maintain a functioning link to a stored process, but still have flexibility to move it to a new SAS folder and/or change the name? --Shaun

ICI_SAS_Admins · ‎08-28-2015

I am going to preface this by saying that I am still trying to understand this whole issue, so please forgive me if my comments and questions below don't make any sense. We recently upgraded to Sybase 16. In the process, a new environment variable name LD_LIBRARY_PATH_64 was created on our SAS BI server. I was previously unaware that SAS strongly warns against setting this variable (see 34579 - Errors occur when the LD_LIBRARY_PATH_64 environment variable is defined on Solaris systems ). Now we are receiving errors with our SAS/Access to Oracle connection and our Java Virtual Machine calls. Our Sybase DBA says that he has an easy fix. The link SAS note above says they have two possible fixes. I am not sure if any of the solutions will fix the issue without causing other issues. So I started to do what a good SAS administrator should do and research the issue to understand what EXACTLY is not working. During my research, I found multiple sites that basically say "do not use/modify LD_LIBRARY_PATH for your applications". I even read places that describe commercial products (ex. SAS?) that use this variable described as "lazy programmers" and "bad programming"... two descriptions I generally do not associate with SAS. They suggest that using a localized variable is a much better approach. My understanding is that both LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 are lists of shared directories that are used by ld. So why does SAS use these variables? Why do they not create a SAS specific variable? In addition to still trying to understand this better, I am now curious if it is possible to unravel SAS from the LD_LIBRARY_PATH variables. Has anyone had to do this, or are there any good discussions on this topic? Thank you for your help! --Shaun

ICI_SAS_Admins · ‎01-07-2015

Hi Jaap, Thank you for your comments as always. My question did fail to address the difference between hard/system limits and soft/user-process limits. Our environment has a hard/system limit that is high enough to handle this, but the default soft limits are 256... well below the SAS recommendation. So my questions are specific to the soft limits that are required by the middleware of SAS. (As a side note, we also have an Oracle database that is being managed on a similar UNIX server, but I have been told that the soft limits required for that are much lower.) The links that you sent only refer to changing the soft limits for a specific user (in this case "oracle"). This brings me back to one of my questions "Can this be solved permanently with a .profile change for the user "sas" or does each individual profile that connects to SAS need this change?" If the "sas" user is the only one that is required to have these higher limits, then I can parallel the changes outlined by the link you provided Chapter 11. Setting Shell Limits for the Oracle User. Tangentially, yesterday we manually set the soft limit for open files to 20480 as stated in the SAS documentation and then manually ran the sas.servers script. This "brought the server to its knees" and the systems administrators were getting all sorts of memory and processor usage warnings. This was on a 64-bit quad-core 64GB memory Solaris server. We stopped all the SAS processes and set the ulimit to 2048 (10% of recommended) and was able to successfully bring up the SAS services via the sas.servers script. This issue is definitely something that we plan to bring up with SAS support. Thank you again for your comments and suggestions. I am curious what others on Solaris servers have done for this soft limit requirement. Shaun

ICI_SAS_Admins · ‎01-06-2015

Based on the SAS support web site, installations of the SAS 9.4 Middle Tier on a UNIX server require that "the soft limit on number of open file descriptors be at least 20480..." (see Pre-Installation Steps for SAS 9.4 Middle Tier) We use a Solaris UNIX server, and the UNIX administrators are perplexed by this request... not how to do it, but why it is recommended. Is there a reason it is so high? Is there any significance to the number "20480" in this case? Can this be solved permanently with a .profile change for the user "sas" or does each individual profile that connects to SAS need this change? Alternatively, can this be a command in the SAS component startup scripts or configuration files? We manage SAS services using VCS, so the sas.servers script is not an option. If we put this setting in a script, what individual startup scripts require this ulimit setting? Any information on this topic would be helpful to our understanding of the SAS 9.4 Middle Tier and hopefully help resolve the concerns of our UNIX system administrators. Thank you for your input. Shaun

Online Status	Offline
Date Last Visited	‎06-13-2018 04:24 PM

Re: Libname Not Resolving Using Enterprise Guide Prompt

Libname Not Resolving Using Enterprise Guide Prompt

Maintain or repair stored process relationships in EG and AMO after mo...

Why does SAS BI use LD_LIBRARY_PATH, and can it be avoided?

Re: SAS 9.4 Middle Tier UNIX ulimit settings

SAS 9.4 Middle Tier UNIX ulimit settings

EGP Project deleted on recover!