PSRA Notes Primary Server Route Authority

PSRA Notes (Primary Server Route Authority)

Setting PSRA=Y indicates that authority checks should be routed to the server. The following notes apply to using the PSRA (or an equivalent) option:

It is recommended that you choose one of these methods to use this option:

• Put PSRA=Y into a profile file or,

• In your connection routine, put a USE SET_SESSION_VALUE (PSRA Y) command to set the value on the fly. This should be done before you define and make the connection or,

• In your DEFINE_XXXXXXXX_SERVER command, set the lock objects value to Z (which means route lock requests and route authority requests).

Things you should know about using PSRA=Y (or an equivalent option) include:

• If you are using authority checks to limit or restrict access to an initial process menu or action bar item and are creating a SuperServer connection by using the PSxx command line parameters, then remember that the SuperServer connection is not created until the first function is executed. Any initial process menu or action bar would be presented before the SuperServer connection is created. To resolve this issue create an entry point function that itself calls the initial process menu and then invoke it (instead of the initial process menu) from the command line.

• The use of PSRA=Y (or equivalent) has a performance impact because more trips to the server are required.

• Authority checks are optimized by being kept in memory, so if you change authority settings any active jobs/processes may not see the changes immediately (LANSA for i works the same way).

• If the user profile or the group profile you are using is QSECOFR, or the LANSA partition security officer, or the LANSA system owner then you always get access. No authority checks are actually made.

• Authority checks check authority. They do not check for existence and cannot be viably used to do this.

• Process, Function and File Security can be enabled in one of two ways. The recommended way is through System Maintenance. The alternative method is to modify Regional Settings in the X_DEFppp.H Definition Header File.

• If file security is disabled (which is the shipped default) then you will always get access to files.

• If process security is disabled (which is the shipped default) then you will always get access to processes and functions.

• If function security is disabled (which is the shipped default) then you will always get access to a function.

• If you are running in SuperServer mode and have no accessible local database and are using PSRA=N (the default) then you will always get access. There is effectively no security when working in this mode.

• If a security check for a function is being made, and no security information at all exists for the function, then the authority of the owning process is "adopted". This logic (which has always existed) is designed to accommodate sites that suddenly turn on function level security (and thus have no security information available for their existing functions).