Thanks for the reply @JuanS_OCS, however adding a new server context isn't going to help in our situation. We want to manage where the WORK library is defined as well as MEMSIZE and SORTSIZE settings for different sets of users who use the same applications. So a single context is what we have and meets our needs. In general, the concept of the Grid Option Sets (GOS) is exactly what we like. However, where it seems to fall short, and is not completely reliable, is that it won't resolve users to a predictable GOS if the user meets the filtering criteria of more than 1 GOS. At least, I haven't discovered the rules by which it seems to work. If you are careful and set them up so that all users have mutually exclusive relationships with the groups chosen for the filters, then it does work somewhat reliably. The one constant, repeatable test, that I can always count on working is that if a user is directly assigned a GOS for EG for example, they will successfully use that GOS, even if there is another EG GOS that is assigned to SASUSERS. Where it gets tricky is if there is a GOS that is assigned to a metadata group that a user belongs to as well as a GOS that is assigned to SASUSERS. In that case, I would assume that because the user is assigned to a group, it would have a higher order of precedence over SASUSERS, and therefore get to use that particular GOS. However, it is not always the case, and often they get the GOS that was for SASUSERS. Herein lies my problem. It seems like this functionality was not accounted for in the development of this feature, which is what I'm trying to find out. Yet, this same logic is how the ACTs work and would be extremely helpful in this context as well.
... View more