You must perform these steps on the XDB Server that will trust requests and perform inbound mapping. In the examples, the XDB Server sales is trusting and performing inbound mapping.
To update the system tables:
SET LOCATION TO system;
UPDATE sysibm.syslunames SET usersecurity = "A" WHERE luname = "servername" AND usernames = "I";
where:
A | indicates that requests from the XDB Server should be trusted. |
servername | is the name of another XDB Server from which AuthIDs will be mapped. |
I | indicates inbound mapping will be performed. |
In the examples on inbound mapping used in this topic, the SQL command:
UPDATE sysibm.syslunames SET usersecurity = "A" WHERE luname = "develop" AND usernames = "I";
would have been issued on the XDB Server sales.
INSERT INTO sysibm.sysusernames VALUES("I","authid","servername", "newauthid","");
where:
I | indicates inbound mapping will be performed. |
authid | is the name of the AuthID to be translated from. |
servername | is the name of the server from which the AuthID to be translated will originate. |
newauthid | is the new AuthID that will be given. |
In the examples on inbound mapping used in this topic, the SQL command:
INSERT INTO sysibm.sysusernames VALUES("I","bruce","develop","developr","");
would have been issued on the XDB Server sales.
REFRESH LOCATIONS;
Use the SQL GRANT command to grant the appropriate privileges to the new AuthIDs. In the examples on inbound mapping and trusting used in this topic, the AuthID developr would have to be granted SELECT privileges on the table may in the location orders.