In this short post we’ll quickly identify some levers and considerations for bolstering the Viya end user experience. It’s important to note this is not an exhaustive list of levers and considerations AND that SAS Viya itself (server and client-side) is constantly evolving. As such, what may be true/accurate today may not be so, a few months down the line. So the bottom line is to always consult the latest documentation, posts and technical support notes on a regular basis.   Think about network entry and exit points for users connecting to Viya in a public Cloud   For some customer organizations, the dispersion of the user community across a wide geographical area compared to the region where Viya has been deployed can be a factor in the overall user experience.   With that in mind, the customer organizations IT teams need to consider how best to route traffic to groups of users. Some potential Cloud specific services are listed below. Offerings like Azure’s “Front Door” works at Layer 7 (HTTP/HTTPS) to route user traffic as quickly as possible. This can help keep latency between the end users and the Viya server to a minimum. Similar features are also offered by AWS and GCP .   As an aside, for a comparison of services from Azure, AWS and GCP, see these useful resources from Azure. Azure & AWS or Azure & GCP.   Getting the Viya applications to load quicker and be environment specific on the users’ desktop/laptop?   If you've not heard of Progressive Web Apps before then check it out. From SAS’s documentation:   You can install SAS Visual Analytics as a Progressive Web App (PWA). The benefits of using SAS Visual Analytics as a PWA include the following:   Application persistence – By default, your session will never time out, so you can restart your work more quickly. Your administrator can control the timing with a configuration property in SAS Environment Manager. Performance – When installed as a PWA, SAS Visual Analytics initializes faster than when accessed in the browser. Desktop experience – Installing SAS Visual Analytics as a PWA confers all the benefits of a traditional installation. You can launch SAS Visual Analytics from the Start menu or Taskbar, and you do not need to sort through countless tabs to find the correct instance of SAS Visual Analytics Renaming – You can rename each PWA instance to quickly access different environments, such as development, test, or production servers.   Thinking about the Viya server(s) configuration and infrastructure   As with all multi-user and analytical software, the end user experience is heavily influenced by the configuration of the underlying software and of course the hardware infrastructure. And it should be added potentially the configuration of third party software may also be a key driver.   A good starting point that will inevitably change over time, is the Viya4 Tuning Guide.    From the Tuning Guide you will see references to topics such as:   How to set upper limits to the number of Compute sessions each user (user & super user) can run concurrently. See SAS_LAUNCHER_USER_PROCESS_LIMIT & SAS_LAUNCHER_SUPER_USER_PROCESS_LIMIT SAS Compute pod settings for settings aligned to specific contexts allow different pod limits and requests for CPU & RAM. See here Tuning the Open Distro for ElasticSearch component Tuning the CAS Server Tuning the SAS Infrastructure Data Server (PostgreSQL) Tuning the JDBC connections Tuning the LDAP connections   To complement the Viya Tuning Guide, there is the Micro Analytical Service tuning guidelines    Compute Server Pods: "Pre-Pull" and "Pool of Available Servers"   When users of SAS Studio and Model Studio start a session, a Compute Server pod is made available to those users. With this in mind, it’s useful for users to know what can be done to speed up the availability of the Compute Server pods. At present two concepts can help those users, namely “pre-pulling container images” and “pool of available Compute Servers”.   "Pre-Pull" Compute Server images   The container image for Compute Server is measured in gigabytes. As such, it is sufficiently large that movement of such an image from container repository to a node that will run Compute Server pods could take several minutes. To mitigate the impact of that movement, The idea is to "pre-pull" (known as “SAS Image Staging”) the Compute pod image during the SAS Viya deployment, so it will be already available on the Nodes at the end of the deployment. For more details read this @RPoumarede  post and the official documentation .   Pool of Available Servers   Now for the second concept which is “Pool of Available Servers”. From the official documentation SAS Compute servers that are configured to be reusable can also be configured to have a minimum number of servers that are available. This configuration enables the SAS Compute service to maintain a set of running compute servers that can be reused. Whenever an environment is started, the number of servers that are specified are also started.   In short where the “Pool of Available Servers” configuration has been set, users of SAS Studio and users of Model Studio running 2 or more pipelines in parallel are likely to experience benefits. For SAS Studio users, their Compute Context/Session is likely to start quicker. For Model Studio users, they are likely to see their pipelines run in parallel as soon they submit the flows.   Compute Server Pods: CPU and RAM limits   So far we have spoken about concepts that help users get to the point of using their analytical clients in a more timely fashion. What can we consider to improve the performance of jobs being submitted to the SAS Compute Server?   For customer organizations that will be using SAS Studio based sessions and batch jobs, Viya users and administrators are encouraged to use different compute contexts, for different types of workloads. For example when a SAS Studio program or flow contains processing that would benefit from multiple threads e.g. Proc Sort, Proc Summary, Proc SQL, Proc GLM, then use a Compute Context that has a large number of cores than the default Compute pod settings. And as a reminder options such as Memsize, Sortsize and Sumsize are also important when running such code .A simple approach would be to have a small, medium, large and Xlarge aligned compute contexts. These would for example have pod limits of 1 CPUs + 1GB RAM, 1 CPUs + 2GB RAM, 4 CPUs + 4GB RAM and 8 CPUs + 8GB RAM.   As an aside remember to take into account how K8s pod CPUs map to the infrastructure. One CPU, in Kubernetes, is equivalent to: 1 AWS vCPU 1 GCP Core 1 Azure vCore 1 Hyperthread on a bare-metal Intel processor with Hyperthreading   Typically the resource values would be lower than the limit sizes for these pods in this scenario. Some informal testing has shown that there are performance gains that can be realized for a given set of workloads submitted to the Compute Server. When thinking about increasing CPU and RAM limits for Compute pods, you will need to be mindful of the likelihood of diminishing returns in terms of performance gains. In part, this is down to the I/O throughput constraints/limitation of the attached storage being read from and written to. Previous published research by @MargaretC in SAS 9.4 indicated that 4 CPUs (4 cores) and 1 GB per core was sufficient. It is worth mentioning that the use of options like UTILLOC to leverage distinct & dedicated storage locations may prove to be beneficial from a performance perspective. And for Cloud based K8s environments, you need to be clear about vCPUs and their alignment to physical cores and threads for a given instance type e.g. on Azure see this page.   And since late 2021, customers can now license SAS Workload Management to enhance the ability to manage and prioritize workloads. Indeed the ability to queue jobs based on a number of parameters can give users confidence their jobs will be executed even if the system is particularly busy. For more information see the SAS Workload Management documentation & recent posts from GEL folks.   Visual Analytics usage   As with other SAS usage, creating content that is optimized for a given visual or programming interface. This short article does not go into such practices but other resources on that topic are available. For this short post we call out one specific feature, namely SAS Report Packages.   For reports that are based on data that change on a relatively slow cadence e.g. perhaps every 8 – 24 hours, then the use of SAS Report packages maybe appropriate. From a report consumer perspective, the snappiness of such report packages may provide a better end user experience because there is little to no working being done by Viya services or a CAS Server. From the documentation    You can export a report and a snapshot of your data and query results for a report from SAS Visual Analytics to a SAS report package. You do not have to export an entire report. Instead, you can select individual objects, containers, and pages that you want to export. You can then use the SAS Visual Analytics SDK to embed the report information into your custom web pages and portals. For more information about the SDK, see SAS Visual Analytics SDK for developers.   The report package is a compressed file named report-package-name.sasreportpkg.zip that includes a snapshot of the report, images, style sheets, and data that are needed for a given set of report objects. The package also includes all of the data that is needed to render the selected objects, as well as the data that is required to support any actions that are defined between the objects.   Visual Data Mining and Machine Learning usage   For data mining and machine learning focused users of SAS Model Studio, the user experience has continued to be enhanced over the lifetime of SAS Viya 4. Knowing how Model Studio works for given use cases or scenarios can help both individual users and all users working concurrently on the system.   The first use case is well known and documented in terms of publications and posts. In short, it relates to users leveraging ‘training’, ‘validation’ and ‘test’ data sets in their analysis. For such use cases, the general recommendation is to have variables that can be mapped to the roles of Partition (e.g. _PARTIND_ ) and Key (e.g. _DMINDEX_ ) already existing in the data table prior to being loaded into CAS for use with Model Studio. If this is not the case, then the table of data will be written to the CASDATADIR location on the CAS Server Controller. The impact of writing such tables to the CAS Server Controller can be a negatively impactful to all users of said CAS Server, if the data table(s) in question are ‘large’. In this context ‘large’ can be tables considered to use more than 40% of the available disk space available to the CASDATADIR location on the CAS Server Controller. During the writing of the table to this location the CAS Server Controller and Workers can become busy, as can the network which connects them.   See this SAS documentation section and this post for more details.   The second use case is for running parallel pipelines in a Model Studio project. As with the SAS Visual Forecasting notes below, there is a setting that allows Viya administrators to increase the Maximum Concurrent Nodes (the setting name is sas.analytics.flows.maximumConcurrentNodeExecution) from it’s default value of 5. See the documentation. This can be helpful if users are planning on creating Model Studio Projects with more than 5 parallel pipelines. Increasing this setting value along with use of “Pool of Available Servers” and “Reusable Servers” can bring benefits, as described in this post by @RobCollum.   SAS Visual Forecasting usage   For customers who use SAS Visual Forecasting, two concepts that can help users have a good experience are listed below. Again, this is not an exhaustive list by any means, but they are certainly two that are worth mentioning. The first is “data shuffling” / “data movement”. The second is concurrent users/pipelines running modelling strategies.   From this section within the documentation: The actual data processing runs on a CAS server. In a distributed CAS environment, the time series are delineated and shuffled based on the distinct combination of values for the BY variables. The time series data is processed in parallel. It is written out to CAS tables on each worker node. Furthermore, threads are used on each worker node to process the time series vectors that are loaded onto a node concurrently.   What does this mean in practice? Imagine we had 5,000 SKUs and each SKU has 2 years of daily data on average (700+ data points per SKU). To do the forecasting, each SKU’s data would be shuffled or moved to one of the available CAS Server Workers (and lets assume we are using MPP CAS Server with 8 Workers). Once all the SKUs’ data points have been placed together on one of the 8 Workers, then the forecasting can begin. So for example imagine we want to forecast beer sales for the SKUs “Hop-tastic”, “Majestic Malt” and “Cwrw Braf”. Then all of “Hop-tastic” data will be CAS Worker 2, “Majestic Malt” data on Worker 5 and “Cwrw Braf” on CAS Worker 8. For more details read these SGF papers by members of SAS's R&D teams (a, b) . From this we can see users who are working with large tables of data may encounter a period of waiting time before the forecasting algorithms are applied. Users working with very, very large data, can consider how some of the "data shuffling" (by-group partitioning) can be done ahead of time or at at quiet times of the day to make best use of the available time for analysis. From the documentation: "You can use the partitioning feature in CAS to partition the table once and use that partitioning over and over again. The partitioning feature in CAS provides a more permanent and efficient solution for grouping data. The work required for partitioning does not have to be repeated as it does when using BY groups. When you partition a table using the partition action, it becomes a partitioned in-memory table that can be accessed by subsequent operations."   The second concept is the number users or pipelines that can be run concurrently. From the official documentation for the section headed "Modeling Strategies Take a Long Time to Complete" :   There are several factors that can influence the performance of modeling strategies during a pipeline run. In some circumstances, if there are a lot of users running pipelines at the same time, node execution time can be affected. By default, a maximum of five users can run the modeling strategies simultaneously. For any additional users, the modeling strategies are placed in Pending state until a run completes and another node can be started.   The SAS Viya administrators can help their forecasting colleagues by changing increasing the Maximum Concurrent Nodes setting to be a value greater than the default number of 5. In addition to adjusting this value, the administrator may also want to consider increasing the number of “Pool of Available Servers” and “Reusable Servers” to facilitate the quicker use of Compute Servers.   SAS Studio usage   SAS Studio is great environment for programmers and low/no-code developers of data management and analytical content.   Running some the steps in a flow can be optimized  and users can get predictable results by using the submission order of a flow     At the current release of SAS Studio within Viya 4 (2021.2.5) it is not possible to run flows in parallel as with SAS 9.4 based technology as described by @EdoardoRiva in his SGF paper. However, if users want to run other workloads in addition to their primary SAS Studio flow, then they can use the ‘Background Submit’ feature. Here’s what the SAS Studio documentation has to say:   You can run a saved program, query, task, or flow as a background submission, which means that the file can run while you continue to use SAS Studio. You can view the status of files that have been submitted in the background, and you can cancel files that are currently running in the background.   This is a great feature and one that can certainly help users be more productive. With this in mind, it is important the users and administrators are aware of what is happening in the background and the tie-back to SAS_LAUNCHER_USER_PROCESS_LIMIT. @DavidStern wrote this useful post on the topic:   Note: Because a background submission uses a separate compute server, any libraries or tables that are created by the submission do not appear in the Libraries section of the navigation pane in SAS Studio.   In practice, if the SAS_LAUNCHER_USER_PROCESS_LIMIT is set to say ‘5’, then a SAS Studio user could have their main session + 4 Background submissions.   Wrapping it-up   Well I was hoping this would be a short post  ‌‌ but if you decided to read it all, you may well now have spent 10 mins reading this. And if you have read it, but your still not sure what all of this means, then feel free to ask a question in the comments section. Or simply logon to a Viya environment and explore some of these proposed tips and tweaks for yourself. And as always if you have other ideas on this topic or would think some of what I've written needs further discussion, then feel free to add a comment below.   Thanks, Simon   Find more articles from SAS Global Enablement and Learning here. ... View more

