Please note that in SAS Viya 3.4 you actually have two versions of SAS Studio. url .../SASStudioV/... this is SAS Studio 5.1 using a SAS Compute Server to run your code, it is integrated in the the application menu, top left, 3 vertical lines url .../SASStudio/... this is SAS Studio 4.4 using a SAS Workspace Server to run your code, it is not integrated with the application menu, your link mentioned refers to this   the following macros vars give you more details: %put NOTE: &=SYSVLONG; %put NOTE: &=SYSSCPL; %put NOTE: &=SYSPROCESSMODE; %put NOTE: &=SYSPROCESSNAME; %put NOTE: &=_CLIENTAPP; %put NOTE: &=_CLIENTAPPVERSION; %put NOTE: &=_CLIENTMODE; ... View more

We're certainly planning on releasing Studio 5.x on SAS 9 but don't yet have a date to announce.  What's happening in R&D right now is work to bring 5.x up to replacement value for 3.x.  While there are spiffy new things in 5.x, it still doesn't have everything 3.x does.  When I have more firm info, I'll certainly post it! ... View more

The issue is that string fields in Hive/Impala don’t have a defined length, so when you point SAS (and other tools) at these tables, they have nothing to go on in terms of how long the content in them is. Taking a recautionary approach, SAS allows for them to be up to its maximum length, 32767 (or whatever you set it to), to avoid as much truncation as possible, but it’s a one-size fits all approach.   When any data is extracted therefore is treated as having text fields as long as this, and the datasets have these fields are formatted as $32767. in effect. Yes they’ll compress, but that isn’t really the issue. The issue is that the data being sent from the Hadoop server to SAS is treated as being this wide, and effectively your transferring way more bytes, a lot of them ”blank” to SAS, at which point they will get compressed. The transfer of “wider” data than it really could/should be introduces elapsed time.   I was lucky enough to be testing on an environment where the SAS servers were on one side of a WAN, with Hadoop on the other. I say “lucky” because you learn more from a badly configured/performing environment that an optimally set up one.   Yup, Viya support fields with much more diverse formats and types than SAS, which is a very good thing that should help in these circumstances, but I’d contest that there are multiple additional reasons to surface tables with fields that have defined lengths relevant to the range of content they actually contain than just embracing Hadoop et al’s ability to "not care".   For instance, a Gender field that presents as $1 makes it pretty obvious what’s going on, and this is what you get with a view that casts string field to varchar(1).   I’d have to dig out my stats, but the compressed datasets from “native” tables with string were (much, I recall) larger than the compressed datasets from the views. ... View more

I have the same issue. Can someone please let me know the resolution. ... View more

I can't speak for SAS Studio, as I haven't yet used it, but Enterprise Guide provides a menu choice to export a whole process flow as SAS code. So I suspect SAS Studio should have a similar option.   The reason why I suggested this is that to run a Studio project flow, you need the Studio engine to interpret it. With SAS code in a .sas file, you just need SAS Foundation. Aside from the fact that a .sas file is simple text and can be viewed/manipulated with any text editor. ... View more