The descriptions throughout this manual assume there is only one DB2 Server for VM production minidisk, which is owned by the SQLMACH machine and supports all activity on a VM system. This minidisk contains the SQLFDEF files that identify the databases; the SQLDBN files that identify the database machines and the databases they access; the bootstrap modules that identify where DB2 Server for VM code is to be loaded; and all the code that the database manager needs to run daily. Because it describes the environment, it changes as your environment changes. For example, it is updated if you generate a database, if you add a dbextent to a database, and at times during database machine startup.
In an environment that contains many database machines doing many administrative tasks, having only one production minidisk can lead to contention problems: only one machine at a time can write to the production minidisk, so other machines may have to wait for it to become available. In addition, in environments that contain extremely sensitive data, having only one production minidisk can be a security exposure: every DB2 Server for VM user would have read access to that production minidisk, and could easily determine what databases exist by scanning the files on it.
Thus, while a single production minidisk is suitable for many installations, it does not suit others. For these situations, you can define and use multiple production minidisks.
One primary database machine already exists in your installation: the SQLMACH machine, which you defined during installation. It owns the original (primary) production minidisk. To define an additional primary database machine, you define and initialize a secondary production minidisk, which is a copy of the original. The new primary database machine owns this new production minidisk through the MDISK statement for this disk in its VM directory entries.
Using your local operating procedures, update the VM directory entries for the new primary database machine. Figure 84 shows an example of these statements. The name of the database machine here is dbmach2. For a complete description of VM directory control statements, see the VM/ESA: CP Command and Utility Reference manual.
Figure 84. Example VM/ESA Directory Control Statements for the Database Machine
If you need to perform tape and DASD file load and unload operations for the DBS utility or trace facility, privilege class B is recommended. Privilege class B is needed to attach tapes.
For the virtual machine name and password shown here, replace dbmach2 and dbmachpw with your own machine name and password.
Set this value to be the sum of the following:
For more information see Setting the MAXCONN Value.
If you plan to use the DB2 Server for VM accounting facility with this database machine, you should also specify the ACCT operand. See Chapter 11, Using the Accounting Facility.
For more information, see VM Directory Control Statements.
In this example, the application server with the resource identifier resid is specified as a LOCAL resource.
| Note: | If remote access is being used, it is recommended you ensure that server names are unique within a set of interconnected SNA networks, and that resids are unique in a TSAF collection or a gateway. (A gateway is also referred to as an LU.) The resid must also be identified with a GLOBAL scope. For more information, see Distributed Processing Administration. |
All database machines (primary or secondary) should use the same service minidisk, to ensure that they have the same level of service.
All secondary database machines should share the same minidisk with its primary database mahcine.
This secondary production minidisk must be online and available for all DB2 Server for VM operations. When updates to it are required, the product-supplied database generation and maintenance EXECs relink it with access mode M or W.
Specify a multiple-access password (multipw) for this secondary production minidisk if:
If multiple database machines share a production minidisk, and the database machine that owns the minidisk does not have a multiple-access password (multipw) specified in its VM directory MDISK control statement, only the machine that does the database maintenance can access the production disk with write-access. If database maintenance must be done, the other machines cannot be performing normal processing using read-access to the production minidisk.
If this is a new virtual machine, you will receive messages after CMS is loaded, because you do not yet have a PROFILE EXEC or A-disk for the virtual machine. Ignore them and continue.
FORMAT 191 A
Respond to the prompts issued during CMS FORMAT command processing. For a complete description of this command and an explanation of the required prompt responses, see the VM/ESA: CMS Command Reference manual.
LINK dbmach2 195 195 Wwhere dbmach2 is your database machine ID.
FORMAT 195 Q
Respond to the prompts issued during CMS FORMAT command processing.
Figure 85. PROFILE EXEC Entries for an Additional Primary Database Machine
PROFILE
ACCESS 193 V
ARISPDFC
For more information on the functions ARISPDFC performs, refer to Appendix G, Service and Maintenance Execs.
+---------------------------VMSES/E Consideration----------------------------+
VMSES/E consideration: ARISPDFC copies over the lastest serviced ARISQLLD LOADLIB to the secondary production minidisk. If for some reason you need to create a different version of the ARISQLLD LOADLIB, you must create a PPF (Product Parameter File) override to the DB2 Server for VM $PPF file (5697F421 $PPF). Refer to the VM/ESA: VMSES/E Introduction and Reference for information on creating PPF overrides. In your new PPF override, you must:
+------------------------End of VMSES/E Consideration------------------------+
LINK dbmach2 195 195 RR ACCESS 195 Qwhere dbmach2 is your database machine ID.
| Note: | Do not log off yet. |
The process of defining an additional primary database machine also generates a database. In this example, the specifications for the starter database are used. If you want to generate a different database, review Chapter 2, Planning for Database Generation.
To generate a starter database, enter:
SQLDBINS DBNAME(name) STARTER(YES) RESID(resid)
where name is the name of the database to be generated.
| Note: | If DBNAME is not the same as RESID, you must specify the resid option. |
ARI6010D Do you want to install English DB2 Server for VM HELP text?
Enter 0(No), 1(Yes), or 111(Quit).
If you need information on how to respond to this prompt, see Running the SQLDBINS EXEC.
After the database is generated, you can log off the new primary database machine.
For information on installing HELP text in additional languages, see National Language Support for Messages and HELP Text.
This section describes how to define an additional database machine. Because a database machine usually owns one or more databases, this section also shows how to generate a database for the new machine.
Before proceeding, you must know the read and write (or multiple access) passwords for the DB2 Server for VM production minidisk.
Using your local operating procedures, update the VM directory entries for the new database machine. Figure 86 shows an example. The name of the database machine is dbmach1. These statements are the same as those for a primary database machine: for an explanation of them, see Step 1: Update the VM Directory. For a complete description of these statements, see the VM/ESA: CP Command and Utility Reference manual.
Figure 86. VM Directory Control Statements for a Secondary Database Machine
Use the CMS saved segment name (for example CMS, CMSL) and device types applicable to your VM operating system.
If this is a new virtual machine, you will receive messages after CMS is loaded because you do not yet have a PROFILE EXEC or A-disk for the virtual machine. Ignore them and continue.
FORMAT 191 A
Respond to the prompts issued during CMS FORMAT command processing. For a complete description of CMS commands and an explanation of the required prompt responses, see the VM/ESA: CMS Command Reference manual.
Note that the entries are provided in file SQLMACH PROFILE located on the production disk.
PROFILE
| Note: | Do not log off yet. |
Figure 87. PROFILE EXEC Entries for an Additional Database Machine
To generate a database, you must first establish access to the service minidisk. Enter the following command:
ACCESS 193 V
In this example, you will generate a database using the starter database specifications. Before proceeding, review the minidisk requirements shown in DB2 Server for VM Program Directory. If you choose to generate your own database, review Chapter 2, Planning for Database Generation.
To generate a starter database enter:
SQLDBINS DBNAME(name) STARTER(YES) RESID(name)
where name is the name of the database to be generated.
| Note: | If DBNAME is not the same as RESID, you must specify the resid option. |
The following prompt appears:
ARI6010D Do you want to install English SQL/DS HELP text?
Enter 0(No), 1(Yes), or 111(Quit).
If you need information on how to respond to this prompt, see Running the SQLDBINS EXEC.
After the database is generated, you can log off the new database machine.
For information on installing HELP text in additional languages, see National Language Support for Messages and HELP Text.
Use VMSES/E to install the database manager code on that processor, but do not run the database installation utilities. See Chapter 1, Planning for Installation and the DB2 Server for VM Program Directory.
To define additional user machines you can either update existing virtual machines or define new ones. In either situation, you must update the VM directory. The new user machine may also require a CMS communications directory. For more information, see Setting Up the CMS Communications Directory.
You can update the VM directory using your installation's current operating procedures. For a complete description of VM directory control statements, see the VM/ESA: CP Command and Utility Reference manual for your IBM VM system.
Figure 88 shows an example of the VM directory entries for a user machine.
Figure 88. VM Directory Entries for a User Machine
Use the CMS saved segment name (for example, CMS, CMSL) and device types applicable to your VM environment.
Privilege class B is optional. It is only required by a user machine that needs to attach real devices, such as tape drives.
Alternatively, user machines can communicate with databases without the need of the IUCV resid statement if both the following are true:
For more information on the VM directory control statements that affect inter-machine communications, see VM Directory Control Statements.
Initialize the user machine.
If this is a new virtual machine, you will receive messages after CMS is loaded, because you do not yet have a PROFILE EXEC or A-disk for the virtual machine. Ignore them and continue.
FORMAT 191 A
Respond to the prompts issued during CMS FORMAT command processing. For a complete description of the FORMAT command and an explanation of the required prompt responses, see the VM/ESA: CMS Command Reference manual.
Note that the entries are provided in the file SQLUSER PROFILE located on the production disk.
Figure 89. PROFILE EXEC Entries for a User Machine
With the user machine defined this way, users can issue the SQLINIT EXEC to communicate with a database machine, and set up a default database for the user. If you have users who typically access the same database all the time, who do not use the database manager frequently, or who are inexperienced in data processing, you may want to issue the SQLINIT EXEC while doing the above steps to set up their machines for accessing the appropriate database.
You can add an additional database to any of the database machines that you have defined. Before doing so, review Chapter 2, Planning for Database Generation.
Database generation consists of a series of steps that define and format minidisks, initialize the database, preprocess the DBS utility package, and run the DBS utility to complete the basic generation process. After the database is defined, other DB2 Server for VM facilities are installed in it. Most of these subtasks are done by issuing a single IBM-supplied EXEC called SQLDBINS, which calls other IBM-supplied EXECs.
These steps are discussed in detail below.
The first step is to add MDISK control statements to the VM directory of a database machine to give that machine ownership of the database you are about to generate.
Initially, the only database machine on a VM system is SQLMACH, but you can define additional machines as described in Adding a Primary Database Machine. Each database machine can have more than one database (although it can only access one at a time), and can access databases that it does not own. For convenience, the owner should be the machine that will be the primary user or controller.
The specific MDISKs required depend on the requirements for your database. However, you must define VM minidisks for:
Figure 90 shows an example of the MDISK control statements needed to define minidisks for a database that has two logs and two dbextents. For detailed information on the MDISK control statement, see the VM/ESA: CP Command and Utility Reference manual.
Figure 90. Defining VM Minidisks for a Database
Notes:
The database manager does not place any restrictions on the virtual device addresses you can use for its minidisks, unless you are using the starter database specifications, in which case the minidisks will occupy virtual device addresses 200, 201, and 202.
When adding MDISK control statements for a database machine, you should also review the current setting for MAXCONN, which is a parameter of the VM OPTION control statement. The MAXCONN determines the number of APPC/VM connections allowed for a virtual machine, and is unique to each database machine. Set it to be the sum of:
Each user machine that communicates with the database machine requires an APPC/VM or IUCV connection.
The database manager uses DASD block I/O, which in turn uses IUCV, to access its database minidisks. Set the MAXCONN value to allow for the maximum number of minidisks that are attached to the database machine.
Because the database manager records the highest dbextent number for the database, you may have to count deleted dbextents when calculating the MAXCONN value. For example:
For example, suppose there are 50 virtual machines (users) allocated for the installation, including the database machine SQLMACH. Of the 49 user machines, 25 are communicating with SQLMACH. In addition, assume that SQLMACH owns three databases: one with 10 minidisks, one with 3 minidisks, and one with 15 minidisks. For the SQLMACH machine, MAXCONN should be set to 40, that is, 25 (for maximum number of connected machines) + 15 (for the largest number of database minidisks). Note that this second number is not the sum of the minidisks in all three databases, because the database machine can only run one database at a time. If SQLMACH were to access the database having 3 minidisks, 37 user machines could connect. This (in most cases) is better than setting MAXCONN to 28 (to accommodate the small database and 25 users), because then if the largest database is accessed, only 13 user machines would be able to connect.
Naturally, you may have to adjust MAXCONN as real conditions (number of minidisks and number of users) change.
The MAXCONN parameter also applies to single user mode; however, here it is only concerned with the number of minidisks because no other user machines are communicating with the database machine.
To generate a database:
This third step is described in detail below.
The SQLDBINS EXEC resides on the service minidisk, where it is placed during the installation process. Figure 91 shows its format.
For resid, specify a VM resource identifier for the database that is unique on the production minidisk being accessed.
The SQLDBINS EXEC installs a database complete with DBS utility support, ISQL support, and English HELP text. If you do not use these facilities, you should leave the support in the database anyway.
If, for any reason, SQLDBINS ends before its processing is complete (for example, system failure or user interrupt), rerun it.
The SQLDBINS EXEC does much of its work by calling other IBM-supplied EXECs, most of which run without your intervention. One of these is the SQLDBGEN EXEC, which does the actual database generation. Thus, before issuing SQLDBINS, you must prepare the proper input for SQLDBGEN as follows. (If you are using the starter database specifications, you do not have to prepare any input.)
The SQLDBGEN EXEC resides on the service minidisk, where it is placed during the installation process. Figure 92 shows its format.
When the SQLDBGEN EXEC is called by the SQLDBINS EXEC, some of these parameters are omitted, while others take on the value that is specified on SQLDBINS. You only need to complete all of them if you are calling the SQLDBGEN EXEC directly, which you might do if you are moving databases from a VSE to a VM system, or doing problem diagnosis. For more information on moving a database from a VSE system to a VM system, see Migrating from a VSE to a VM Operating System.
When SQLDBINS calls SQLDBGEN, the DBNAME specified on SQLDBINS is passed to SQLDBGEN.
The SQLDBINS EXEC operates on the assumption that no saved segment has yet been defined; thus, when calling SQLDBGEN, it omits the DCSSID parameter.
The AMODE, if any, specified on SQLDBINS, is passed to SQLDBGEN.
If you specify POOL(NOLOG), SQLDBGEN prompts you for the numbers of any nonrecoverable storage pools you want to create. If you omit the POOL parameter or specify POOL(LOG), you will not receive any prompts.
The SQLDBINS EXEC always omits this parameter when calling SQLDBGEN.
For RESID, specify a VM resource identifier for the database. This identifier must be unique on the production minidisk being accessed.
The RESID, if any, specified on SQLDBINS, is passed to SQLDBGEN.
| Note: | The SQLDBGEN EXEC automatically specifies SYSMODE=S, STARTUP=C, and DUALLOG (Y or N, as appropriate) when it calls SQLSTART, so do not specify those parameters for PARM. Also, do not specify the PROGNAME initialization parameter as it is not valid when STARTUP=C. |
The SQLDBGEN EXEC does three major tasks:
These three operations are discussed below.
For each minidisk in the database, SQLDBGEN issues a CMS FORMAT and a CMS RESERVE command. It prompts you for the virtual device address (cuu) of each minidisk, which you should have recorded when you specified the MDISK statements in Step 1: Defining the Database Minidisks. Because the FORMAT and RESERVE commands will erase the current contents of the minidisk, you will be asked to confirm that you really want to have them run: respond YES.
Attention: Be sure you are accessing the correct minidisk before you do so.
The directory is formatted with a block size of 512 bytes. All other minidisks are formatted with a block size of 4096 bytes.
| Note: | When using CHANGE TO PERFF, the directory could be formatted with a block size of 4096 bytes. |
The RESERVE command creates CMS-like database files on the minidisks. These files are not the same as regular CMS files.
| Note: | Never use CMS file manipulation commands (such as COPY or RENAME) against the database files, as these commands may render the database useless. Instead, use DB2 Server for VM facilities. For a list of commands that you should not use, see CMS Restrictions. |
Each database must have one (and only one) SQLFDEF CMS file. The SQLDBGEN EXEC creates this file and places entries in it after it issues FORMAT and RESERVE for each minidisk. All SQLFDEF files reside on the production minidisk (Q-disk).
| Note: | The SQLDBGEN EXEC accesses the production minidisk in write access mode M, which allows a database machine to get write access to the production minidisk while someone else has read access. If another database machine already has write access, both SQLDBGEN and SQLDBINS end, and you must restart SQLDBINS when no other machine has write access. |
The CMS file name of the SQLFDEF file is taken from the DBNAME parameter you specified when you ran SQLDBINS. For example, if you specified SQLDBINS DB(DBNAME01), a file called DBNAME01 SQLFDEF is created on the production minidisk. You can determine whether a database exists by issuing the CMS STATE command for the SQLFDEF file. For example, to determine whether there is a database called PROD34, issue:
STATE PROD34 SQLFDEF Q
Before creating the SQLFDEF file and before formatting the database minidisks, SQLDBGEN issues a STATE command similar to the one above to determine whether the database specified in the DBNAME parameter (of SQLDBINS) already exists. If it does, SQLDBGEN gives you the choice of either using the existing file or replacing it. If you choose to use it, you are given a choice of whether to have SQLDBGEN issue FORMAT and RESERVE commands for the minidisks.
The SQLFDEF file contains CP LINK and CMS FILEDEF commands for the database minidisks. When the SQLSTART EXEC is called to start the database manager, it uses the SQLFDEF file as the vehicle by which it accesses the database. Specifically, it copies the SQLFDEF file from the production minidisk to the database machine's A-disk, and changes the file name and file type to ARISFDEF EXEC (any existing CMS file with this name); then calls ARISFDEF EXEC to access the minidisks of a particular database.
The minidisk read and write passwords do not appear in the LINK commands in SQLFDEF: the only place they appear is in the VM directory entry for the database machine that owns the database. This prevents users who do not know the passwords from accessing the database minidisks. For more information on using the SQLFDEF file to maintain security, and for information on how to protect the minidisks, see Chapter 6, Maintaining Database Security.
The FILEDEF commands in SQLFDEF associate the virtual device addresses of the database minidisks with the ddnames used by the DB2 Server for VM program. The database manager uses the following stylized ddnames for its directory, log, and dbextent minidisks:
Because the FILEDEFs for the program are generated for you, these ddnames are not usually a concern. Many people refer to the minidisks by their ddnames, so it is good to keep the ddnames in mind. The ddnames can also appear in messages to identify a minidisk.
After FORMAT and RESERVE are issued for the minidisks and SQLFDEF is created, the VM mechanisms for using the database minidisks are in place. Next, the database components must be formatted and the catalog tables created. The SQLDBGEN EXEC does these tasks by doing a coldstart: that is, starting the database manager in single user mode with STARTUP=C. To do this, it calls another IBM-supplied EXEC: SQLSTART. As part of its processing, the SQLSTART EXEC either creates or updates a CMS file named resid SQLDBN. The resid is the name that identifies the database to the VM system.
The SQLDBN file is created on the production minidisk. It contains four pieces of information:
The SQLDBN file is used to establish communications between users and database machines. Its uses are discussed in Chapter 4, Planning for Operation of the Database Manager; at this point, all you need to know is that it exists, and that you should not erase it after database generation. Like the SQLFDEF file, this file exists on the production minidisk for the life of the database.
Of more concern at this point is the coldstart processing, which requires you to provide input about the remaining database parameters in the form of database generation control statements. To help you provide this input, the SQLDBGEN EXEC first searches for a file named resid SQLDBGEN on the production disk. If this file exists, it means that a database with the resource identifier resid has already been generated, so you are prompted to either use this file or replace it. If you choose to use it, SQLDBGEN copies the file to the database machine's A-disk by issuing a CMS COPYFILE command similar to this one:
COPYFILE resid SQLDBGEN Q resid SQLDBGEN A (REP
Any existing file with the name resid SQLDBGEN will be replaced.
If you choose not to use this file, or if it cannot be found, SQLDBGEN copies a file named ARISDBG MACRO from the service minidisk to the database machine's A-disk, by issuing a CMS COPYFILE command similar to this one:
COPYFILE ARISDBG MACRO V resid SQLDBGEN A (REP
Any existing resid SQLDBGEN file on your A-disk will be replaced.
The ARISDBG MACRO contains the control statements that are used in generating the starter database. Usually the file that is copied is ARISDBG MACRO, not the production minidisk resid SQLDBGEN file. (That is, usually you generate a new database rather than replace an existing one.)
Figure 93 shows the ARISDBG MACRO.
Figure 93. Database Generation Control statements for a Starter Database
 |
If you specify POOL(NOLOG) when using SQLDBGEN, you are prompted for the numbers of storage pools that you want to be nonrecoverable.
Remember that the SQLDBINS EXEC calls the SQLDBGEN EXEC without the POOL parameter. Hence, during a normal database generation, you will not be prompted for information on nonrecoverable storage pools. If you want to define such storage pools during database generation, enter the POOL keyword control statements when you are given the opportunity to edit the resid SQLDBGEN file.
The SQLDBGEN EXEC generates additional database generation control statements based on the numbers you provide. The control statement generated is the POOL keyword control statement. (The POOL keyword control statement, along with all the other database generation keyword control statements, is described later in this section.)
After the SQLDBGEN EXEC has generated the POOL keyword control statements (if any), it asks if you want to modify the file. (It does this regardless of what you have specified for its POOL parameter.) If you answer yes, SQLDBGEN starts XEDIT.
You should modify the CMS file as appropriate and FILE it. (Note that the comments on the right of the keyword control statements are not in the actual file.) The SQLDBGEN EXEC then copies the resid SQLDBGEN file to the production minidisk (this provides a record of the control statements used to generate a given database), and then does a coldstart of the database manager. The database manager uses the completed file to format the database components and to create the catalog tables. The SQLDBGEN EXEC then ends.
Figure 94 shows how you might modify the CMS file for a database. The control statements shown work with the minidisk definitions in Figure 90. Table 2 summarizes all database generation parameters.
Figure 94. Example Database Generation Control Statements
The three control statements are divided into sets of input records, called keyword control statements, and are separated by END delimiter control statements. If you specify more than one keyword control statement on a single input record, separate the statements by a blank. The END delimiter control statement cannot be combined with the other keyword control statements. The keyword control statements must be coded in columns 1-72.
The details of specifying these database generation control statements are described below.
These keyword control statements define the number of dbextents to be initialized during the database generation process (CUREXTNT), and establish certain maximum values for the database (MAXPOOLS, MAXEXTNT, and MAXDBSPC).
The format for specifying these values is :
>>-CUREXTNT=nnn---+--------------+---+--------------+----------->
'-MAXPOOLS=nnn-' '-MAXEXTNT=nnn-'
>-----+--------------+--END------------------------------------><
'-MAXDBSPC=nnn-'
|
Each keyword control statement can be specified on its own input record or multiple statements can be specified on one input record.
These keyword control statements identify the initial set of nonrecoverable storage pools and define the initial set of dbextents. The format for specifying these values is :
.--------------------------------------.
V |
>>----+--------------------------------+--+--------------------->
| .-LOG---. |
'-POOL-pool_number----+-------+--'
'-NOLOG-'
.----------------------------------.
V |
>--------extent_number-+-------------+---+--END----------------><
'-pool_number-'
|
The first number in the pair is the extent number. You must define the dbextents in consecutive (numeric) order by extent number. Note that the extent numbers are decimal (unlike virtual device addresses, which are hexadecimal). The consecutive numbering is needed because the database manager requires the use of stylized ddnames in the CMS FILEDEF commands used to access the database. The SQLDBGEN EXEC creates these stylized ddnames in SQLFDEF for you. Both the SQLDBGEN EXEC and the database manager operate on the assumption that you are numbering the dbextents in consecutive (numeric) order. The stylized ddname format is DDSKn, where n is the extent number used in the dbextent keyword control statement.
The second number, which must be separated from the first by at least one blank, is the storage pool number. This is also a decimal value (as opposed to hexadecimal). If you do not specify the storage pool number, it defaults to 1.
| Note: | You cannot assign a dbspace to a storage pool until a dbextent has been assigned there. |
Each extent number/storage pool number pair must be entered on a separate input record. You can put comments on the dbextent keyword control statements by specifying the storage pool number and separating the comment from the number by at least one blank. A comment must be contained in the one input record for the dbextent: it cannot be continued on the next input record, which is interpreted as the next dbextent definition.
In the example in Figure 94, dbextent number 1 is assigned to storage pool number 1, and dbextent number 2 is assigned to storage pool number 2. The SQLDBGEN EXEC generates CMS FILEDEF commands in SQLFDEF of the following form:
FILEDEF DDSK1 DISK 32A... FILEDEF DDSK2 DISK 32B...
These keyword control statements define the initial set of dbspaces, including public dbspaces that the database manager requires (system dbspaces), any user public and private dbspaces you need initially, and the internal dbspace allocations for the database.
The format for specifying these values is :
.-1-------------------.
>>-+-PUBLIC-------+--number_of_pages----+---------------------+-><
'-+---------+--' '-storage_pool_number-'
'-PRIVATE-'
|
The number of pages value is the number of logical pages in the dbspace, rounded up to the next higher multiple of 128. The storage_pool_number must correspond to a pool that already has a dbextent, as defined by the dbextent keyword control statements.
You must define six public dbspaces for system use: the catalog, package, HELP text, ISQL tables, temporary install use, and the sample data tables dbspaces. In the example in Figure 94 all are assigned to storage pool 1, but you can assign them elsewhere. The catalog and package dbspaces must always be assigned to a recoverable storage pool. In the example in Figure 94, the first five dbspace keyword control statements specify:
The remainder of the public and private dbspaces shown in Figure 94 are user dbspaces of various sizes and storage pool assignments. After database generation finishes, the temporary installation dbspace is available as a user public dbspace. Thus, at the end of any database generation, there is at least one public dbspace of 1 024 pages available.
You must also define a number of internal dbspaces, for internal sorting and index creation. The general format for specifying the initial internal dbspace keyword control statement is:
>>-INTERNAL--number_of_dbspaces--number_of_pages---------------->
.-1-------------------.
>-----+---------------------+----------------------------------><
'-storage_pool_number-'
|
This statement specifies the number (number_of_dbspaces) of equal size (number_of_pages) temporary dbspaces that you want. The storage_pool_number must correspond to a pool that already has a dbextent, as defined by the dbextent keyword control statements. The storage pool to which you assign the internal dbspaces can be either recoverable or nonrecoverable: if you do not specify the storage pool number, it defaults to 1. You must not delete all dbextents from this storage pool.
This internal dbspace keyword control statement must be the last dbspace definition input record before the END delimiter control statement. Separate the values in this statement by at least one blank.
In the example in Figure 94, 80 internal dbspaces of 1 024 pages each are defined and assigned to storage pool 1.
| Note: | Because the catalog and package dbspaces are assigned to storage pool 1, performance is improved if internal dbspaces are assigned to some other recoverable storage pool. To keep the example simple, however, the internal dbspaces are assigned to storage pool 1. |
You can change the specification of internal dbspaces on any ADD DBSPACE operation. For more information, see Adding Dbspaces to the Database.
Generally speaking, your input records for initial dbspace definitions would follow the pattern shown in Figure 95.
Figure 95. Input Records for Initial Dbspace Definition
The first two dbspaces are public dbspaces (SYSTEM.SYS0001 and SYSTEM.SYS0002) that are both defined and acquired by the generation process for the catalog tables. You are advised to change either of these keyword control statements only if you want to define and allocate a larger dbspace for the catalog tables or for packages, respectively. You do this by increasing the number of pages specified in the control statement.
There must also be keyword control statements for the three dbspaces that are acquired by the MACRO ARISDBU during SQLDBINS EXEC. These dbspaces are needed for the HELPTEXT, ISQL, and sample dbspaces; the default sizes are 8192, 1024, and 512 pages respectively.
| Note: | The sample tables are loaded into the dbspace PUBLIC.SAMPLE by the
IBM-supplied DBS control file ARISAMDB MACRO V, which uses the user ID
SQLDBA.
Other IBM-supplied EXECs call sample application programs, which manipulate the data in the sample tables. One sample program (and an EXEC to run it) is provided for each programming language that is supported by the database manager. Details of these programs are given in the DB2 Server for VSE & VM Application Programming manual. |
If any of the above six database generation control statements are omitted, database generation may fail.
You can put comments on the dbspace keyword control statements if you specify the storage pool number and separate the comment from the storage pool number by at least one blank.
The SQLDBINS EXEC issues the following prompt:
ARI6010D Do you want to install English DB2 Server for VM HELP text?
Enter 0(No), 1(Yes), or 111(Quit)
For information on installing HELP text in additional languages, see National Language Support for Messages and HELP Text.
The application server default CHARNAME value on a newly installed database manager is INTERNATIONAL (CCSID=500); on a migrated database manager, the default is ENGLISH (CCSID=37). To change the application server default CHARNAME (and with it the application server default CCSID, classification tables, and translation tables), specify the new CHARNAME as an SQLSTART EXEC parameter. For more information, see Character Set Considerations at Startup.
For information on creating a new CHARNAME, CCSID, and character set, see National Language Support for Messages and HELP Text.
If you use mixed data (data that contains both DBCS and SBCS characters), you may want to change the application server default character subtype to mixed. The application server default character subtype is the value used for new columns when the character subtype is not explicitly defined by the CREATE TABLE or ALTER TABLE statements, or supplied as a package option. The character subtype value is also used to determine whether the results of the CHAR, DIGITS, and HEX scalar functions and the character representation of date, time, or timestamp values, or special registers should be interpreted either as mixed data or as SBCS data.
The application server default character subtype is initially set to SBCS. To change it, subtype, see Setting the Application Server Default Character Subtype.
If you are using a double-byte character set (DBCS), you should enable the DBCS option, which allows the database manager to correctly interpret SQL statements that contain DBCS strings. As a default, the DBCS option is not enabled. For information see Using Double-Byte Character Set (DBCS).
One final task you should perform is to change the password of user ID SQLDBA in your new database. User ID SQLDBA is defined in all databases to have DBA authority. The password for this user ID is set to SQLDBAPW during database generation. Because this default password is common knowledge (it is in many product manuals), you should change it immediately after database generation. To do so, use ISQL, an application program, or the DBS utility to connect to the database as SQLDBA:
CONNECT SQLDBA IDENTIFIED BY SQLDBAPW
Then change the password to one of your own choosing:
GRANT CONNECT TO SQLDBA IDENTIFIED BY newpw
Figure 96 summarizes the database generation process. It shows the major EXECs that are called, and key files that are created on the production minidisk.
Figure 96. Summary of Database Generation Process
When you generate a database, be aware that:
If you have VSE/ESA running as a guest under your VM operating system, VSE applications and users can access DB2 Server for VM databases through VSE guest sharing. The database accessed must be on the same VM system as the one that supports the VSE guest, or on another VM system in the same TSAF collection or SNA network. VM users and applications are not affected by VSE guest sharing.
The VSE guest sharing machine communicates with the database manager running under a VM/ESA operating system by using VSE APPCVM protocol, which is translated into the APPC/VM communication protocol. The following features are available to the VSE guest:
While VSE guest users are accessing an application server on VM, a batch application can also access an application server on VSE in single user mode. To do this, do not issue the SET APPCVM command for the batch application when you IPL VSE. Online users can access the database on VM by identifying it with the DBNAME parameter of the CIRB transaction. The batch application automatically accesses the application server on VSE.
The application server is identified to the VSE subsystem by an entry in the DBNAME directory and by the SET APPCVM command, which is issued when you IPL VSE. Batch/ICCF users access the application server identified by this command. Online users can access another application server by specifying it with the DBNAME parameter of the CIRB transaction. For more information on the SET APPCVM command and the CIRB transaction, see Operating VSE Guest Sharing and Chapter 5, Operating the Online Support for VSE Guest Sharing.
The user ID supplied by the CIRB transaction identifies CICS to the database machine. The user ID is the CICS APPLID, and defaults to DBDCCICS, unless you supply a different APPLID in the DFHSIT macro. For more information on CICS, see Implicit CONNECT Support.
Users who know the password for the CIRB transaction can have DBA authority in databases accessed by CIRB. The DB2 Server for VM user ID for CICS is set up by CIRB. Anyone accessing a database under that user ID has DBA authority.
The authority of users who know the CIRB transaction password can be limited using VM directory control statements. For more information on directory control statements, see VM Directory Control Statements.
VSE guests who access the database manager on the VM/ESA operating system are subject to the following restrictions:
The following figures show examples of VSE guest sharing configurations.
Figure 97 shows an example where both the VSE guests and the application server they access are on the same processor.
Figure 97. VSE Guest Sharing on One Processor
 |
Figure 98 shows an example where the VSE guest and the application server it accesses are on different processors. Communication is handled by TSAF.
Figure 98. VSE Guest Sharing with TSAF
 |
Figure 99 shows an example where the VSE guest and the database it accesses are on different processors. Communication is handled by the VTAM product and AVS over an SNA network.
Figure 99. VSE Guest Sharing with VTAM Product and AVS
 |