I use kc [-n <namespace>] delete jobs --field-selector='status.successful=1' ... View more

You could always play around in SAS OnDemand for Academics for free... ... View more

It is more accurate to say 'if SAS/CONNECT is configured' instead of installed. SAS/CONNECT can be installed, but if you did not have any SAS/CONNECT Server Configurations (or SAS/CONNECT configurations) defined in your plan file, a SAS/CONNECT spawner would not have been configured and Logical CONNECT servers may not have been configured either. ... View more

You track things started on the grid through the Grid provider's UI.  SAS Workload Orchestrator serves up its own UI (no mid-tier needed) SAS has the SAS Grid Manager Module for SAS Environment Manager to serve up one for LSF (mid-tier required). Hadoop YARN has the UI for the YARN Resource Manager ... View more

SAS/CONNECT is a pre-requisite for any grid product so you should have it licensed, but unless your plan file specified CONNECT spawners to be running, they will not automatically be set configured by SDW.   SAS Grid can start CONNECT servers by adding the grdsvc_enable statement before the SIGNON statement so a spawner is not needed. CONNECT servers started this way are often called 'grid servers', but are just CONNECT servers started by the grid provider (SWO, LSF, YARN). ... View more

Since your RSUBMITs are followed immediately by SIGNOFFs, the CONNECT servers may be torn down before your code completes. You need to add WAITFOR statements to cause the SIGNOFFs to wait until the RSUBMIT code blocks complete.   I will agree with Patrick that having Tivoli just schedule all three jobs at the proper time seems like a easier approach. ... View more

If SEGVs occur on one specific machine, my guess would be that something is out of sync due to a incomplete or failed hotfix installation. Assuming all your machines are at the same version/maintenance level with the same hotfixes installed, compare the files in the <SASROOT>/SASFoundation/9.4 directory on a working machine to the ones on the failing machine to see if there are differences, specifically in shared library files *.so (UNIX/Linux) or *.dll (Windows).   Also, the SEGVs may occur in multiple SAS programs, but only when executing something similar (a specific PROC or data step function). If you can find out what it was executing when SEGV occurred, maybe that would help narrow it down. ... View more

I would try to find the similarities in the SEGVs. If you have multiple machines, do the SEGVs happen on a specific machine? Does it happen for a specific user? Does it happen for a specific SAS program? Does it happen during a specific time of the day? ... View more

While @AnandVyas is correct from a very very high level, there are a lot of decisions you need to make that can greatly affect the performance and availability of your SAS deployment. Things like What types of computers are you installing on? Do you have enough power to do the work you expect? If doing data intensive work (ETL), do they have enough IO throughput per core? If doing compute intensive work, do they have enough cores? How is the SAS processing going to be distributed across the computers? Will metadata/mid-tier/compute be shared on any machines? Are you going to install / config the deployment on each machine or will you install / configure to a shared filesystem and share the install / config to all other hosts? This will depend somewhat on the operating system you are going to use. UNIX/Linux deployments tend to install / configure to a shared filesystem and just mount that filesystem to all hosts. What shared filesystem are you going to use? At a minimum, LSF requires one but you need to ask yourself Is SASWORK going to be on the shared file system or local to each host? Is SAS data be stored on the shared filesystem? Are you going to have the metadata server failover to another host such that the filesystem needs to handle the metadata server? How are you going to keep the deployment highly available? SAS Professional Services can be engaged to help you with all of these questions and more. ... View more

While you could do a great deal of work to make SASGSUB with GRIDRUNSASLM work with -stdio, why are you not putting the code you want to execute in a file (like my-program.sas) and using that as the program to run? ... View more

So I take it you did not see a connection in the log put out by the spawner? I did not see a spawner log in your response.   The data sent to the spawner will not be encrypted at the start since it has to negotiate encryption first. If the firewall does not like that, SSH tunneling will be your only answer to getting through the firewall. ... View more

For test purposes, be more explicit about your SIGNON rather than default to variables since they may not contain what you think. Try   options netencralg=ssl; %let testrem=<spawner-host-FQDN> <spawner-port-number>; SIGNON testrem USER=_PROMPT_ password=_PROMPT_;   Also, turn on trace logging on the spawner so that you can see if a connection is made and a server is spawned. This will help you know if the client was able to get to the spawner or not and if it did, whether it was able to spawn a server. If the spawner does not show a connection being made, then the firewall is preventing access or there is no route from the client to the spawner. ... View more

SAS Management Console (SASMC) is a java program that runs on Windows/Linux/UNIX.   It is not a PC program like Enterprise Guide. ... View more