With SAS Grid Manager in 9.4M6, the deployment of SAS Workload Orchestrator and SAS Job Flow Scheduler are through the SAS Deployment Wizard and you should be able to use its unattended install feature to install your deployment.   Previous versions of SAS Grid Manager (now called SAS Grid Manager for Platform in SAS 9.4M6) had the installation of Platform Suite for SAS as a 3rd party install prerequisite for the SAS Deployment Wizard so SDW's unattended install feature would not be able to be used for Platform Suite for SAS. However, the installation of Platform Suite for SAS on Linux is a command line based install that could probably be automated without much trouble.   If you install & configure to a shared file system (as opposed to a local file system), new machines may be able to be added/removed without having to reinstall/redeploy your software - you would just need to start the necessary services on your new machine. ... View more

When SAS Deployment Wizard runs, it asks for the Ambari admin password to be able to get information about your deployment so it can configure SAS to work with your Hadoop cluster properly. That password is not saved after the configuration is run so you should be able to change the Ambari admin password without affecting your SAS deployment. ... View more

Generally when that happens, hosts are defined on the queue that do not match up with hosts defined under the logical workspace server.   For example, the following will not work since the list of hosts for both do not intersect: The queue 'big' has hosts Big1 and Big2 defined as the hosts the jobs can run on. The SASApp logical workspace server has hosts Small, Medium, and Large defined on it. To fix the problem Big1 and Big2 would need to be added to the logical workspace server list of hosts.   If that is not the problem, contact tech support so they can get the proper logs from the object spawner so the issue can be debugged. ... View more

Sure. You just need to create an options set that has the job option 'queue=<name_of_queue>'. Then you create a mapping from 'SAS Enterprise Guide' to whatever users you want to use that options set so that they get the queu you defined in that options set. ... View more

You do not want users to define the queue they run in; you want the SAS administrator to define which queue the user runs in.   If users could define the queue they run in, all users would chose the highest priority queue since they think their work is the most important. 😁   Remember, the queue just determines the launching of the workspace server. Individual code submits do not start a new workspace server, they just send new code to the same workspace server. ... View more

I see that I am not making this clear. There are two ways to run SAS code through EG on a SAS server launched in the grid. The old method (spawner launched workspace server spawning a grid-launched CONNECT server) is controlled by EG since it is EG that adds code to the workspace server initialization to launch the grid-server. The new method (grid-launched workspace servers) is controlled by the object spawner and is independent of settings in EG. Options set mappings are applied by the object spawner for grid-launched workspace servers.   To sum it up, you do not need to do anything in EG to get the benefit of grid-launched workspace servers and options set mappings. In fact, if you are using EG with grid-launched workspace servers, you should set the EGGridPolicy/AMOGridPolicy to 'Ignore' so that EG does not try to auto-submit code to the newly launched workspace server to attach to a grid-launched CONNECT server. ... View more

Back in 9.2 and 9.3 there were no grid-launched workspace servers as there are in 9.4. To simulate grid-launched servers back then, the spawner-launched workspace server would spawn a grid-launched CONNECT server (a.k.a., grid server), and all code submitted to the workspace server was wrapped in a RSUBMIT and sent to the CONNECT server. To make the workspace server spawn a grid server for processing, EG added the 'Use grid if available' option.   With the advent of true grid-launched workspace servers in 9.4, the EG 'Use grid if available' is no longer needed since the workspace server itself is launched in the grid. If you use the EG 'Use grid if available' in conjunction with a grid-launched workspace server results in two grid jobs - one for the workspace server and one for the spawner CONNECT server. So in short, always use grid-launched workspace servers and do not use the EG 'Use grid if available' or 'Initialize Grid (if available)' options. Later versions of EG will detect that grid-launched workspace servers are being used and will disable the 'Use grid if available' or 'Initialize Grid (if available)' options; doing automatically what adding the EGGridPolicy/AMOGridPolicy set to Ignore does manually. ... View more

You do not need the IsGridCapable setting - SAS Enterprise Guide is already grid capable (you should see it as a application when creating a grid options set without this setting).   Your pictures do not show who you have selected to be able to use the option set in your doc. An option set mapping has an application (SAS Enterprise Guide), an options set (EGforPowerusers), and user/groups that this options set mapping should be applied to. Do you have the metadata ID of the user you want to use the options set selected? When you signed into EG, did the credentials for that user map to the metadata ID of the user in the options set mapping?   Example: 1) I have a logical workspace server setup to do grid-launched workspace server load balancing for application server context 'SASApp' 2) I have a logical grid server with an options set mapping for 'SAS Enterprise Guide' to the options set 'EGforPowerusers' for the metadata ID 'Doug' for the application server context 'SASApp'. 3) When I log into EG, I use the OS user ID 'doug_sas'. 4) I have a User record in SAS Management Console's User Manager for the metadata user 'Doug' that has an account for the DefaultAuth domain with a user ID of 'doug_sas' so that the OS user 'doug_sas' is known in metadata as 'Doug'   When EG goes to launch a workspace server from the SASApp server context, the object spawner logs into the metadata server with the OS credentials and gets the grid information for the logical grid server. The grid information should see that the request is for 'SAS Enterprise Guide' grid application for the metadata user 'Doug' for the application server context 'SASApp' and use the queue from the EGforPowerusers options set. ... View more

If you have SAS/CONNECT on both deployments (you do for 9.4M6 since you have Grid), you can use PROC UPLOAD/DOWNLOAD which will convert data set contents from source to target format as it moves the data between systems. You can get more information in the Data Transfer Services section of the SAS/CONNECT User's Guide. ... View more

If you are asking whether you can use a single grid to run jobs from separately deployed SAS 9.4M5 and SAS 9.4M6 environments, the answer is yes.   If you are asking whether you can use multiple installs of grid software on the same machines to run separately deployed SAS 9.4M5 and SAS 9.4M6, the answer is no. Two resource managers on the same machines cause scheduling problems. ... View more