The AS/400 system implements the DRDA application requester support as an integral part of the OS/400 operating system. Because application requester support is part of the OS/400 operating system, it is active whenever the operating system is active. This is also true of the application server support in DB2 Universal Database for AS/400.
When DB2 Universal Database for AS/400 acts as an application requester, it can connect to any application server that supports DRDA. For the DB2 Universal Database for AS/400 application requester to provide distributed database access, you need to consider the following:
The Application Requester must be able to accept a relational database name and translate it into network parameters. The AS/400 system uses the relational database directory to register relational database names and their corresponding network parameters. This directory allows the AS/400 application requester to pass the required network information to establish communications in a distributed database network.
Much of the processing in a distributed database environment requires messages to be exchanged with other locations in the network. For this processing to be performed correctly in the SNA environment you need to do the following:
Define the local system to DB2 Universal Database for AS/400
Define the remote system to DB2 Universal Database for AS/400
Define communications to DB2 Universal Database for AS/400
Each application requester in the distributed database network must have an entry in its Relational Database Directory for its local relational database and one for each remote relational database the application requester accesses. Any AS/400 system in the distributed database network that acts only as an application server must have an entry in its relational database directory for the local relational database. For more information about the relational database directory, see AS/400 Distributed Database Programming.
To define the local system, name the local database by adding an entry with a remote location name of *LOCAL to the relational database directory. To do this, use the Add Relational Database Directory Entry (ADDRDBDIRE) command. The following example shows the ADDRDBDIRE command, where the name of the application requester's database is ROCHESTERDB:
ADDRDBDIRE RDB(ROCHESTERDB) RMTLOCNAME(*LOCAL)
For more detail on relational database directory commands, see AS/400 Distributed Database Programming.
| Note: | In the latest versions of OS/400, the local RDB name entry be created automatically if it does not already exist when it is required. The system name in the network attributes will be used as the local RDB name. |
Each application server in the distributed DB network must also have a local entry in its RDB directory. In addition, an entry for each remote database must be present in the RDB directory of each application requester. To create these:
For most cases, the only information needed is the remote database name and the remote location name 4 of the database. When only the remote location name is specified, default values are used for the remaining parameters. The system selects a device description using the remote location name.
If more than one device description contains the same remote location name and a specific device description is required, then the values for local location name and remote network identifier in the relational database directory entry should match the values in the device description. The selection of device descriptions can be complicated if the same remote location name is used in more than one device description. Use unique remote location names in each device description to avoid confusion. The transaction program name of the remote database defaults to the DRDA default transaction program name of X'07F6C4C2'.
The communications information in the relational database directory is used to establish a conversation with the remote system.
For TCP/IP connections (supported in DB2 Universal Database for AS/400 Version 4.2), only the remote database name and associated IP address and port are required. See Connecting DB2 Universal Database for AS/400 in a DRDA Network Using TCP/IP.
This section describes configuring communications on the AS/400 system using Advanced Peer-to-Peer Networking (APPN). The AS/400 system also allows advanced program-to-program communications (APPC) configurations, which do not provide network routing support. An AS/400 distributed database works with either configuration. For more information about APPC configurations, see OS/400 Communications Configuration.
AnyNet Support on the AS/400 allows APPC applications to run over Transmission Control Protocol/Internet Protocol (TCP/IP) networks. Examples in the sections that follow include DDM, Systems Network Architecture Distribution Services, Alerts, and 5250 Display Station Pass-Through. These applications, along with DRDA, can run unchanged over TCP/IP networks with some additional configuration. To specify AnyNet support, you specify *ANYNW on the LINKTYPE parameter of the CRTCTLAPPC command.
For more information on APPC over TCP/IP, refer to OS/400 Communications Configuration and OS/400 TCP/IP Configuration and Reference. (Note that native TCP/IP support for DRDA communications is provided in DB2 Universal Database for AS/400 Version 4.2. See Connecting DB2 Universal Database for AS/400 in a DRDA Network Using TCP/IP.)
APPN provides networking support that allows the AS/400 system to participate in and control a network of systems without requiring the networking support traditionally provided by a mainframe system. The following steps tell you how to configure an AS/400 system for APPN support.
The network attributes contain:
The line description describes the physical line connection and the data link protocol to be used between the AS/400 system and the network. Use the following commands to create line descriptions:
The controller description describes the adjacent systems in the network. Indicate the use of APPN support by specifying APPN(*YES) when creating the controller description. Use the following commands to create controller descriptions:
If the AUTOCRTCTL parameter on a token-ring or Ethernet line description is set to *YES, then a controller description is automatically created when the system receives a session start request over the token-ring or Ethernet line.
Use class-of-service description to select the communication routes (transmission groups) and give transmission priority. Five class-of-service descriptions are supplied by the system:
Create other class-of-service descriptions using the Create Class-of-Service (CRTCOSD) command.
The mode description gives the session characteristics and number of sessions that can be used to negotiate the allowed values between the local and remote location. The mode description also points to the class of service that is used for the conversation. Several predefined modes are shipped with the system:
Other mode descriptions can be created using the Create Mode Description (CRTMODD) command.
The device description provides the characteristics of the logical connection between the local and remote systems. You do not have to manually create device descriptions if the AS/400 system is running to a host system with APPN and as an independent logical unit (LU). The AS/400 system automatically creates the device description and attaches it to the appropriate controller description when the session is established. If the AS/400 system is a dependent LU, then you must manually create the device descriptions using the Create Device Description (CRTDEVAPPC) command. In the device description, specify APPN(*YES) to indicate that the APPN is being used.
If additional local locations (called LUs on other systems) or special characteristics of remote locations for APPN are required, then you need to create APPN location lists. The local location name is the control point name specified in the network attributes. If you need additional locations for the AS/400 system, an APPN local location list is required. An example of a special characteristic of a remote location is if the remote location is in a network other than the one the local location is in. If the conditions exist, an APPN remote location list is required. Create APPN location lists by using the Create Configuration List (CRTCFGL) command.
You can activate the communication descriptions by using the Vary Configuration (VRYCFG) command or the Work With Configuration Status (WRKCFGSTS) command. If the line descriptions are activated, then the appropriate controllers and devices attached to that line are also activated. The WRKCFGSTS command is also useful for viewing the status of each connection.
RU sizes and pacing are controlled by values specified in the mode description. When you create the mode description, defaults are provided for both RU size and pacing. The default values are an AS/400 estimate for most environments including a distributed database. If the default is taken for RU size, the AS/400 system estimates the best value to use. When the AS/400 system is communicating with another system that supports adaptive pacing, the pacing values specified are only a starting point. The pacing is adjusted by each system depending on the system's ability to handle the data sent to it. For systems that do not support adaptive pacing, the pacing values are negotiated at session start, and remain the same for the life of the session. For more information, see OS/400 Communications Configuration.
Notes:
For more information about configuring for networking support and working with location lists, see the OS/400 Communications Configuration and APPN Support. For examples showing use of CL commands to define system configurations, see AS/400 Distributed Database Programming.
When a remote system performs distributed database processing on behalf of an SQL application, it must be able to satisfy the security requirements of the application requester, the application server, and the network connecting them. These requirements fall into one or more of the categories that follow:
On AS/400 systems, end users are assigned a 1- to 10-character user ID that is unique to that system, but not necessarily unique within the network. This user ID is the one passed to the remote system when the connection is being established between two databases. To avoid conflicts between user IDs on systems in the network, outbound name translation is often used to change the user ID to resolve the conflict before it is sent over the network. However, the AS/400 system does not provide any outbound name translation to resolve potential conflicts at the server. These conflicts must be resolved at the application server, unless you use the additional USER and USING clauses on the AS/400 SQL CONNECT statement. USER is a valid ID on the application server, and USING is the corresponding password for the user.
After the application requester selects the end user names to represent the remote application, it must provide the required LU 6.2 network security information. LU 6.2 provides three major network security features:
Session-level security is provided through LU-to-LU verification. Each LU has a key that must match the key at the remote LU. You specify the key on the LOCPWD keyword on the CRTDEVAPPC command.
Because the application server is responsible for managing the database resources, the application server dictates which network security features are required of the application requester. The AS/400 security administrator must verify the security requirements of each application server so they require no more than the AS/400 application requester supports.
The following are possible SNA conversation security options:
The AS/400 system does not have an external security subsystem. All security is handled through the OS/400 operating system as discussed in the following section, System Security.
The OS/400 operating system controls authorization to all objects on the system, including programs, packages, tables, views, and collections.
The application requester controls authorization to objects that reside on the application requester. The security for objects on the application server is controlled at the application server, on the basis of which user ID is sent from the application requester. The user ID sent to the application server is associated with the user of the AS/400 application requester or the user ID given in the USER clause of the AS/400 SQL CONNECT statement. For example, CONNECT TO rdbname USER userid USING password.
Security of objects can be managed using the object authority CL commands or with the SQL statements GRANT and REVOKE. The object CL authority commands include Grant Object Authority (GRTOBJAUT) and Revoke Object Authority (RVKOBJAUT). These commands work on any object on the system. The statements GRANT and REVOKE only work on SQL objects: tables, views, and packages. If you need to change authorization for other objects such as programs or collections, use the GRTOBJAUT and RVKOBJAUT commands.
Granting and Revoking Authority:
Enter the following command on an AS/400 system to grant *USE authority to user USER1 to program PGMA:
GRTOBJAUT OBJ(PGMA) OBJTYPE(*PGM) USER(USER1) AUT(*USE)
The command to revoke the same authority:
RVKOBJAUT OBJ(PGMA) OBJTYPE(*PGM) USER(USER1) AUT(*USE)
*PGM identifies the object type in this example as a program. *SQLPKG is used to operate on a package, *LIB is used for a collection, and *FILE is used for a table.
GRTOBJAUT and RVKOBJAUT can also be used to prevent users from creating programs and packages. When authority is revoked from any of the CRTSQLxxx commands (where xxx = RPG, C, CBL, FTN, or PLI) used to create programs, a user is not able to create programs. If authority is revoked to the CRTSQLPKG command, the user is not able to create packages from the application requester or on the application server.
For example, enter the following command on an AS/400 system to grant *USE authority to user USER1 to the CRTSQLPKG command:
GRTOBJAUT OBJ(CRTSQLPKG) OBJTYPE(*CMD) USER(USER1) AUT(*USE)
This affects the execution of crtsqlpkg on the application requester. On the application server, this command allows the creation of packages.
The command to revoke the same authority is:
RVKOBJAUT OBJ(CRTSQLPKG) OBJTYPE(*CMD) USER(USER1) AUT(*USE)
Applying Default Authorization:
When objects are created, they are given a default authorization. By default, the creator of a table, view, or program is given all authority on those objects. Also by default, the public is given the same authority on those objects as they (the public) have on the objects' library or collection.
For more information on system security see AS/400 Security - Reference.
Products supporting DRDA automatically perform any necessary conversions at the receiving system. For this to happen the application requester CCSID value must be a supported value for conversion by the receiving system.
On an application requester, you should be concerned with the CCSID associated with:
OS/400 work management support initializes the job CCSID to the CCSID specified on the user profile. If the user profile CCSID value is *SYSVAL, work management support gets the CCSID from the QCCSID system value. The system value QCCSID is initially set to CCSID 65535. The use of 65535 for the CCSID of jobs servicing connect attempts from DB2 Universal Database will cause the connection attempts to fail. Changing the system value QCCSID affects the whole system, so the recommended action is to change the CCSID of the user profile for the job under which the server job runs. Set the CCSID of the user profile for the job to an appropriate value. For example, use CCSID 37 for US English. In general, the the appropriate choice would be to use the default coded character set identifier for the AS/400 you are connecting to.
The job CCSID can be changed by using the Change Job (CHGJOB) command. Or for subsequent jobs use the Change User Profile (CHGUSRPRF) command to change the CCSID value of the user profile. To see what CCSID is in effect for a job, in a CL program, use the Retrieve Job Attributes (RTVJOBA) command to get the current job CCSID. Interactively, use the Work with Job (WRKJOB) command and select option 2, Display Job Definition Attributes on the Work with Job display.
Database physical files default to the default job CCSID (which may be different from the job CCSID) at file creation if a CCSID is not explicitly specified on the Create Physical File (CRTPF) or Create Source Physical File (CRTSRCPF) command. Prior to DB2 for AS/400 V3R1, the default was the job CCSID which was often 65535 and inappropriate for DRDA usage. The default job CCSID is never 65535, and it is therefore a better choice for the CCSID of physical files accessed via DRDA.
You can use the Display File Description (DSPFD) command to view the CCSID of a file or the Display File Field Description (DSPFFD) command to view the CCSID of the fields of a file.
Use the Change Physical File (CHGPF) command to change the CCSID of a physical file. A physical file cannot always be changed if one or more of the following conditions exist: