The user might create additional relational databases on an iSeries™ server by configuring independent auxiliary storage pools (IASPs) on the server. Each independent auxiliary storage pool group is a relational database.
In this topic, independent auxiliary storage pool groups are called user databases. They consist of all the database objects that exist on the independent auxiliary storage pool group disks. Additionally, all database objects in the system relational database (called system database in this topic collection) of the iSeries server to which the independent auxiliary storage pool is varied on are logically included in a user relational database. However, from a commitment control perspective, the system database is treated differently.
There are a number of rules associated with the creation and use of user databases, besides those imposed by the commitment control considerations just mentioned. One example is that you cannot use an Advanced Program-to-Program Communication (APPC) protected distributed unit of work (DUW) conversation to connect to a database from an application requester (AR) which has been set to a user database (an auxiliary storage pool [ASP] group) for the current thread. Another example is that the name of any schema created in a user database must not already exist in that user database or in the associated system database. For more information about such restrictions, see the SQL reference topic.
There are certain DRDA-related objects that cannot be contained in user databases. DDM user exit programs must reside in libraries in the system database, as must any Application Requester Driver programs.
You should be aware that the process of varying on a user database causes the RDB directory to be unavailable for a period of time, which can cause attempts by a DRDA® application requester or application server (AS) to make use of the directory to be delayed or to timeout. The exposure to having directory operations timeout due to unavailability caused by varying on a database is much greater if multiple databases are varied on at the same time. As noted here, the first time a user database is varied on, an attempt is made by the server to add a directory entry for that database. If the directory is unavailable due to a concurrent vary on operation, the addition will fail, in which case the entry will have to be manually added.
Other considerations in the use of user databases concern configuration of entries in the RDB directory. One of the rules for naming user databases is that user RDB names cannot match the system name specified in the network attributes (as displayed by the Display Network Attributes (DSPNETA) command).
Local user database entries in the RDB directory are added automatically the first time that the associated databases are varied on. They are created using the *IP protocol type and with the remote location designated as LOOPBACK. LOOPBACK indicates that the database is on the same server as the directory. It is highly recommended that user databases that are intended to be switched among servers be configured to have a dedicated IP address associated with them. If the switchable database does not have a dedicated IP address, then whenever it is switched, manual updating of its directory entry on all the servers that reference that database must be done.