JuanS_OCS Tracker

Re: How can SAS Web Application users be tracked on a SAS Linux platform?

JuanS_OCS — Thu, 09 Apr 2026 13:00:19 GMT

what you are asking is quite extensive. One could literally write a book about those topics. I would initially like to point you to the SAS documentation (wondering which documents you found so far), else SAS Professional Services or a trusted technological partner. (And, as side topic, I would also highly encourage your company to upgrade from M6 to latest maintenance in M9 with the latest hotfixes and security patches).

I will try to address your questions but providing some perspective, which might not be what you can find on documentation.

The web applications provided by SAS are no different from other web applications that are built in Java. What you need to keep in mind is:

- Your web app servers are tomcat alike. And they serve basically J2EE applications.

- You have an apache load balancer.

- Authentication and URL re-directions will be mostly governed by the SAS Metadata in one way or another.

- As any java web application, Log4J (now v2) rules your logging level, what informs, where and the rolling of the logs, based on the java libraries you enable and at what level (INFO, WARN, ERROR, DEBUG, TRACE)

- One of the applications is the SAS Environment Manager, which acts like an in-house data collection of your SAS system (however should never be your main monitoring tool, since it depends on several SAS services to be healthy and running).

- You could enable the extended monitoring (the so called EMI framework, which includes ACM and APM, as shared by @SASKiwi ) for SAS Environment Manager. This is a collection of scripts which will extend the level of information of your logs, and will add reports (and Stored Processes reports) and services and metrics being collected. - if you enable this, you need to set some cleaning of your EMI database in postgres, to ensure your system won't collapse of the amount of data collected.

If you manage to understand those foundations, you can understand all you need towards monitoring and auditing your SAS system, specially your SAS Web Applications. I mean it. Any web administrator or security expert based on Java web apps should be able to follow up and provide advice.

Indeed, SAS 9 is not the same as SAS Viya. There are many differences and improvements in SAS Viya towards auditing and monitoring, and make IT standards even more visible. Listing those differences could take a while.

I would like to point you to:

SAS Intelligence Platform: Overview
SAS Intelligence Platform: System Administration Guide
SAS Intelligence Platform: Security Administration Guide
SAS Intelligence Platform: Middle-Tier Administration Guide

Re: SAS Grid Installation Query and Plan file generation query

JuanS_OCS — Tue, 13 Jan 2026 08:57:17 GMT

Hi @start4mzero ,

I am now a little confused by what you are proposing/intending to achieve, or I might not be understanding well.

To clarify my previous comment:

- while /home binaries could potentially be in NFS, not all under a single same /sashome folder. You still want different NFS filesystem per SAS layer (eg /sashome/meta, /sashome/comp & /sashome/web)

- NFS might be suitable, but depends a lot of your configuration. A SAS tested DFS is definetely more recommended.

https://communities.sas.com/t5/SAS-Communities-Library/Contemplating-shared-file-systems-for-SAS/ta-p/468263

https://support.sas.com/resources/papers/proceedings17/SAS0569-2017.pdf

- you always need to prepare a plan file, custom to your designed deployment. However, if you follow above, there should not be a lot to customize.

A last note, in terms of recommendations:

Not for Sharing SAS 9.4 Deployment Files Across Meta and Middle Tiers:

The section above mentioned using a shared file system to host SAS 9.4 deployment files (software and configuration) for the SAS 9.4 compute tier software

However, the SAS 9.4 meta and middle tiers follow a different availability paradigm. We prefer that each host for the meta and middle tiers have their own local SAS software and configuration files

And even more importantly, never direct the SAS 9.4 Deployment Wizard to install one tier's software and configuration into the same physical directories for a different tier. In that way lies madness.

Re: SAS Grid Installation Query and Plan file generation query

JuanS_OCS — Mon, 12 Jan 2026 13:27:04 GMT

Hi @start4mzero ,

these kind of decisions should not be done at deployment time, but during the architecture sessions.
There are many variables involved.

For example, the fact that you are using NFS, instead of an Distributed Shared File System (DFS) has many implications for the questions you are posting. How will NFS will handle it? Files/blocks locking? Performance? Limitations of NFS (based on version and platform used)?

In general, and just to answer to your questions, very generally - but please mind my previous comment(s):

1- 1 time shared binaries /sashome should be enough. In all tiers. However I have no clue how your NFS will behave with such dependency. MIght create serious issues when you reach Production workloads. I suggest thorough testing and validation, and risk management.

