Server access control exit programs
A security feature of the Distributed Relational Database Architecture™ (DRDA) server, for use with both Advanced Program-to-Program Communication (APPC) and TCP/IP, extends the use of the DDMACC parameter of the Change Network Attributes (CHGNETA) command to DRDA.
The parameter previously applied only to DDM file I/O access. The DRDA usage of the function is limited to connection requests, however, and not to requests for data after the connection is made.
If you do not choose to use this security function, you normally do not need to do anything. The only exception is if you are currently using a DDM exit program that is coded to reject operations if an unknown function code is received, and you are also using DRDA to access data on that system. In this case, you must change your exit program so that a '1' is returned to allow DRDA access if the function code is 'SQLCNN '.
To use the exit program for blocking or filtering DRDA connections, you need to create a new DRDA exit program, or change an existing one.
You can find general instructions for creating a DRDA exit program in the Distributed data management topic.
This security feature adds a DRDA function code to the list of request functions that can be input to the program in the input parameter structure. The function code, named 'SQLCNN ' (SQL connect request), indicates that a DRDA connection request is being processed (see the FUNC parameter in Example: DRDA server access control exit program). The APP (application) input parameter is set to '*DRDA ' instead of '*DDM ' for DRDA connection request calls.
When you code exit programs for DRDA, the following fields in the parameter structure might be useful:
- The USER field allows the program to allow or deny DRDA access based on the user profile ID.
- The RDBNAME field contains the name of the RDB to which the user wants to connect. This can be the system database or a user database (ASP group). This field can be useful if you want to deny access to one or more databases in an environment where multiple databases are configured.
- The SRVNAME parameter in the topic Example: DRDA server access control exit program might or might not be set by the caller of the exit program. If it is set, it indicates the name of the client system. If it is not set, it has the value *N. It is always set when the DRDA application requester is a System i® product.
- The TYPDEFN parameter gives additional information about the type of client that is connecting. For an IBM® mainframe, TYPEDEFN is QTDSQL370. For a System i product, it is QTDSQL400. For an Intel PC, it is QTDSQLX86. For an RS/6000® client, it is QTDSQLASC.
- The PRDID (product ID) parameter identifies the product that is
attempting to connect, along with the product's release level. Here
is a partial list of the first three characters of these codes (You
should verify the non-IBM codes before you use them in an exit program):
- QSQ
- IBM DB2® for i
- DSN
- IBM DB2 for z/OS®
- SQL
- IBM DB2 for Linux, UNIX, and Windows (formerly called DDCS)
- ARI
- IBM DB2 for VSE & VM
- GTW
- Oracle Corporation products
- GVW
- Grandview DB/DC Systems products
- XDB
- XDB Systems products
- IFX
- Informix® Software products
- SIG
- StarQuest products
- STH
- FileTek products
- JCC
- IBM DB2 Universal Driver for SQLJ and JDBC
If the exit program returns a RTNCODE value of 0, and the connection request came from an IBM i client, then the message indicating the connection failure to the user will be SQ30060, User is not authorized to relational database ... In general, the response to a denial of access by the exit program is the DRDA RDBATHRM reply message, which indicates that the user is not authorized to the relational database. Different client platforms might report the error differently to the user.
Restrictions:
- If a function check occurs in the user exit program, the program returns the same reply message, and the connection attempt will fail. The exit program must not do any committable updates to DB2 for i, or unpredictable results might occur.
- You should not use exit programs to attempt to access a file that was opened in a prior call of the prestart server job.
- Prior to V5R2, a further restriction resulted when the prestart jobs used with the TCP/IP server were recycled for subsequent use. Some cleanup is done to prepare the job for its next use. Part of this processing involves using the Reclaim Activation Group (RCLACTGRP) command with the ACTGRP parameter with value of *ELIGIBLE. As a result, attempts to use any residual linkages in the prestart server job to activation groups destroyed by the RCLACTGRP can result in MCH3402 exceptions (where the program tried to refer to all or part of an object that no longer exists). One circumvention to this restriction is to set the MAXUSE value for the QRWTSRVR prestart jobs to 1 as follows: CHGPJE SBSD(QSYSWRK) PGM(QRWTSRVR) MAXUSE(1).