We have installed and configured SAS 9.4 M5 Grid Version in a Linux environment.
We have configured four queues for job submission
We are trying a submit a job with priority queue through EG.
By default EG Job runs in normal queue.
We have set the options based on few support papers
But still EG job always runs on normal by default.
Could you please suggest here.
Some screenshots attached in the document.
When a grid-launched Workspace Server is requested from the Object Spawner, the spawner performs a check for any grid options sets associated with the requesting user and application.
In your example the jobs are not being submitted by the Object Spawner but by Enterprise Guide directly. You can see this based on the job name "EG*" instead of SAS Enterprise Guide.
This means you are not using grid-launched Workspace Servers but the grid functionality built in to Enterprise Guide, which does not use Grid Options Sets or specify a queue.
Switching your Workspace Servers to grid-launched and turning off the Use grid if available option in Enterprise Guide would allow the options set to be used, and prevent duplicate SAS sessions (the client Workspace Server session Enterprise Guide is using to start the grid sessions would not be required).
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?
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.
Thanks for the response.
As per the instructions we have converted the workspace servers as grid launched.
The jobs in EG are running now always in priority queue.
We have set the properties in extended attributes as mentioned in the documents and papers.
we have used the values Ignore,NoForce in the extended attributes for EGGridPolicy and AOMGridPolicy. But still the job is running as Grid launched server.
We want the user to select the 'grid options if available' from SAS EG.
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.
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.
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.
This documentation talks more about the EGGridPolicy and AMOGridPolicy settings:
Essentially, as @doug_sas mentions, when using grid-launched workspace servers you would want to set these to "Ignore" to prevent the client application (EG or AMO) from launching a second session to the grid from the workspace server which is already running as a grid job. In this scenario the grid-launched workspace server uses grid options sets specified in SAS Management Console to apply changes like queue selection based on the user and application requesting the workspace server.
If you were trying to launch child grid jobs from the grid-launched workspace server (for parallel execution for example), you can use GRDSVC_ENABLE to start child grid job sessions and connect to them using SAS/CONNECT like EG and AMO did behind the scenes when "use grid if available" was in play. With that function you can specify job options like queue or manually reference a grid option set.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.