About MargaretC

MargaretC · ‎06-02-2019

On line 26, the FILENAME statement is trying to assign a physical path name for a file to the symbolic reference IN. as you can see, there is a WARNING that the &infile1 did not resolve to a file. This is bad. On line 30, the DATA step has an INFILE statement that is trying to resolve IN to the physical file. And since this does not resolve to a file, the DATA has no data to read in, and thereby the step fails. Does this make sense? Margaret

MargaretC · ‎05-16-2019

Greetings everyone, I just wanted to share with you the link to my updated “Important Performance Considerations When Moving SAS to a Public Cloud” from SAS Global Forum 2019. https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2019/3363-2019.pdf As I mention in the paper, things are always changing in the public cloud. Here are two new items to share with you since my paper was published: 1. New AWS E32 instance: i3en Here is information from my colleague at AWS about how this new instance type can be used by SAS: The i3en instance family is designed for data-intensive workloads where the data resides on the NVMe volumes attached to the instance. They come with more than 2x the NVMe instance store volume capacity and 4x the network performance. They also come with the new Elastic Fabric Adapters (EFA) to provide even lower latencies and consistent network performance (SAS has not tested these adapters yet). Because they’re designed to leverage local store volumes for high performance block storage, high performance EBS access wasn’t a priority. You can utilize the entire available network bandwidth of the instance to FSx for Lustre. These instances will be able to burst up to 25 Gbps for short periods of time but then fall back to the baseline throughput of each instance type (which is not published). 2. DDN’s Lustre is available in MS Azure. Instructions on how to create a Lustre cluster on Azure can be found here: https://wiki.whamcloud.com/display/PUB/Creating+a+Lustre+Cluster+on+Azure Enjoy this information.

MargaretC · ‎05-15-2019

Greetings everyone, I just wanted to share with you the link to my updated “Important Performance Considerations When Moving SAS to a Public Cloud” from SAS Global Forum 2019. https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2019/3363-2019.pdf As I mention in the paper, things are always changing in the public cloud. Here are two new items to share with you since my paper was published: New AWS E32 instance: i3en Here is information from my colleague at AWS about how this new instance type can be used by SAS: The i3en instance family is designed for data-intensive workloads where the data resides on the NVMe volumes attached to the instance. They come with more than 2x the NVMe instance store volume capacity and 4x the network performance. They also come with the new Elastic Fabric Adapters (EFA) to provide even lower latencies and consistent network performance (SAS has not tested these adapters yet). Because they’re designed to leverage local store volumes for high performance block storage, high performance EBS access wasn’t a priority. You can utilize the entire available network bandwidth of the instance to FSx for Lustre. These instances will be able to burst up to 25 Gbps for short periods of time but then fall back to the baseline throughput of each instance type (which is not published). DDN’s Lustre is available in MS Azure. Instructions on how to create a Lustre cluster on Azure can be found here: https://wiki.whamcloud.com/display/PUB/Creating+a+Lustre+Cluster+on+Azure Enjoy this information. Cheers, Margaret

MargaretC · ‎05-09-2019

Yes, the deployment subtopic includes SAS Viya and SAS 9.4. Below are the papers from the Administration: Deployment topics. Our Journey: Getting on SAS(r) Grid Computing SAS(r) Viya(r): Experience Gained from Multiple Installations and Implementations Planning for Migration from SAS(r) 9.4 to SAS(r) Viya(r) 3.4 Top SAS(r) Architecture Pitfalls: Lessons Learned the Hard Way SAS(r) on Kubernetes: Container Orchestration of Analytic Work Loads Proper Planning Prevents Possible Problems: SAS(r) Viya(r) High-Availability Considerations Multi-tenancy in SAS(r) Viya(r): Considerations and Implementation Integration of Google BigQuery with SAS(r) Analytics Pro in a Docker Container in Cloud Environment Modernize Your Business Intelligence Content from SAS(r)9 to SAS(r) Viya(r) in Three Steps Margaret

MargaretC · ‎05-08-2019

Greetings, Believe it or not, but the planning for SAS Global Forum 2020 is under way. One of our first items is to determine if the presentation topics and subtopics are still correct. Here are the subtopics for the Administration topic area along with the number of breakouts for each subtopic area for SAS Global Forum 2019: Cloud – 7 Deployment – 9 IT Architecture – 12 SAS Administration – 23 Security - 4 Any suggestions of other subtopic areas? Many thanks in advance for your input. And looking forward to seeing you at SAS Global Forum 2020 in downtown Washington, DC March 29 th – April 1 st , 2019. Margaret

