Yes, I am talking about standard SAS datasets accessed via the base engine. I discourage you from putting SPDE/SPD Server on the same machine as LASR.  Those two are likely to compete heavily for resources, so you are likely to have performance issues if placed on the same machine.  As for other SAS/ACCESS engines... again, I would recommend that the data sources are NOT placed on the same machines.  Of course you will likely still need to use the SAS/ACCESS engines to pull the data to the SMP server.  Once that is done, the choice is now yours...  As I said, you can place it into datasets on that machine, or stream it directly into memory.  Streaming it directly into memory clearly is faster than writing it to disk, just to read it back and put it into LASR memory.  But if pulling data from the remote source is slow for whatever reason, it is sometimes good to have a local copy. ... View more

@sat_lr, as an R&D person, my expertise is in the technical details and implementation of our product-- unfortunately, I am not that familiar with what our competitors offer.  I have sent an email to a group of people who will be able to provide more information.  Stay tuned for more information. ... View more

I understand your concern about access to LASR from AMO, EG and DI Studio and whether those access points are secure.  The LASR server is quite secure-- even a user that has the ability to write any SAS code they want can only access LASR tables if they've been given explicit permission.  There's two security models, but one or the other is always in play and without permission, you can't get in.  There are, of course, best practices that should be followed to ensure that data is secure.  Even a building with the highest quality locks is only secure if the doors are closed and locked. ... View more

You seem to have jumped to some incorrect conclusions... "As of the 'ïn memory analytics processing' the executing in memory proces (service) is not isolated from the requestor(client),   There has no service oriented architecture (SOA) has been implemented for this." The LASR Analytic Server is completely isolated from the web application server on the midtier.  The midtier makes requests to the LASR server based on user actions and the LASR server performs the analytics and returns the results.  There is well defined SOA in play. "There is a need to isolate the old SAS procs not running in this environmet." I am not sure what you mean by this statement.  Old SAS procs run in a workspace server, not on the LASR server, so they are isolated.  There is nothing preventing the the old procs connecting to LASR via the SASIOLA library engine. "As there is no isolation in processes you are trying to solve the concerns about security in a programmatic way. IMO that ia a dead end. Just follow the issues about virus-scanners, running at root-level like PHP usage SQL injection and more (sans).   When you are really concerned about security it should be a fundamental part of the design." There is complete isolation of processes, allowing the separation of the various parts on separate machines.  Security has been a primary architecture consideration from the beginning and I assure you SQL injection attacks aren't possible.  HTTP connections can be protected via the use of HTTPS and various tiers can be isolated via firewalled zones. In the case of SAP-Hana and other foreign databases with proprietary implementations and SQL dialects, integration is always difficult, but SAS supports explicit SQL pass-through to facilitate the usage of those third-party features.  But most of those third-parties don't provide the analytic capabilities of SAS or support those operations against big data.  ... View more

SAS Visual Analytics Administrator provides a Resource Monitor, that allows you to see what is going on across all of the nodes in the cluster.  It provides real-time feedback on each node's activity.  Unfortunately, we don't yet provide a way to see the historic data about the nodes' activities in VA Administrator.  On the Resource Monitor tab, you'll see a Utilization History line chart with lines representing CPU, memory and network usage. Down below, you'll see a Real-Time View that shows one column per node in your cluster.  In the upper matrix, each square in the node's column represents a CPU on that node.  The brighter the green, the more active a given CPU is.  The lowest two rows indicate the node's memory utilization and network activity. At this time, Environment Manager doesn't provide any additional information. ... View more

Peter, PROC MEANS (and all of the traditional procedures) do NOT take advantage of the LASR server.  In order to do the work in LASR, you need to use PROC IMSTAT.  If you use the SASIOLA library engine to access data resident in a LASR server from a SAS session, be careful.  If you run something like PROC MEANS against LASR data, SAS will pull all of the data out of LASR back to the SAS server to do the calculations.  That might worth for a small data table, albeit somewhat inefficiently.  Remember, however, that LASR is capable of holding tables in excess of several terabytes in memory-- attempting to perform a traditional SAS calculation, such a PROC MEANS on a a really large LASR table, you may swamp your SAS server. But that is why we created LASR.  SAS wasn't able to scale to perform fast calculations on billions of rows of data, so we needed a different approach.  Hope that clarifies thing, David. ... View more

I know it isn't what it needs to be and we are working on major improvements for our Fall release.  I am not at liberty to provide details at this time, but thing will get better, I promise. ... View more