This will be a short blog that will hopefully help you to be aware of the nuances of Kubernetes features, how some of the major public Cloud providers consider them and what resources you can access for reference. This may help in situations when deciding whether certain features are appropriate for a given release and flavour of Kubernetes & Viya.   As a reminder the Kubernetes (K8s) documentation is a rich set of materials that goes into various levels of details. There is also a set of useful blog posts https://kubernetes.io/blog/. With all this this content, you’re very likely to find most of the information you need. But 😊 if like me you sometimes skim read to get to the answers you are looking for, you should take a moment to ensure you have the complete context regarding the K8s features. An example I was excited to see a feature “CPUManager” that allow K8s pods to have exclusive use of CPUS/cores (“exclusive” versus “shared pool”, within the Guaranteed QoS category) . What I did not know/appreciate initially is this K8s feature is at Beta release. And then having read some more I realized (I know, I’m not the fastest at putting 2 + 2 together) that there are also Alpha levels features available.   Before we move on, did you know that SAS Viya users can see which features have been switched on in their release of SAS Viya? See this SAS documentation for more information.   From the K8s documentation pages, there’s an excellent description of Feature Stages:   K8s Feature stages (taken from the official K8s documentation)   A feature can be in Alpha, Beta or GA stage. An Alpha feature means: Disabled by default. Might be buggy. Enabling the feature may expose bugs. Support for feature may be dropped at any time without notice. The API may change in incompatible ways in a later software release without notice. Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.   A Beta feature means: Enabled by default. The feature is well tested. Enabling the feature is considered safe. Support for the overall feature will not be dropped, though details may change. The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature. Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.   Note: Please do try Beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes. A General Availability (GA) feature is also referred to as a stable feature. It means:   The feature is always enabled; you cannot disable it. The corresponding feature gate is no longer needed. Stable versions of features will appear in released software for many subsequent versions.   So just from this page you can quickly see points of interest.   Alpha features are disabled by default, but beta features are enabled by default.   Customers wanting to use K8s in production/business critical use cases, need to understand the impact of using alphas and betas. In summary alpha features should not be used with production systems, but beta features can be if multiple K8s clusters of differing K8s versions are available.   By now you might ask: “Where can I find a list of features by feature stages?” Answer can be found here.  “How does the K8s deprecation policy work?” Answer can be found here.  “Where can I find the list of features which graduated to GA or were deprecated?” Answer can be found here.  “How or does this impact SAS Viya deployments in anyway?” See the last section of the blog below.   As an FYI, my colleague Raphael Poumarede (@RPoumarede) is currently working on a SAS Communities post.  This discusses the impact a recent deprecation of K8s APIs has on current Viya releases.   Which then leads us on to the public Cloud providers and K8 specific providers. What’s their current (as of March 1 st , 2022) approach to dealing with alpha and beta features. The table below provides a quick summary but if you want more detail, you’ll need to reach out to a Cloud provider support page/team.       AKS (Azure) EKS (AWS) GKE (GCP)  Openshift Supports beta features? Yes Yes *Yes Yes, if the beta is well documented. Supports use of alpha features? No No Yes but in specific alpha cluster instance(s). To some degree. Contact RedHat for specifics Additional notes     *In some cases, GKE may have disabled a beta feature for a specific GKE control plane version.       In addition, some public Cloud providers also provide “preview” access to upcoming features. For Azure, AKS updates on previews and features that have become GA can be found here:   With this information in front of us, what does this mean for SAS teams and SAS Viya? Well it probably helps if we are being specific about the “which teams at SAS”. 😊   For customers and SAS professional services consultants, hosting teams, technical support, and pre-sales engineers the use of GA features is a given. However, if a given beta feature proves to be useful and beneficial in the usage and operations experience of a SAS Viya environment, then both the customer and SAS team should note that the feature is beta and that customer needs to monitor any graduation or deprecation of that feature. Knowing what flavour of K8s and what version is a good starting point. This is especially important for open source flavours of K8s. This is because customers have the flexibility to turn on and off both alpha and beta features.   The other teams at SAS are of course the R&D and product management teams. In short, SAS’s R&D engineering approach will be to use K8’s GA features only when developing Viya features.   Thanks to my colleagues at SAS for their contributions to this blog.   Find more articles from SAS Global Enablement and Learning here. ... View more

