The application server support on the AS/400 system allows it to act as a server for DRDA application requesters. The application requester connected to a DB2 Universal Database for AS/400 application server can be any client that supports DRDA protocols.
The application requester is permitted to access tables stored locally at the DB2 Universal Database for AS/400 application server. The application requester must create a package at the DB2 Universal Database for AS/400 application server before any SQL statements can be run. The DB2 Universal Database for AS/400 application server uses the package containing the application's SQL statements at program run time.
To process distributed database requests on the AS/400 application server, you need to name the application server database in the RDB directory. For SNA Communications you need to define the application server system, and set the request and response unit sizes and pacing. For TCP/IP communications, supported from DB2 Universal Database for AS/400 Version 4.2, see Connecting DB2 Universal Database for AS/400 in a DRDA Network Using TCP/IP.
You name the application server database (at the application server location) in the same way that you identify the application requester database (at the application requester location). Use the Add Relational Database Directory Entry (ADDRDBDIRE) command, and specify *LOCAL as the remote location.
For access using SNA, defining the application server to the network is identical to defining the application requester to the network. You need to create line, controller, device, and mode descriptions to define both the application server and the application requester that sends the requests. For information on how to define the application server to the network, see Defining the Local System to DB2 Universal Database for AS/400 and Defining the Remote System to DB2 Universal Database for AS/400. See also AS/400 Distributed Database Programming.
The transaction program name used to start an AS/400 application server database is the DRDA default X'07F6C4C2'. This transaction program name is defined within the AS/400 system to start the application server. The corresponding parameter for TCP/IP connections, when that protocol is supported by DB2/400, is the port. DB2/400 will always use the DRDA well-known port of 446 as a server.
Network definitions must be reviewed to determine if the distributed database network impacts the existing network. These considerations are the same for the application server and the application requester.
When an application requester routes a distributed database request to the AS/400 application server, the following security considerations can be involved:
The application requester sends a user ID to the application server for security processing. The job running on the AS/400 application server uses this user ID, or in some instances, a default user ID.
The AS/400 application server does not provide inbound user ID translation to resolve conflicts among user IDs that are not unique or group multiple users under a single user ID. Each user ID sent from an Application Requester must exist on the application server. A method to group incoming requests into a single user ID, with loss of some security, is to specify a default user ID in a communications entry in the subsystem that is handling the remote job start requests. See the descriptions of ADDCMNE and CHGCMNE in the AS/400 CL Reference.
LU 6.2 provides three major network security features:
The DB2 Universal Database for AS/400 application server uses session-level security in exactly the same manner as the DB2 Universal Database for AS/400 application requester.
The application server controls the SNA conversation levels used for the conversation. The SECURELOC parameter on the APPC device description or the secure location value on the APPN remote location list determines what is accepted from the application requester for the conversation.
The possible SNA conversation security options are:
SNA/DS (SNA Distribution Services) requires a default user ID, so SNA/DS should have its own subsystem for the normal case where you don't want a default user id for DRDA applications.
A method for grouping incoming start job requests into a single user ID was mentioned in Selecting End User Names. This method does not verify the user ID sent from the Application Requester. The application server job is started under a default user ID, and the user who initiated the connection from the application server has access at the application server even if the user ID sent has restricted authorization. This is done by defining the application server as a nonsecure location, specifying a default user ID in the AS/400 subsystem communications entry, and configuring the application requester to send a user ID only during connection processing. If a password is sent, the user ID that accompanies it is used instead of the default user ID.
The AS/400 subsystem communications entries are distinguished by the device and mode name used to start the conversation. By assigning different default user IDs to different device/mode pairs, users can be grouped by how they are communicating with the application server.
The AS/400 system also offers a network security feature that is used only for distributed database and distributed file management. A network attribute for these types of system access exists that either rejects all attempts to access or allows the security to be controlled by the system on an object-by-object basis.
All security is handled through the OS/400 security function.
The AS/400 system does not have an external security subsystem. All security is handled by the OS/400 security function that is an integral part of the operating system. The operating system controls authorization to all objects on the system, including programs, packages, tables, views, and collections.
The application server controls authorizations to the objects that reside on the application server. The security control for those objects is based on which user ID starts the application server job. This user ID is determined as described in Selecting End User Names.
Security of objects can be managed through the use of the object authority CL commands or through the SQL statements GRANT and REVOKE. The object authority CL commands include Grant Object Authority (GRTOBJAUT) and Revoke Object Authority (RVKOBJAUT). Use these CL commands for any object on the system. Use the statements GRANT and REVOKE only for SQL objects: tables, views, and packages. If authorization needs to be changed to other objects, such as programs or collections, use the GRTOBJAUT and RVKOBJAUT commands.
When objects are created on the system, they are given a default authorization. The user ID that creates tables, views, and packages is given all authority. All other user IDs (the public) are given the same authority they have to the collection or library in which the object is created.
Authority to objects referenced by static or dynamic statements within the package are checked at package run time. If the creator of the package does not have authority to the referenced objects, warning messages are returned when the package is created. At execution time, the user executing the package adopts the authority of the creator of the package. If the creator of the package is authorized to a table, but the user running the package is not authorized, the user adopts the authority of the package creator and is allowed to use the table.
For more information on system security see AS/400 Security - Reference.
Products supporting DRDA automatically perform any necessary conversions at the application server. For this to happen the application server CCSID value must be a supported value for conversion by the application requester.
On an application server you should be concerned with the CCSID associated with:
The CCSID of your servicing job must be compatible with the application requester. This CCSID is established by the user profile of the user ID requesting the connection. OS/400 work management support initializes the job CCSID to the CCSID on the user profile. If a CCSID does not exist on the user profile, work management support gets the CCSID (QCCSID) from the system value. The system value QCCSID is initially set to CCSID 65535.
Before initiating a request to DB2 Universal Database for AS/400, you should sign on and use the Change User Profile (CHGUSRPRF) to assign an acceptable CCSID value to the user profile of the job that will service the DRDA requests.
An SQL collection consists of an OS/400 library object, a journal, a journal receiver, and optionally, an IDDU data dictionary if the WITH DATA DICTIONARY clause is specified on the CREATE COLLECTION statement. The physical and logical files used for some of these objects default to the job CCSID at the time of creation. If you query the data dictionary or the catalog from an application requester that does not support the CCSID value of these files, you might see non-displayable or distorted data. Or the application requester might issue a message saying the CCSID value is not supported. To correct this you need to create a new SQL collection with a job CCSID value that is acceptable to the other system.
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. 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.
An SQL table corresponds to an DB2 Universal Database for AS/400 physical file within a library of the same name as your collection. The columns of a table also correspond to the field definitions of a physical file. The CCSID values for the table or columns of the table might not be compatible with the application requester. To change this value refer to Represent Data, which describes changing database physical files. A major source of CCSID incompatibility in versions of OS/400 prior to Version 3 Release 1 was that many files or SQL tables were tagged with the CCSID 65535 by default. In Version 3 Release 1, and subsequent releases, the CCSIDs of these files are changed automatically to some other more appropriate value.