MargaretC · ‎05-06-2019

So what you want to do is say from 23:00 until 5:00 SAS Grid nodes xx1 and xx2 are not available to the SAS Grid. So these nodes need to be taken out of a list that SAS Grid is aware of. And then the nodes back to the list at 05:00. If that is correct, then I can chase SAS Grid R&D to see if this can be done with the queue manager in SAS Grid.

MargaretC · ‎05-06-2019

What do you mean by "automating scaling of SAS Grid nodes"? If you mean spinning up a new AWS EC2 instance and using it as a SAS Grid node, then it is not there by default. The step you will have to do manually is adding the name of the new SAS Grid node to the file that defines all the SAS Grid compute nodes. CoreCompete (a SAS partner) demoed doing this at the recent SAS Global Forum 2019 conference. Cheers, Margaret

MargaretC · ‎04-16-2019

I gave a paper at SAS Global Forum 2018 on this topic. Here is a link to the paper from last year. https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2018/1866-2018.pdf I am redoing this paper at SAS Global Forum 2019 and can forward you my updated paper if you have questions. There are some other papers about running SAS in the Public Clouds on this site. http://support.sas.com/kb/62/239.html Hope the information helps you out. Cheers, Margaret

MargaretC · ‎04-11-2019

What type of SAS 9.4 code are you looking to integrate with Microsoft Azure DevOps Tools? It looks like ascii files with SAS code in them can be used with these tools, but I am not sure if this is what you are looking to do. Cheers, Margaret

MargaretC · ‎03-06-2019

What do you mean by Virtual Machines? Do you mean a machine with VMware running on it, but the cores and memory are dedicated to just the application (i.e. thickly provisioned), or do you mean a virtualized infrastructure where memory and cores can be “stolen” at a moments notice if another virtual machine in the infrastructure needs them (i.e. thinly provisioned)? SAS runs in both, but prefers to be on a thickly provisioned infrastructure. Also, depending on the network activity between the various SAS components, your SAS Metadata server may need to have a 10Gigabit dedicated network card (NIC) in order for SAS to perform optimally. So, what is Margaret trying to say? You can use a virtualization tool to take an 8 core system and turn it into a 4 cores system for SAS Metadata and it will function. Will it function without issues and perform well, that will depend on what the others 4 cores will be used for. Margaret

MargaretC · ‎02-04-2019

In the scenario above, if you have made no modifications to the 1000s of lines of SAS code, they will all run on a single SAS Grid node, the same way they do today. If you want to split the logic up of the SAS job, you will need to manually do that. We have a SAS tool that will let you know if you are even able to split the logic up. It is called scaproc. More details on how to do this can be found in this document. http://support.sas.com/documentation/cdl/en/gridref/67371/HTML/default/viewer.htm#n0qbehvhrcl5van165bzsmh76ttr.htm Margaret

MargaretC · ‎01-17-2019

Yes, on Windows 64 bit you can run either 32-bit or 64-bit SAS

MargaretC · ‎01-14-2019

Since the SAS WORK file system is open for anyone to write to it, sometimes SAS users will copy non-SAS WORK files to this file system. If the owner does not claim them, then just use a UNIX command (like rm) to remove them. Margaret

MargaretC · ‎11-30-2018

I have spent the day discussing this several SAS Grid deployment experts about the pros and cons of doing this. The main issue is sharing data between the different regions. If this is not a requirement, then yes you can setup dedicated SAS Grid nodes in local regions that can only access the data that is locally attached to their dedicated SAS Grid compute node. This is currently being done successfully by a global insurance firm. However, if you want to keep certain aspects of SAS Grid (authentication, web services, metadata, ...) in a single location for all the regions to us, then the latency to access the data in this centralized location has caused major performance issues and many upset SAS Grid users. The latency overhead of accessing data across slow WAN connections make SAS Grid unusable for many customers. So, with a good understanding of where the data is and setting up the system to keep the data transfer across WANs to be minimal, this can work.

MargaretC · ‎11-28-2018

I am not being sarcastic. There are lots of different file systems needed for SAS Viya 3.4. Please read the links I sent you.

Online Status	Offline
Date Last Visited	a week ago