There is no max number.    Memory and CPU constraints will create a practical limit, but the real throttle is on the number of jobs that are running and that can be handled by LSF. ... View more

If there are any questions that go unanswered about SAS Workload Orchestrator, you can ask them here and I will try to answer them. ... View more

  LSF must be running on all nodes in the grid.   If using grid-launched SAS servers, the object spawner is really only needed to be running on one machine, but it will spread out the job launching to other object spawners if available.   Is something currently not working?   Users must be defined on all hosts in the grid and have home directories available on every node in the grid. Having users be able to log into the machines is probably not what you want. That allows the users to bypass the workload management provided by the grid. By 'login enable' I am assuming you mean they are able to ssh to the grid machines and run commands.   ... View more

Hard to say what the problem was.   Sometimes copy/paste from web to SAS does not translate the characters correctly.   Maybe it will work if you hand-type it instead of copy/paste. ... View more

The remote session ID is 'host' but it is also a macro variable which SAS/CONNECT should be able to use to get the spawner host and the spawner port.   The format would be something like   %let <remote_session_id_variable>=<host_spawner_is_running_on> <port_spawner_is_listening_on>; signon <remote_session_id_variable> username='<your_user_name>' password='<your_password>';   In the original case, the <remote_session_id_variable> was 'host'.   It could have easily been   %let myhostv=myHost.myDomain.com 7551; signon myhostv user='<your_user_id>' pwd='<your_pwd_on_host>'; signoff; Change myHost.myDomain.com to the host name where you have the spawner running. Change 7551 to the port that the spawner is listening on. ... View more

The 'support parallel jobs' feature listed in the table means the ability to submit to the workload manager a single job request that results in multiple processes being started on multiple machines. This would be used, for example, to start an MPI job on the grid that spans multiple machines.   SAS Grid Manager has never used parallel jobs or something like MPI to do its work. Parallelism in SAS code is done via SAS/CONNECT. SAS code would start multiple CONNECT servers using grid-enabled SIGNON statements which results in a single grid job for each server process. The SAS code would then submit SAS code to each server using the RSUBMIT/ENDRSUBMIT statements. Assuming the RSUBMITs set the option to process the remote code asynchronously, all the code on all servers execute in parallel. You still get the parallelism, but it is not done via a single job request - it is done through multiple job requests.   So 'parallel jobs' are not needed to be able to run parallel SAS code. Actually SAS/CONNECT allows you to run parallel SAS code without needing SAS Grid Manager.   ... View more

SAS Grid Manager creates single jobs. Parallel SAS programming requires multiple grid-enabled SAS/CONNECT SIGNONs which each are a single job.   Parallel jobs would be to support a job that uses something like MPI across multiple machines. For that we have Viya's Cloud Analytic Services. ... View more

I can give a feature comparison for SAS Workload Orchestrator vs LSF vs YARN (from my upcoming SGF 2019 presentation): Feature SAS Workload Orchestrator Platform LSF Hadoop YARN Preemptable priority queue-based scheduling Yes Yes Yes Fairshare based scheduling No Yes Yes Host selection by sorting on dynamic resources values Yes Yes No Host selection by static accounting Yes No Yes Job preemption by suspension Yes Yes No Pluggable scheduling logic No No Yes Time-based queue configuration Yes Yes No Time-based host configuration Yes Yes No Time-based hostgroup configuration No Yes No Time-based usergroup configuration No Yes No Time based configuration time definition Cron Expression Day of week, time of day N/A Scheduling based on dynamic resources Yes Yes No User-defined resources Yes Yes No Scheduling thresholds based on resources Yes Yes No Suspension thresholds based on resources Yes Yes No Scheduling dispatch windows Yes Yes No Queue active job limits Yes Yes No Terminate jobs when limit exceeded Yes Yes No Job request specifies minimum resource requirements Yes Yes No Job request specifies consumable resource requirements Yes Yes Yes Job request specifies Boolean resources Yes Yes Yes Job owner Authenticated user on job submission Process owner of job submission Authenticated user on job submission Authentication Username/password, Kerberos Process owner Kerberos Data-in-motion security SSL Proprietary SSL Data-at-Rest security File based permissions. Sensitive data encrypted using AES128 with key derived from site-defined password (SHA256, 10000 iterations) File based permissions. Sensitive data encrypted with internally defined key, AES128 File-based permissions. End-to-end Kerberos to run jobs Yes No No Type of jobs that can be run Any SAS only Any Embedded GUI Yes No Yes Dynamic configuration Yes No No REST-API Based Yes No Yes Configuration files One Multiple Multiple Ability to start/stop VMs as needed No Yes No Support parallel jobs No Yes Yes Ability to change job information before it gets into the queue Yes Yes No Supported Operating Systems Windows X64, Linux X64 All SAS v9 Windows and UNIX server platforms Linux X64 ... View more

When you enter a metadata password, make sure it is for the metadata user that is specified in the sasgsub.cfg file. If the user in the config file is not correct use the -metauser option to change it.   It could also be that you do not have access to the shared directory that SASGSUB will try to create a job directory and copy the program.   You could run SASGSUB with the -verbose option and may be able to see at what point the access is denied. ... View more