Hello @Babloo ,
yours is an excellent question, about concepts.
For SAS Grid, the unit is a Job. This is important, because a Job is, as said, a unit and what will be taken to execute in a Grid node or another.
First things first. SAS Grid manages it resources and will always bring a new Job, a unit, to the node that is less loaded, and as defined by the queue (and Grid Option Sets) where it enters, unless it is manually specified.
Secondly, a sas program, a .sas file, will be, in general, a Job, a unit. All of it. Unless, that you define in the code, the blocks of the code that can be considered as a unit, a Job. Then the SAS Grid will bring, a gain, the piece of code to the grid node that is less loaded and following the rules of the queues and Grid Option Sets.
Of course, you can also define manually in the code, what piece of code do you want it to run and where, if needed. In general, this option defeats a bit the purpose of the SAS Grid Manager, but it is also true that, in a few cases, it might be a good idea.
And last but not the least, there are a few procedures, such as DS2, that can allow, the same data step, to run multi-threaded and even on multiple Grid Nodes, maximizing your resource usage and performance.
All in all, I suggest you to peek into papers and documentation. Some good examples:
In addition, if you really want to monitor in detail the execution of any SAS job, grid or not grid, where they execute, the performance of each piece, etc, I would like to highly recommend you to give a chance to Boemska's Enterprise Session Monitor . If you are interested, you can get more information from @boemskats (I hereby summon you).
I hope this can help you. Please let us know if you need more information.
Kind regards,
Juan
