Hi Hilario,
the user priority is attached to a specific user, this user is identified by the user´s ETID (userid) and this is the value gets specified when the user issues an OP command (Additions-1 field).
The program accessing Adabas has to specify this value when executing the OP command (which is not necessary always).
At one time there can only one user with the same userid (ETID) be active.
Natural:
In Natural this is called the ETID, and this can be set in various way (see Natural documentation). ´Normally´ this is the logon id. You can for example influence the Natural ETID when specifying it explicitly when executing a batch job.
If you like to classify the users in groups such as batch, online (CICS, TSO etc), remote you need to come up with a userid(ETID) concept. I suppose that especially for remote users this will be not so easy. And you should be sure that different ´users´ are using different ETIDs, otherwise you get rsp-48 and rsp-9 conflicts.
Definition of the user priority is done via AOS or ADADBS. You specify the userid and the associated user priority. Which is very cumbersome if you have thousands of users
But the good news are: the priority influences the selection of the command out of the commandqueue only. And for this selection priority we use (mostly) a combined value out of
- the user priority (maybe set)
- an operating system dispatching priority (maybe set by the interregion communication) and
- the age of the command in the commandqueue.
This value cannot be seen
Normally sooner than later the command will get selected and then it will be processed (equally to the other commands).
It is more wisely (but maybe other customer can give an advice here 8)) to think about the system priority of the Adabas task, versus the CICS task, versus the Net-work task, the broker etc. I.e. if the Adabas task has low priority compared to the other tasks these others might send so many commands and no matter how the priority is set this will overwhelm your Adabas task.
I would suggest that you look at the number of threads used in comparision with the commandqueue, see if there are system bottlenecks in the I/O area and think about other ´tuning´ methods. And from the other side not every command ´costs´ the same, compare an RC command with a complex Search command.
This was now a long explanation, hopefully it helps :roll: