Modifying the server configuration member for DRDA

If you are using a zIIP specialty engine, enable the RDBMS access method for Distributed Relational Database Architecture (DRDA) in the server configuration member.

About this task

Configure the server to use Distributed Relational Database Architecture (DRDA) when accessing a RDBMS.

Modify the server configuration member in data set hlq.AZKS.SAZKEXEC(AZKSIN00).

Procedure

  1. Verify that the Unicode translation of the Coded Character Set Identifier (CCSID) used in the DEFINE DATABASE statement and the CCSID used by the target RDBMS are defined for your z/OS environment.
    1. You should identify the CCSID of the RDBMS.

      For example, Oracle may use ccsid1. In your DEFINE DATABASE statement in the configuration member for the RDBMS you have ccsid2. For this example, where Oracle is using ccsid1, you need to verify that you have ccsid1-ccsid2 and ccsid2-ccsid1 defined in your Unicode translation table on z/OS using the command D UNI,ALL.

    2. If the entry is not present, you need to add the entry to your Unicode translation table and refresh.
      Please refer to the IBM z/OS documentation on how to add the entry.
      Note: As an alternative, the Unicode table can be appended within the server by using the following statement examples in the server configuration member:
      "DEFINE CONV SOURCE(ccsid1) TARGET(ccsid2) TECH(RE)" 
      "DEFINE CONV SOURCE(ccsid2) TARGET(ccsid1) TECH(RE)"
  2. In the AZKSIN00 member, locate the section that contains the comment “ENABLE DRDA ACCESS TO RDBMS.”
  3. Enable the DRDA parameters by changing if DontDoThis to if DoThis. Set the DRDASKIPZSERVICES parameter to YES.
    if DoThis then
      do
    		“MODIFY PARM NAME(TRACEOEDRDARW)        VALUE(YES)”
    		“MODIFY PARM NAME(CLIENTMUSTELECTDRDA)  VALUE(NO)”
    		“MODIFY PARM NAME(DRDASKIPWLMSETUP)     VALUE(NO)”
    		“MODIFY PARM NAME(DRDAFORLOGGINGTASK)   VALUE(NO)”
    The following table lists the parameters for configuring support for DRDA:
    Parameter Description Valid values
    CLIENTMUSTELECTDRDA
    If set to YES, JDBC clients must explicitly opt in for DRDA to be used by setting the user parameter connection variable to 'DRDA'.
    Note: JDBC clients can always opt out of DRDA processing by setting the user parameter to 'NODRDA'.

    If set to NO, DRDA processing is used for access all configured RDBMSs.

    YES
    NO
    Default value.
    DRDASKIPWLMSETUP

    If set to YES, WLM information is not collected and sent to DRDA during JDBC logon processing. If captured, the DRDA equivalent to SET_CLIENT_ID calls is issued after logon to establish these values on the DRDA connection. If not captured, the transmission that is used to set these WLM-related values is bypassed.

    If set to NO, the client user ID, application name, workstation name, and accounting token that were sent in the initial client buffer are collected and sent separately after logon processing to DRDA.

    YES
    NO
    Default value.
    DRDAFORLOGGINGTASK

    If set to YES, DRDA processing is used for the AZK DB2 on z/OS logging subtask.

    If set to NO, SAF or RRSAF connections are used.
    Note: Passticket support must be enabled for the target DDF server. If passticket support is not configured, set the parameter to NO.
    YES
    NO
    Default value.
    TRACEOEDRDARW

    If set to YES (recommended), TCP/IP communications via DRDA are traced.

    If set to NO, DRDA receive and send operations are not traced.

    YES
    NO
    Default value.
  4. Define DRDA RDBMSs by entering a definition statement. Provide your local environment values for all the parameters.
    "DEFINE DATABASE TYPE(type_selection)"         ,
                     "NAME(name)"                  ,
                     "LOCATION(location)"          ,
                     "DDFSTATUS(ENABLE)"	          ,
                     "DOMAIN(your.domain.name)"    ,
                     "PORT(port)"                  ,
                     "IPADDR(1.1.1.1)"             ,
                     "CCSID(37)"                   ,
                     "APPLNAME(DSN1LU)"            ,
                     "IDLETIME(110)"               ,       

    Where type_selection is either GROUP, MEMBER, or ZOSDRDA.

    The following table lists the parameters for defining DDF endpoints:
    Parameter Description Valid values
    APPLNAME

    Application name. The APPLNAME used by the target endpoint for passticket generations. (Optional)

    A valid value is 1 - 8 characters. If APPLNAME is not specified in the definition statement, no default value is provided and passticket access is disabled.

    Note: APPLNAME is not required when connecting from the JDBC driver.
    AUTHTYPE Authentication type. This can be either DES for Diffie Hellman Encryption Standard or AES for Advanced Encryption Standard.

    When AUTHTYPE is not supplied the default is DES. To force AES the option must be added to the DEFINE DATABASE, each server can be different in what is supported as to AES/DES.

    DES
    Diffie Hellman Encryption Standard (default value)
    AES
    Advanced Encryption Standard.
    CCSID

    Specify the EBCDIC single-byte application CCSID (Coded Character Set Identifier) configured for this RDBMS subsystem on the RDBMS installation panel DSNTIPF, option 7. (Optional)

    Refer to the RDBMS vendor documentation for a list of valid CCSID.
    DDFSTATUS

    The DDF activation status can be altered online by using the ISPF 4-DB2 dialog panels. (Required)

    ENABLE
    To make this DDF definition active within AZK.
    DISABLE
    DDF endpoint is not used.
    DOMAIN The part of a network address that identifies it as belonging to a particular domain. No default value.
    IPADDR Specify the dot-notation IPV4 address of the DDF endpoint. (Optional)

    If this parameter is not specified, the value 127.0.0.1 (local host) is the default. For group director definitions, use the DVIPA IP address of the group director.

    LOCATION

    For DB2: The DB2 location name.

    For LUW: The LUW database.

    For Oracle: The Oracle SSID as defined to the Oracle Database Provider (Gateway)

    (Required)

    A valid value is a string 1 - 16 characters.

    NAME

    The database name as known to the server. (Required)

    A valid value consists is 1 - 4 characters. Clients use this ID when they request access to a specific DB2 subsystem.
    PORT

    The TCP/IP port at which the server is listening. (Required)

    If this keyword is not entered, the default DRDA port number 443 is used.

    SECMEC The DRDA security mechanism in force for standard dashDB services requires an authentication method setting. Define as either USRENCPWD, which informs the server to encrypt the PASSWORD or EUSRIDPWD, which informs the server to encrypt the USERID and PASSWORD during the initial connection to dashDB. (For GROUP and MEMBER types.)
    USRENCPWD
    Encrypt password only.
    EUSRIDPWD
    Encrypt userid and password.
    TYPE

    For DB2 for z/OS:

    GROUP

    If this DDF endpoint is a DB2 group director, specify GROUP.

    MEMBER

    If this DDF endpoint is a DB2 instance or group member for z/OS, specify MEMBER.

    ZOSDRDA

    If this DDF endpoint is a remote LPAR access with SEF ATH rule processing, typically used for connecting to a DB2 on another LPAR that uses a different passwords as the local LPAR specify ZOSDRDA. An ATH rule may be necessary to manage the credentials. ZOSDRDA allows for ATH rule management of credentials.

    For DB2 for z/OS:

    GROUP

    MEMBER

    ZOSDRDA