2- I don't expect, by default, differences in the plan file. But of course all depends on architectural decisions

Re: Latency numbers of On Prem SAS/ SAS Viya and On cloud SAS Viya on AWS

JuanS_OCS — Mon, 12 Jan 2026 11:22:28 GMT

Hi there,

in general terms, SAS indicates that all layers of a SAS environment must stay as close as possible, preferably in the same datacenter. Specifically to minimize network latency while increasing network throughput data transfers.

Of course connections can be done towards outside, or from outside. But then you need to deal with all the aspects related to latency: timeouts, slowness, performance degradation, loss of packages and noise, etc.

As such, you really want low latency numbers. As close as possible as being part of the same datacenter. Meaning, preferably within single digit milliseconds, 2 digits max (I'd say no much more than 20 ms).

A (more complete) answer from AI, which should be taken with salt and pepper, but overall I can agree with it:

For a SAS environment with external connections, good latency means low single-digit milliseconds (ms) for interactive tasks like Enterprise Guide, while high throughput (hundreds of MB/s) is crucial for large data moves; slow network links (VPNs, high-latency internet) can severely degrade performance, emphasizing the need for fast, direct connections, ideally <20ms for cloud/remote, and very low internal SAS Grid latency for coordination, with <100ms overall being desirable for responsive user experience.

Key Latency & Throughput Factors

User Experience (SAS EG/VA):

<20ms: Excellent for fast, responsive work over LAN/direct cloud links.

20-50ms (Cable/Fast Internet): Generally acceptable but noticeable lag for some actions.

50-100ms+ (DSL/VPNs): Can cause significant delays (5-10s) due to aggregated small requests, frustrating users.

SAS Grid/Viya (Internal Nodes):

Very Low Latency: Essential for node-to-node coordination (e.g., 1-5ms).

High Throughput: Critical for loading data into memory (e.g., 100+ MB/s per core).

Cross-Prem/Cloud Data Movement:

Network Speed (Bandwidth): High latency can severely limit throughput (e.g., only 500KB/s to 20MB/s over some cloud links).

Physical Distance: Major contributor to latency; keep SAS and data close.

What's "Good"?

Aim for Sub-20ms: When connecting from outside (e.g., laptops, remote offices), aim for <20ms latency to the SAS environment (e.g., via dedicated circuits, ExpressRoute, fast VPNs) for a snappy feel.

Measure Throughput: Ensure you have hundreds of MB/s available for data loads, not just low latency.

Isolate Workloads: Use dedicated network paths (VNETs, subnets) for SAS nodes to avoid contention and latency spikes from other traffic.

In summary, think beyond just latency: low latency provides responsiveness, but adequate network throughput is vital for moving large datasets efficiently. For external users, <20ms latency with high bandwidth (100s of MB/s) is the goal for a good experience

Re: SAS grid Architecture consideration

JuanS_OCS — Mon, 15 Dec 2025 12:45:19 GMT

I think this is a tricky question. With NFS you will always hit some important limitation (google it).

Also, NFS has different limitations depending on the version of the protocol, the implementation, and the infrastructure/cloud.

Another reason why makes it tricky.

Normally, for Grid data or Grid SASWORK, I would rather use a proper Distributed Shared File System, which will face less limitations and risks, on top of higher performance. But, of course, those tend to be expensive solutions for storage.

Do you need SASWORK on shared storage, meaning, will your programs include checkpoints, so your programs can resume from defined points. If you don't I would strongly suggest to run away from the option to put SASWORK/UTILLOC in a shared storage. Local makes more sense.

And if you do need it, and you don't have a DFS available, then try to find your NFS options with your infra team, and try to run enough tests and stress tests, to ensure your Production workloads will go as you expect.

Re: Single machine SAS 9.4 Deployments

JuanS_OCS — Sun, 06 Jul 2025 19:02:54 GMT

The option is about the sizes of the Java Virtual Machines, as described in the MidTier admin guide, fine turning chapter.

Re: ERROR: Error retrieving DatabaseMetaData: java.sql.SQLFeatureNotSupportedException: getTypeInfo

JuanS_OCS — Thu, 19 Jun 2025 20:15:49 GMT

Excellent, thanks! I am planning on testing all the options and figure out the differences, especially in basic performance 😉 I am curious about your progress too!

Re: ERROR: Error retrieving DatabaseMetaData: java.sql.SQLFeatureNotSupportedException: getTypeInfo

JuanS_OCS — Thu, 19 Jun 2025 15:36:17 GMT

FYI, I see it is resolved with the latest version 1.3.1.0

83         libname x JDBC driverclass="org.duckdb.DuckDBDriver" URL="jdbc:duckdb::memory:"
83       ! classpath="/data-drivers/jdbc/duckdb_jdbc-1.3.1.0.jar";
NOTE: Libref X was successfully assigned as follows: 
      Engine:        JDBC 
      Physical Name: jdbc:duckdb::memory:
84         *libname x JDBC driverclass="org.duckdb.DuckDBDriver" URL="jdbc:duckdb::memory:"
84       ! classpath="/data/duckdb_jdbc-1.3.1.0.jar";

Re: The Quack is Back: SAS/ACCESS Meets DuckDB

JuanS_OCS — Thu, 19 Jun 2025 13:30:11 GMT

Great article @jarno , thanks!

Any experiences in SAS 9.4? And with multi-database support (https://duckdb.org/2024/01/26/multi-database-support-in-duckdb.html) queried from SAS?

Re: implementation of SSO for SAS Fat clients SAS EG, SAS DI Studio & SMC

JuanS_OCS — Mon, 16 Jun 2025 11:02:18 GMT

Hi,

yes, you will need SPNs and a UPN, and to enable (contrained) Keberos delegation.

Again, it is all well documented by SAS: https://documentation.sas.com/doc/en/bicdc/9.4/bisecag/n1d1zo1jsf2o0en1ehu4c4simfky.htm

If what you need is an overview, you can find a nice one provided by @PaulHomes here: https://platformadmin.com/blogs/paul/2015/01/iwa-sas-94m2-linux/

It is based on an old maintenance (2), but I am sure that, by reading the documentation provided by SAS, you can make the adjustments required for your actual SAS environment.

Kind regards,

Juan

Re: implementation of SSO for SAS Fat clients SAS EG, SAS DI Studio & SMC

JuanS_OCS — Mon, 16 Jun 2025 09:58:13 GMT

Hi @siddhu1 ,

since your servers are on Linux, you are bound to set up Kerberos IWA system between the servers and your clients (and, preferably, between your SAS servers and your DBMS).

IWA with Kerberos is described in the SAS documentation. If you have any more specific question, please feel free to raise those questions!

Best ,

Juan

Re: Questions regarding rebuilding Windows services for SAS Web App Servers in SAS 9.4M7

JuanS_OCS — Sun, 25 May 2025 17:31:07 GMT

Hi there,

The reason is that the Web App Servers can be started/operated in several ways: with the windows service, with the individual command, etc. That's the reason why both confit files exist and why both should be maintained keeping always the same configurations. The best practice is of course the wrapper.conf, however, as far as I know, due to some traditional scripting and operations it has been decided that both need to remain. But probably its best if someone from SAS answers you that one.

I hope this answers your questions?

Re: SAS Encoding conversion

JuanS_OCS — Thu, 13 Mar 2025 18:41:59 GMT

Hi there,

You have 2 options (more, but I’ll simplify):

The code approach and the configuration approach.

In the code approach, and since your SAS session run on wlatin, you would need to use the transcoding facilities SAS provides, quite intensive, for all the activities related to snowflake/Unicode/UTF8.

On the configuration approach you could have an extra SASApp, but running SAS on UTF8, for those operations. As side option, you could just call SAS executable, but passing a sas9.cfg file defining UTF8 encoding, just for that migration.

Re: I need help using sas with unix commands

JuanS_OCS — Thu, 06 Mar 2025 13:11:09 GMT

Hi @Universe ,

perhaps I am not understanding you, as you are requesting help with code, however it seems to me as your issue is with permissions. If the user that is owner of the SAS process does not have the right permissions, it won't be able to perform certain actions. You probably should align with our Unix admin.

This being said, I can see your code is quite elaborate for the required listing for which I commend you for.

However, since you are already using linux commands, perhaps you could use linux commands to do that job, much more simpler and with less lines of code.

Some examples:

tree -nf  | awk '{printf $0} {system("stat -c \" [ %y ]\" " $NF )}'| sed -e 's#\([0-9][0-9]:[0-9][0-9]:[0-9][0-9]\).*#\1 ]#g'  2>/dev/null

ls -Rl --time-style=long-iso /path/to/directory

tree -D

Re: Retrieve List of active users and information

JuanS_OCS — Mon, 03 Mar 2025 14:00:11 GMT

Hi @Jed_Klei ,

you might want to look into the sas-admin CLI https://documentation.sas.com/doc/en/calcdc/3.4/calcli/n01xwtcatlinzrn1gztsglukb34a.htm

You can also query, programatically, through the RestAPIs SAS VIya offers:

https://developer.sas.com/rest-apis

Re: CPU usage in the Viya 3.5 platform

JuanS_OCS — Sun, 23 Feb 2025 02:18:32 GMT

Hi there,

Considering the fact that 2 of your 3 options are related to Python and not to SAS, I would start at looking what exact system processes and or services are the ones going up in cpu.

There’s also the aspect of coincidence. Several things happening at the same time: try to filter them down and observe which one in fact causes the pattern of the problem.

In any case, do align with your SAS and system admins, and feel free to share (with us and/or SAS tech support) your further observations when you are still unable to get a conclusion on your own.

Re: ODBC Connection from SAS 9.4 M6 on Windows Server Cannot see tables.

JuanS_OCS — Thu, 20 Feb 2025 03:42:37 GMT

Hi there,

In these cases I like to understand what’s going on behind the scenes, so I can pinpoint exactly the issue, instead of going through trial and error.

For that I always refer to the logs on the client side (ODBC client) and the database server logs (audit).

You clearly have an issue with permissions, as you have been told. There is no mistake there. Whether it’s a wrong schema or username or something else, we need to figure it out, thanks to those logs.

The server logs should already tell you a lot. Have you asked your DBAs what do they see when you connect with SAS?

From the client side, you either use STRACE or enable the client logs (ODBC ini for ODBC connections).

My personal thought, but this is without knowing more of your setup and design, is that either your connection to the schema is different from SAS to Java, or you are connecting with your OS user on top of the user in the lib name statement.

Would you mind sharing as well your exact code used in Java?

Re: Need to Delete EVManager DB to complete Mid-Tier Installation/Configuration

JuanS_OCS — Thu, 13 Feb 2025 13:10:56 GMT

Hello @CCC1492_ME , Mark,

several questions come to my mind, of the kind of:

- what could force you to have to delete this DB to be able to continue the deployment

- or, why are you not reaching out to SAS Technical Support, as already advised?

It is a bit mind boggling to me so I cannot give you much more advise. My reasons:

- EVManager database is integral part of your deployment, plus part of the Environment Manager product. You really don't want to mess up with that and you want to do what is supported. Right?

- What is supported is documented, and what SAS Technical Support or professional services provide, period. Even SAS partners have to adhere to those aspects, and what does not adhere, is not officially supported.

- It is a normal database: undeploying the Environment Manager products or just deleting the database with the admin account would achieve exactly what you indicate... BUT, is it supported? If you still find issues, who will lend you a hand? You would be basically on your own and up to your own talents.

Re: SAS Metadata Scheduled Flow Migration

JuanS_OCS — Wed, 12 Feb 2025 13:28:33 GMT

@Key123 : yes, I mean that you can redeploy and reschedule manually (that would be my approach) in SMC after the metadata migration (which you can automate with the SAS Platform Object Framework).

While it is possible to reschedule with any metadata account for as long as the Outbound login has the right permissions in LSF, the OS folders and the metadata user has the right permissions over the metadata you could potentially use any account to redeploy the jobs, and to schedule them.

However, you are going to need to look into the implications of using an elevated account, and to ensure that the scheduled jobs will use the right credentials for the execution, file ownership, connection to databases, etc. That is for you to evaluate and decide.

This being said, I do not know how your users schedule and deploy jobs and flows (it depends on the design), which what user, if there is a common user for them, etc etc.

I say this because Batch Jobs are supposed to be controlled workflows. All what is controlled, there should be just one or a limit amount of privileged accounts to deploy and schedule, in the end. However, if your users are using Batch as self service, that is a different story, and, indeed, the implications on security vs investment of work are much different.

Let me add: in the communities there is a limit as to how much we can help you without knowing details on design and security of your environment. When they get complicated, I would encourage you then to reach out to SAS Professional Services or a trusted SAS Partner, specialised on this area.

Re: How to Containerize a SAS Viya and GenAI Application

JuanS_OCS — Wed, 12 Feb 2025 11:41:23 GMT

@Bogdan_Teleuca excellent article, thanks!