From time to time, what appear to be simple questions generate more thinking than initially anticipated. And off the back of one such question I have written this article, which refers to how generate load across multiple cores when you have a Base SAS / SAS Foundation environment and SAS/CONNECT (think a SAS compute/connect session in 9.4/Viya ). Before diving into the detail my thanks to my colleague Mark Thomas who helped me with MP Connect code and to colleagues in Technical Support and R&D for raising this as a topic of interest. From time to time, customers ask  SAS how to determine if SAS 9.4 is able to use all the cores available to it. This is sometimes as a result of their own testing which appears to be inconclusive e.g. a customer had over 12+ cores available to them but in their testing they were only seeing a handful of cores being leveraged. So what was going on? Well here are some reminders when it comes to Base SAS: For quick explanation about threads and SAS Foundation, read What Is Threading Technology in SAS? Many of the SAS Foundation procs and a big chunk of datastep were written to execute in single threaded mode However there are some procs and data step that are multithreaded either by default or by setting some options. For more information read Threading in Base SAS. For some procs that can use multiple threads, they exploit by-group processing to enable each thread to focus on a particular by-group (or multiple by-groups depending on how many groups and how many threads are available) SAS Foundation licensing can be cores based Demonstrating multi-threading using multi-threaded procs may be limited by the constraints of the underlying storage being able to provide the data in a timely manner For a clear definition of features which MP Connect (which is part of SAS/CONNECT) brings read MP CONNECT. So with all this in mind, the question of whether users can generate SAS jobs that don't rely on sufficient data to generate enough CPU load, to occupy as many cores in a symmetric multiprocessing (SMP), server springs to mind. There are probably multiple solutions to this, but one that sprang to my mind was the generation of prime numbers. Is there a sufficient number of prime numbers to find within a set of numbers e.g. 1 - 10000, that would generate sufficient load so that a user/observer could see generating across all cores (or as many cores as needed). BUT we also have to ensure that the number is not too large that the test takes hours to complete. So we want to have some code which to some degree is inefficient but not too inefficient.    With help from Mark and his knowledge of MP Connect and macros, this is the code we came up with. In essence for this example we generate 10 distinct sessions (which equates to 10 of threads out of a possible 88, and yes this is a hyperthreaded host, so 88 threads = 44 cores) and sought to find the prime numbers available in the first 100,000 numbers (1-100,000) and write them to SAS datasets.  If you're wondering there 9592 but our code generates 9591 into a table (can you guess which one it leaves out?). As mentioned earlier the code is meant to be inefficient but not too inefficient. So in our approach, we deliberately exclude all even numbers from the test. For greater efficiencies you can take a look these resources to get you started: How many prime numbers? SAS/CONNECT - Tips and Tricks Using SAS/IML to sieve prime numbers by Rick Wicklin SAS/CONNECT -> MP CONNECT documentation Running SAS programs in parallel using SAS/CONNECT by Leonid Batkhan The code below is what we used for our tests: options sascmd=”!SASCMD” fullstimer symbolgen; /* Set the ‘num” macro variable to the number of sessions you want to create */ %let num=10 ; /* this loop initiates sessions and runs the code to generate prime numbers */ %macro loop; %local i ; %do i=1 %to &num %let session=sess&i. ; %let &session.=myddfai.sas.com; signon &session.; %let testds=test&i. ; %syslput testds=&testds.; rsubmit &session. wait=no ; data &testds.; do i = 1 to 100000 by 2; L=0; do j=1 to i; k=0; if (mod(i , j)= 0) then do; k+1; a=mod(i , j); end; if K=1 then L+1; end; If L=2 then output; end; run; endrsubmit; %end ; %mend loop; %loop ; /* macro to generate a string of session names */ %macro gensess; %do i=1 %to &num sess&i. %end ; %mend gensess ; listtask _all_ ; waitfor _all_ %gensess; /* macro to download datasets generated in each session */ %macro download; %local i ; %do i=1 %to &num %let testds=test&i. ; %syslput testds=&testds. /remote=sess&i.; rsubmit sess&i. wait=no ; proc download data=work.&testds. out=work.&testds.; run; endrsubmit ; %end ; %mend download; %download ; /* macro to signoff each of the connect sessions */ %macro signoff; %local i ; %do i=1 %to &num signoff sess&i. ; %end ; %mend signoff; %signoff ; /* proc datasets lib=work ; */ /* delete test1-test10 ; */ /* run; */   Below is the log that it generates, when we look at the first 100,000 numbers. The interesting takeaway is that on the this specific server, it takes roughly between 53-56 seconds to create the tables at the server side.   Using the linux utility "htop" us to look at the demand on each core and if needed we can take a screenshot (as we did below). We did not test this using SAS Environment Manager, but there's a good chance that in Viya 3.5 you will see the spikes in CPU activity.   1 %studio_hide_wrapper; 82 options sascmd=”!SASCMD” fullstimer symbolgen; 83 84 /* Set the ‘num” macro variable to the number of sessions you want to create */ 85 %let num=10 ; 86 87 /* this loop initiates sessions and runs the code to generate prime numbers */ 88 %macro loop; 89 90 %local i ; 91 92 %do i=1 %to # 93 94 %let session=sess&i. ; 95 %let &session.=myddfai.sas.com; 96 signon &session.; 97 98 %let testds=test&i. ; 99 %syslput testds=&testds.; 100 rsubmit &session. wait=no ; 101 102 data &testds.; 103 do i = 1 to 100000 by 2; 104 L=0; 105 do j=1 to i; 106 k=0; 107 if (mod(i , j)= 0) then do; 108 k+1; 109 a=mod(i , j); 110 end; 111 if K=1 then L+1; 112 end; 113 If L=2 then output; 114 end; 115 run; 116 117 endrsubmit; 118 %end ; 119 %mend loop; 120 121 %loop ; SYMBOLGEN: Macro variable NUM resolves to 10 SYMBOLGEN: Macro variable I resolves to 1 SYMBOLGEN: Macro variable SESSION resolves to sess1 SYMBOLGEN: Macro variable SESSION resolves to sess1 NOTE: Remote signon to SESS1 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.04 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS1 complete. SYMBOLGEN: Macro variable I resolves to 1 SYMBOLGEN: Macro variable TESTDS resolves to test1 SYMBOLGEN: Macro variable SESSION resolves to sess1 NOTE: Background remote submit to SESS1 in progress. SYMBOLGEN: Macro variable I resolves to 2 SYMBOLGEN: Macro variable SESSION resolves to sess2 SYMBOLGEN: Macro variable SESSION resolves to sess2 NOTE: Remote signon to SESS2 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.05 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS2 complete. SYMBOLGEN: Macro variable I resolves to 2 SYMBOLGEN: Macro variable TESTDS resolves to test2 SYMBOLGEN: Macro variable SESSION resolves to sess2 NOTE: Background remote submit to SESS2 in progress. SYMBOLGEN: Macro variable I resolves to 3 SYMBOLGEN: Macro variable SESSION resolves to sess3 SYMBOLGEN: Macro variable SESSION resolves to sess3 NOTE: Remote signon to SESS3 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.05 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.01 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS3 complete. SYMBOLGEN: Macro variable I resolves to 3 SYMBOLGEN: Macro variable TESTDS resolves to test3 SYMBOLGEN: Macro variable SESSION resolves to sess3 NOTE: Background remote submit to SESS3 in progress. SYMBOLGEN: Macro variable I resolves to 4 SYMBOLGEN: Macro variable SESSION resolves to sess4 SYMBOLGEN: Macro variable SESSION resolves to sess4 NOTE: Remote signon to SESS4 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.05 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS4 complete. SYMBOLGEN: Macro variable I resolves to 4 SYMBOLGEN: Macro variable TESTDS resolves to test4 SYMBOLGEN: Macro variable SESSION resolves to sess4 NOTE: Background remote submit to SESS4 in progress. SYMBOLGEN: Macro variable I resolves to 5 SYMBOLGEN: Macro variable SESSION resolves to sess5 SYMBOLGEN: Macro variable SESSION resolves to sess5 NOTE: Remote signon to SESS5 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.04 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.01 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS5 complete. SYMBOLGEN: Macro variable I resolves to 5 SYMBOLGEN: Macro variable TESTDS resolves to test5 SYMBOLGEN: Macro variable SESSION resolves to sess5 NOTE: Background remote submit to SESS5 in progress. SYMBOLGEN: Macro variable I resolves to 6 SYMBOLGEN: Macro variable SESSION resolves to sess6 SYMBOLGEN: Macro variable SESSION resolves to sess6 NOTE: Remote signon to SESS6 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.07 seconds cpu time 0.06 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.00 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS6 complete. SYMBOLGEN: Macro variable I resolves to 6 SYMBOLGEN: Macro variable TESTDS resolves to test6 SYMBOLGEN: Macro variable SESSION resolves to sess6 NOTE: Background remote submit to SESS6 in progress. SYMBOLGEN: Macro variable I resolves to 7 SYMBOLGEN: Macro variable SESSION resolves to sess7 SYMBOLGEN: Macro variable SESSION resolves to sess7 NOTE: Remote signon to SESS7 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.06 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.01 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS7 complete. SYMBOLGEN: Macro variable I resolves to 7 SYMBOLGEN: Macro variable TESTDS resolves to test7 SYMBOLGEN: Macro variable SESSION resolves to sess7 NOTE: Background remote submit to SESS7 in progress. SYMBOLGEN: Macro variable I resolves to 8 SYMBOLGEN: Macro variable SESSION resolves to sess8 SYMBOLGEN: Macro variable SESSION resolves to sess8 NOTE: Remote signon to SESS8 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.05 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.01 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS8 complete. SYMBOLGEN: Macro variable I resolves to 8 SYMBOLGEN: Macro variable TESTDS resolves to test8 SYMBOLGEN: Macro variable SESSION resolves to sess8 NOTE: Background remote submit to SESS8 in progress. SYMBOLGEN: Macro variable I resolves to 9 SYMBOLGEN: Macro variable SESSION resolves to sess9 SYMBOLGEN: Macro variable SESSION resolves to sess9 NOTE: Remote signon to SESS9 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.05 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.01 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS9 complete. SYMBOLGEN: Macro variable I resolves to 9 SYMBOLGEN: Macro variable TESTDS resolves to test9 SYMBOLGEN: Macro variable SESSION resolves to sess9 NOTE: Background remote submit to SESS9 in progress. SYMBOLGEN: Macro variable I resolves to 10 SYMBOLGEN: Macro variable SESSION resolves to sess10 SYMBOLGEN: Macro variable SESSION resolves to sess10 NOTE: Remote signon to SESS10 commencing (SAS Release V.03.05M0P110619). NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.03.05 (TS5M0 MBCS3170) Licensed to GEL Viya 3.5- ImplWkshp – 19w47 – Ship – Shared, Site 70180938. NOTE: This session is executing on the Linux 4.1.12-124.19.2.el6uek.x86_64 (LIN X64) platform. NOTE: Analytical products: SAS/STAT 15.1 SAS/ETS 15.1 SAS/OR 15.1 SAS/IML 15.1 SAS/QC 15.1 NOTE: Additional host information: Linux LIN X64 4.1.12-124.19.2.el6uek.x86_64 #2 SMP Fri Sep 14 08:59:12 PDT 2018 x86_64 Oracle Linux Server release 6.10 NOTE: SAS initialization used: real time 0.06 seconds cpu time 0.06 seconds NOTE: AUTOEXEC processing beginning; file is /opt/sas/viya/config/etc/compsrv/default/autoexec.sas. NOTE: DATA statement used (Total process time): real time 0.00 seconds cpu time 0.01 seconds NOTE: AUTOEXEC processing completed. NOTE: Remote signon to SESS10 complete. SYMBOLGEN: Macro variable I resolves to 10 SYMBOLGEN: Macro variable TESTDS resolves to test10 SYMBOLGEN: Macro variable SESSION resolves to sess10 NOTE: Background remote submit to SESS10 in progress. 122 123 /* macro to generate a string of session names */ 124 %macro gensess; 125 %do i=1 %to # 126 sess&i. 127 %end ; 128 %mend gensess ; “SESS10” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS9” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS8” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS7” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS6” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS5” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS4” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS3” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS2” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY “SESS1” ————– Type: SAS/CONNECT Process State: RUNNING ASYNCHRONOUSLY 129 130 listtask _all_ ; 131 waitfor _all_ %gensess; SYMBOLGEN: Macro variable NUM resolves to 10 SYMBOLGEN: Macro variable I resolves to 1 SYMBOLGEN: Macro variable I resolves to 2 SYMBOLGEN: Macro variable I resolves to 3 SYMBOLGEN: Macro variable I resolves to 4 SYMBOLGEN: Macro variable I resolves to 5 SYMBOLGEN: Macro variable I resolves to 6 SYMBOLGEN: Macro variable I resolves to 7 SYMBOLGEN: Macro variable I resolves to 8 SYMBOLGEN: Macro variable I resolves to 9 SYMBOLGEN: Macro variable I resolves to 10 132 133 134 /* macro to download datasets generated in each session */ 135 %macro download; 136 %local i ; 137 138 %do i=1 %to # 139 140 %let testds=test&i. ; 141 142 %syslput testds=&testds. /remote=sess&i.; 143 rsubmit sess&i. wait=no ; 144 proc download data=work.&testds. out=work.&testds.; 145 run; 146 endrsubmit ; 147 %end ; 148 %mend download; 149 150 %download ; SYMBOLGEN: Macro variable NUM resolves to 10 SYMBOLGEN: Macro variable I resolves to 1 SYMBOLGEN: Macro variable TESTDS resolves to test1 SYMBOLGEN: Macro variable I resolves to 1 SYMBOLGEN: Macro variable I resolves to 1 SYMBOLGEN: Macro variable I resolves to 2 SYMBOLGEN: Macro variable TESTDS resolves to test2 SYMBOLGEN: Macro variable I resolves to 2 SYMBOLGEN: Macro variable I resolves to 2 SYMBOLGEN: Macro variable I resolves to 3 SYMBOLGEN: Macro variable TESTDS resolves to test3 SYMBOLGEN: Macro variable I resolves to 3 SYMBOLGEN: Macro variable I resolves to 3 SYMBOLGEN: Macro variable I resolves to 4 SYMBOLGEN: Macro variable TESTDS resolves to test4 SYMBOLGEN: Macro variable I resolves to 4 SYMBOLGEN: Macro variable I resolves to 4 SYMBOLGEN: Macro variable I resolves to 5 SYMBOLGEN: Macro variable TESTDS resolves to test5 SYMBOLGEN: Macro variable I resolves to 5 SYMBOLGEN: Macro variable I resolves to 5 SYMBOLGEN: Macro variable I resolves to 6 SYMBOLGEN: Macro variable TESTDS resolves to test6 SYMBOLGEN: Macro variable I resolves to 6 SYMBOLGEN: Macro variable I resolves to 6 SYMBOLGEN: Macro variable I resolves to 7 SYMBOLGEN: Macro variable TESTDS resolves to test7 SYMBOLGEN: Macro variable I resolves to 7 SYMBOLGEN: Macro variable I resolves to 7 SYMBOLGEN: Macro variable I resolves to 8 SYMBOLGEN: Macro variable TESTDS resolves to test8 SYMBOLGEN: Macro variable I resolves to 8 SYMBOLGEN: Macro variable I resolves to 8 SYMBOLGEN: Macro variable I resolves to 9 SYMBOLGEN: Macro variable TESTDS resolves to test9 SYMBOLGEN: Macro variable I resolves to 9 SYMBOLGEN: Macro variable I resolves to 9 SYMBOLGEN: Macro variable I resolves to 10 SYMBOLGEN: Macro variable TESTDS resolves to test10 SYMBOLGEN: Macro variable I resolves to 10 SYMBOLGEN: Macro variable I resolves to 10 151 152 153 /* macro to signoff each of the connect sessions */ 154 %macro signoff; 155 156 %local i ; 157 158 %do i=1 %to # 159 signoff sess&i. ; 160 %end ; 161 %mend signoff; 162 163 %signoff ; SYMBOLGEN: Macro variable NUM resolves to 10 SYMBOLGEN: Macro variable I resolves to 1 NOTE: Remote submit to SESS1 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST1 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 55.61 seconds cpu time 55.60 seconds 3 The SAS System Sunday, 21 March 2021 14:06:24 NOTE: Remote submit to SESS1 complete. NOTE: Background remote submit to SESS1 in progress. NOTE: Remote submit to SESS1 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST1 to out=WORK.TEST1 NOTE: 383640 bytes were transferred at 19158950 bytes/second. NOTE: The data set WORK.TEST1 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST1 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.02 seconds cpu time 0.00 seconds NOTE: Remote submit to SESS1 complete. NOTE: Remote signoff from SESS1 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 57.45 seconds cpu time 55.71 seconds NOTE: Remote signoff from SESS1 complete. SYMBOLGEN: Macro variable I resolves to 2 NOTE: Remote submit to SESS2 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST2 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 55.26 seconds cpu time 55.25 seconds 3 The SAS System Sunday, 21 March 2021 14:06:24 NOTE: Remote submit to SESS2 complete. NOTE: Background remote submit to SESS2 in progress. NOTE: Remote submit to SESS2 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST2 to out=WORK.TEST2 NOTE: 383640 bytes were transferred at 5682803 bytes/second. NOTE: The data set WORK.TEST2 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST2 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.07 seconds cpu time 0.02 seconds NOTE: Remote submit to SESS2 complete. NOTE: Remote signoff from SESS2 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 57.34 seconds cpu time 55.37 seconds NOTE: Remote signoff from SESS2 complete. SYMBOLGEN: Macro variable I resolves to 3 NOTE: Remote submit to SESS3 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST3 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 54.93 seconds cpu time 54.92 seconds 3 The SAS System Sunday, 21 March 2021 14:06:24 NOTE: Remote submit to SESS3 complete. NOTE: Background remote submit to SESS3 in progress. NOTE: Remote submit to SESS3 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST3 to out=WORK.TEST3 NOTE: 383640 bytes were transferred at 5913536 bytes/second. NOTE: The data set WORK.TEST3 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST3 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.07 seconds cpu time 0.01 seconds NOTE: Remote submit to SESS3 complete. NOTE: Remote signoff from SESS3 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 57.21 seconds cpu time 55.04 seconds NOTE: Remote signoff from SESS3 complete. SYMBOLGEN: Macro variable I resolves to 4 NOTE: Remote submit to SESS4 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST4 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 55.48 seconds cpu time 55.47 seconds 4 The SAS System Sunday, 21 March 2021 14:06:25 NOTE: Remote submit to SESS4 complete. NOTE: Background remote submit to SESS4 in progress. NOTE: Remote submit to SESS4 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST4 to out=WORK.TEST4 NOTE: 383640 bytes were transferred at 6157076 bytes/second. NOTE: The data set WORK.TEST4 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST4 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.07 seconds cpu time 0.01 seconds NOTE: Remote submit to SESS4 complete. NOTE: Remote signoff from SESS4 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 57.08 seconds cpu time 55.59 seconds NOTE: Remote signoff from SESS4 complete. SYMBOLGEN: Macro variable I resolves to 5 NOTE: Remote submit to SESS5 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST5 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 54.91 seconds cpu time 54.90 seconds 4 The SAS System Sunday, 21 March 2021 14:06:24 NOTE: Remote submit to SESS5 complete. NOTE: Background remote submit to SESS5 in progress. NOTE: Remote submit to SESS5 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST5 to out=WORK.TEST5 NOTE: 383640 bytes were transferred at 4911086 bytes/second. NOTE: The data set WORK.TEST5 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST5 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.09 seconds cpu time 0.02 seconds NOTE: Remote submit to SESS5 complete. NOTE: Remote signoff from SESS5 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 56.95 seconds cpu time 54.99 seconds NOTE: Remote signoff from SESS5 complete. SYMBOLGEN: Macro variable I resolves to 6 NOTE: Remote submit to SESS6 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST6 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 55.57 seconds cpu time 55.54 seconds 4 The SAS System Sunday, 21 March 2021 14:06:25 NOTE: Remote submit to SESS6 complete. NOTE: Background remote submit to SESS6 in progress. NOTE: Remote submit to SESS6 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST6 to out=WORK.TEST6 NOTE: 383640 bytes were transferred at 4664201 bytes/second. NOTE: The data set WORK.TEST6 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST6 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.08 seconds cpu time 0.00 seconds NOTE: Remote submit to SESS6 complete. NOTE: Remote signoff from SESS6 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 56.83 seconds cpu time 55.66 seconds NOTE: Remote signoff from SESS6 complete. SYMBOLGEN: Macro variable I resolves to 7 NOTE: Remote submit to SESS7 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST7 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 55.23 seconds cpu time 55.22 seconds 4 The SAS System Sunday, 21 March 2021 14:06:25 NOTE: Remote submit to SESS7 complete. NOTE: Background remote submit to SESS7 in progress. NOTE: Remote submit to SESS7 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST7 to out=WORK.TEST7 NOTE: 383640 bytes were transferred at 4030212 bytes/second. NOTE: The data set WORK.TEST7 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST7 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.10 seconds cpu time 0.00 seconds NOTE: Remote submit to SESS7 complete. NOTE: Remote signoff from SESS7 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 56.69 seconds cpu time 55.34 seconds NOTE: Remote signoff from SESS7 complete. SYMBOLGEN: Macro variable I resolves to 8 NOTE: Remote submit to SESS8 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST8 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 54.88 seconds cpu time 54.86 seconds 4 The SAS System Sunday, 21 March 2021 14:06:25 NOTE: Remote submit to SESS8 complete. NOTE: Background remote submit to SESS8 in progress. NOTE: Remote submit to SESS8 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST8 to out=WORK.TEST8 NOTE: 383640 bytes were transferred at 4171902 bytes/second. NOTE: The data set WORK.TEST8 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST8 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.10 seconds cpu time 0.01 seconds NOTE: Remote submit to SESS8 complete. NOTE: Remote signoff from SESS8 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 56.56 seconds cpu time 54.99 seconds NOTE: Remote signoff from SESS8 complete. SYMBOLGEN: Macro variable I resolves to 9 NOTE: Remote submit to SESS9 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST9 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 54.85 seconds cpu time 54.84 seconds 4 The SAS System Sunday, 21 March 2021 14:06:25 NOTE: Remote submit to SESS9 complete. NOTE: Background remote submit to SESS9 in progress. NOTE: Remote submit to SESS9 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST9 to out=WORK.TEST9 NOTE: 383640 bytes were transferred at 3724369 bytes/second. NOTE: The data set WORK.TEST9 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST9 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.11 seconds cpu time 0.02 seconds NOTE: Remote submit to SESS9 complete. NOTE: Remote signoff from SESS9 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 56.43 seconds cpu time 54.96 seconds NOTE: Remote signoff from SESS9 complete. SYMBOLGEN: Macro variable I resolves to 10 NOTE: Remote submit to SESS10 commencing. 1 data &testds.; 2 do i = 1 to 100000 by 2; 3 L=0; 4 do j=1 to i; 5 k=0; 6 if (mod(i , j)= 0) then do; 7 k+1; 8 a=mod(i , j); 9 end; 10 if K=1 then L+1; 11 end; 12 If L=2 then output; 13 end; 14 run; NOTE: The data set WORK.TEST10 has 9591 observations and 5 variables. NOTE: DATA statement used (Total process time): real time 55.09 seconds cpu time 55.08 seconds 4 The SAS System Sunday, 21 March 2021 14:06:26 NOTE: Remote submit to SESS10 complete. NOTE: Background remote submit to SESS10 in progress. NOTE: Remote submit to SESS10 commencing. 15 proc download data=work.&testds. out=work.&testds.; 16 run; NOTE: Download in progress from data=WORK.TEST10 to out=WORK.TEST10 NOTE: 383640 bytes were transferred at 3675059 bytes/second. NOTE: The data set WORK.TEST10 has 9591 observations and 5 variables. NOTE: Downloaded 9591 observations of 5 variables. NOTE: The data set WORK.TEST10 has 9591 observations and 5 variables. NOTE: PROCEDURE DOWNLOAD used (Total process time): real time 0.11 seconds cpu time 0.00 seconds NOTE: Remote submit to SESS10 complete. NOTE: Remote signoff from SESS10 commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 56.30 seconds cpu time 55.20 seconds NOTE: Remote signoff from SESS10 complete. 164 165 166 167 /* proc datasets lib=work ; */ 168 /* delete test1-test5 ; */ 169 /* run; */ 170 171 172 %studio_hide_wrapper; SYMBOLGEN: Macro variable _STUDIONOTES resolves to SYMBOLGEN: Macro variable _STUDIOSOURCE resolves to SYMBOLGEN: Macro variable _STUDIOSTIMER resolves to SYMBOLGEN: Macro variable GRAPHTERM resolves to GOPTIONS NOACCESSIBLE; SYMBOLGEN: Macro variable _STUDIONOTES resolves to NOTES SYMBOLGEN: Macro variable _STUDIOSOURCE resolves to SOURCE SYMBOLGEN: Macro variable _STUDIOSTIMER resolves to STIMER 183 184   What does the CPU load look like for 10 sessions when run against a machine with 88 available threads (44 hyperthreaded cores)? Here's a screenshot when using the Htop command. CPU usage for 10 threads Select the image to see a larger version. Mobile users: To view the image, select the "Full" version at the bottom of the page.   Some final thoughts and comments: Stress testing CPUs outside of SAS can be done with readily available Linux utilities like "Stress" which are part of the RHEL/CentOS EPEL repository  Care should be taken when running any of these tests to ensure no other users are currently running workloads and the tests take a matter of minutes and not hours When running such tests, users must consider whether they are staying within  SAS licensing terms and conditions Having done this in Base SAS, it would be an interesting exercise to see how this could be done in CAS The possibility of using performing the same test in SAS Studio or Enterprise Guide without the need for SAS/CONNECT is something that is also of future interest Well that's all folks. I hope you found it interesting and I'm sure that that there will be some of you who can come up with additional ways to load an SMP using Base SAS code. Feel free to share what you know in the comments section below.   Thanks, Simon ... View more