SAS Platform Admin Blog

Issue: We have several jobs on waiting status in IBM Platform Process Manager 9.1. Solution: IBM support team suggested us to add the parameter below to avoid creating new login shell for the submission users for each job triggered from PPM side: JS_SU_NEW_LOGIN=false You can find this configuration in js.conf file located at /pm/conf. bash-4.1$ grep JS_SU_NEW_LOGIN js.conf JS_SU_NEW_LOGIN=false # Default is JS_SU_NEW_LOGIN=true Side effects: There is one downside of using this parameter, that it will not get user's $HOME/.profile sourced so any environment variables set there will not be seen in job execution environment. PPM submission to LSF is by default using "su - username -c 'command' " and the dash here implies user login is invoked souring the $HOME/.profile file. When we added JS_SU_NEW_LOGIN=false to our Test environment, it broke some jobs for user that depended on variables defined in user $HOME/.profile. We resolved it by sourcing t

Issue: We deployed a new SAS Software in SAS Web tier. While restarting the web services we were unable to bring up the services. We found out below error message from the web logs (/Lev1/Web/Logs/SASServer1_1): com.atomikos.icatch.SysException: Error in init: Error in recover We reached out for tech support and after the investigation he found out that it is PermGen issue. Solution: A restart of the SAS web application server instance would temporarily remedy this situation and get you back up, but it would likely re-occur unless it was caused by some unusual usage scenario. SAS TS took JVM memory settings from the log, and he discussed this with their performance expert to see if we may need to tweak some JVM arguments. He also suggested that it may also require some more in-depth GC logging in order to determine the root of the issue. After futher investigation it is found out that it occured due to heavy OLAP/Cube usage and  PermGen issue again. This is a known issu

Whenever you face any issue with Web Tier like not able to bring up, restart failure you need to go and check logs. Logs are present in two location: SASServer1_1 server logs - /Lev1/Web/WebAppServer/SASServer1_1/logs SAS web application logs -  /Lev1/Web/Logs/SASServer1_1 To find today's log with error, you can use below command in Linux/Unix: find /Lev1/Web/Logs/SASServer1_1 -type f -name "SAS*.log" -mtime -1 -exec grep -H ERROR {} \; find /Lev1/Web/WebAppServer/SASServer1_1/logs -type f -name "SAS*.log" -mtime -1 -exec grep -H ERROR {} \;

I have noticed that License Warning messages are still showing up when running a DM Job in Batch mode DataManagement Log: 2015-12-14T07:48:05,767 WARN  [SAS] base state GRACE 2015-12-14T07:48:05,769 WARN  [SAS] di_ent_resoln state GRACE 2015-12-14T07:48:05,773 WARN  [SAS] di_dataflow state GRACE 2015-12-14T07:48:05,774 WARN  [SAS] quality state GRACE Check whether configuration file points to new license location Data management license location - /DataFluxDataManagementServer/2.6/dmserver/etc License config file - app.cfg Inside app.cfg serach for base/primary_license_loc. It should be base/primary_license_loc = /DataFluxDataManagementServer/2.6/dmserver/etc/license/license.lic You can place your license in any location and mention that location in base/primary_license_loc.