QDDMDRDASERVER special value in server authentication entries

Answer

To reduce the administrative burden, special value QDDMDRDASERVER is now allowed for DDM and DRDA connections. Administrators may specify QDDMDRDASERVER in the SERVER parameter of the Add Server Authentication Entry (ADDSVRAUTE) command. This new special value allows a user to make DDM or DRDA connections to any system in the TCP/IP network via a common userid and password.
This prevents having to add individual server authentication entries for each DRDA application server and for each user profile on the system.
For DRDA or RDB DDM files, this resolves the problem of having to add new server authentication entries for every user profile each time a new systems has been added to the TCP/IP network.

Special value QDDMSERVER already exists which allows for non-RDB DDM file users to make DDM connections to servers with a common userid and password. The new special value QDDMDRDASERVER is a superset of QDDMSERVER, expanding this support to RDB DDM files and DRDA connections.

For DRDA connection requests, if a server authentication entry specifying the system name exists, and a user ID and password are not passed in on CONNECT statement, the user ID and password associated with the server authentication entry will take precedence over the server authentication entry for QDDMDRDASERVER.

For DRDA connection requests, if a server authentication entry specifying the system name exists, and a user ID and password are passed in on CONNECT statement, the user ID and password associated with the CONNECT statement will take precedence over any server authentication entry.

For RDB DDM file connection requests, the server authentication entry specifying the system name will take precedence over the server authentication entry for QDDMDRDASERVER.

For non-RDB DDM file connection requests, the server authentication entry QDDMSERVER will take precedence over the server authentication entry for QDDMDRDASERVER.

As before, this does not allow a customer to connect over DRDA/DDM unless they specify a valid userid and password on the server authentication entry or CONNECT statement.

Example 1:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requester (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid)  
PASSWORD(yourpwd)
STRSQL
CONNECT TO SYSB
CONNECT TO SYSC

At this point you have two connections made with userid 'youruid' and password 'yourpwd'.


Example 2:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requester (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid)  
PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSB) USRID(yourotheruid)      
PASSWORD(yourotherpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSC) USRID(yourotheruid)      
PASSWORD(yourotherpwd)
STRSQL
CONNECT TO SYSB
CONNECT TO SYSC

At this point you have two connections made with userid 'yourotheruid' and password 'yourotherpwd'. This occurs because server authentication entries specifying the real system name take precedence over server authentication entries specifying QDDMDRDASERVER.

Example 3:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requester (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid)  
PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSB) USRID(yourotheruid) PASSWORD(yourotherpwd)
STRSQL                                                            
CONNECT TO SYSB user testuserid using 'testpassword'              
CONNECT TO SYSC    

At this point you have two connections. The connection to SYSB would be made with userid 'testuserid' and password 'testpassword'. This occurs because specifying userid and password on a CONNECT statement takes precedence over server authentication entries. The connection to SYSC would be made with userid 'youruid' and password 'yourpwd' since it will use the QDDMDRDASERVER authentication entry when no other server authentication entry exists specifying the system name.

Example 4:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requester (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid)  
PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMSERVER) USRID(youruid2)
PASSWORD(yourpwd2)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSC) USRID(yourotheruid) PASSWORD(yourotherpwd)
CRTDDMF FILE(QTEMP/DDMF) RMTFILE(FILE) RMTLOCNAME(SYSB *IP)      
CRTDDMF FILE(QTEMP/DDMF2) RMTFILE(FILE) RMTLOCNAME(*RDB) RDB(SYSB)
CRTDDMF FILE(QTEMP/DDMF3) RMTFILE(FILE) RMTLOCNAME(*RDB) RDB(SYSC)

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF)    

The connection to SYSB would be made with userid 'youruid2' and password 'yourpwd2'. This occurs because non-RDB DDM files will use QDDMSERVER for userid and password at connection time. If QDDMSERVER didn't exist, QDDMDRDASERVER would be used.

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF2)

The connection to SYSB would be made with userid 'youruid' and password 'yourpwd'. This occurs because RDB DDM files will use QDDMDRDASERVER for userid and password at connection time if a server authentication entry doesn't exist specifying the system name.

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF3)
The connection to SYSC would be made with userid 'yourotheruid' and password 'yourotherpwd'. This occurs because RDB DDM files will not use QDDMDRDASERVER for userid and password at connection time if a server authentication entry exists specifying the system name.