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.
Note: If your system is configured with multiple databases (ASP groups), the
exit program must reside in a library in the system database (on an auxiliary
storage pool in the range 1-32).
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 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 will always be set when the DRDA Application Requester is an iSeries™ server.
- The TYPDEFN parameter gives additional information about the type of client
that is connecting. For an IBM® mainframe, TYPEDEFN will be QTDSQL370. For an iSeries server, it will be QTDSQL400. For
an Intel® PC,
it will be QTDSQLX86. For an RS/6000® client, it will be 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 Universal Database™ for iSeries
- DSN
- IBM DB2
Universal Database™ for z/OS®
- SQL
- IBM DB2
Universal Database for Linux®, Unix and Windows® (formerly
called DDCS)
- ARI
- IBM DB2
Universal Database for VSE & VM
- GTW
- Oracle Corporation products
- GVW
- Grandview DB/DC Systems products
- XDB
- XDB Systems products
- IFX
- Informix® Software
products
- RUM
- Wall Data Rumba for Database Access
- SIG
- StarQuest products
- STH
- FileTek products
- JCC
- IBM DB2® Universal
Driver for SQLJ and JDBC
The rest of the field is structured as vvrrm,
where vv is version, rr is release, and m is
modification level.
If the exit program returns a RTNCODE value of '0', and the connection
request came from an iSeries 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. Note that 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 UDB for iSeries,
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).