DB2 Server for VSE: System Administration

Database Generation Process

The steps for generating a database are as follows:

1. Update the DBNAME Directory for the new database.
2. Define the VSAM data sets for the database, by running the VSAM IDCAMS program with the appropriate set of DEFINE commands.
3. Set up the job control statements for generating the database.
4. Modify and run a job control to generate a database. The job control does the following:
   • Formats the database components and constructs the catalog tables
   • Installs the DBS utility
   • Runs the DBS utility to complete the installation of the database.

     This involves tasks such as creating views, granting access to DB2 Server for VSE facilities, and acquiring dbspaces for system use.

   Once the database is generated, you can do the following:

5. Install the desired components into the database, such as ISQL, online support, and HELP text.
6. Optionally change the application server default CHARNAME.
7. Optionally change the application server default character subtype.
8. Optionally set the DBCS option to YES.
9. Change the password of authorization ID SQLDBA in the database to one of your own choosing.
10. Optionally install the DRDA code.
11. Optionally load phases into the SVA.

These steps are all described in detail below.

Step 1: Update the DBNAME Directory

Update your DBNAME directory to add the new database. See Setting Up the DBNAME Directory.

Step 2: Defining the Database Data Sets

To define the VSAM data sets for the new database, run the VSAM utility program IDCAMS. The specific DEFINEs will depend on your requirements. At a minimum, however, you must define data sets for:

• A directory (sometimes called a BDISK)
• One or two logs
• At least one dbextent (at least one data set).

The ARIS71CD procedure shown in Figure 87 provides an example of the job control statements to define a VSAM user catalog and data sets for a database. This database has one directory, one log, and one dbextent. In the example, they will reside on an IBM 3380 DASD device.

Note:

The VSAM keywords shown here are only the basic ones that the database manager requires. Other keywords and options that you can use are described in the Using VSE/VSAM Commands and Macros manual.

Figure 87. Job ARIS71CD (Defining VSAM Data Sets for the Database)

// JOB ARIS71CD DB2 for VSE STARTER DATABASE VSAM DEFINITIONS // LIBDEF PROC,SEARCH=(PRD2.DB2710) // EXEC PROC=ARIS71DB *-- SQL/DS DATABASE ID PROC // EXEC IDCAMS,SIZE=AUTO DEFINE UCAT /* DEFINE USER CATALOG */ - ( NAME (SQLCAT) - CYL (1) - ORIGIN (NNNN) - VOL (XXXXXX) ) DEFINE SPACE /* DEFINE DB2 DATABASE SPACE */ - ( ORIGIN (NNNN) - CYL (119) - VOL (XXXXXX) ) - CAT (SQLCAT) DEFINE CLUSTER /* DEFINE DB2 DATABASE DIRECTORY */ - ( NAME (SQL.BDISK.STARTER.DB) - CNVSZ (512) - CYL (34) - NONINDEXED - VOL (XXXXXX) - RECSZ (505 505) - REUSE - SHR (2) ) - CAT (SQLCAT) DEFINE CLUSTER /* DEFINE DB2 DATABASE LOG */ - ( NAME (SQL.LOGDSK1.STARTER.DB) - CNVSZ (4096) - CYL (08) - NONINDEXED - VOL (XXXXXX) - RECSZ (4089 4089) - REUSE - SHR (2) ) - CAT (SQLCAT) DEFINE CLUSTER /* DEFINE DB2 DATABASE DATA EXTENT 1 */ - ( NAME (SQL.DDSK1.STARTER.DB) - CNVSZ (4096) - CYL (77) - NONINDEXED - VOL (XXXXXX) - RECSZ (4089 4089) - REUSE - SHR (2) ) - CAT (SQLCAT) /* /&

Notes:

1

Change the NAME keyword to the name of the application server you want to access.

2

Change all occurrences of VOLUME (XXXXXX) and ORIGIN (NNNN) to reflect the volume serial number and origin allocation for the VSAM components that make up your new database. (The origin value is the beginning track number or block number.)

3

If you are allocating the database to a 3380 DASD device, you do not need to modify the CYL space allocations. If a fixed-block architecture (FBA) 3370/9332/9335 DASD device is being used for the database, replace the CYL allocations with the equivalent BLOCK allocations. For all other types of DASD devices, refer to Appendix B, Estimating Database Storage. Minimum space allocation values are shown in Table 41.

4

If the user catalog for the database will not be identified by the file-id SQLCAT, then:

• Alter the file_id in the DLBL statement identifying the VSAM user catalog for the database, and
• Alter the CAT specification in the IDCAMS DEFINE SPACE and DEFINE CLUSTER commands.

We recommend that you use a VSAM user catalog for the new database. If you choose not to, you must do the following:

• Remove the DLBL statement identifying the VSAM user catalog
• Remove the DEFINE UCAT command and the DEFINE SPACE command
• Remove the CAT specification from the IDCAMS DEFINE CLUSTER commands.

You may also wish to password-protect your database with the VSAM password protection facility. See Protecting VSAM Data Sets.

The directory for the database is defined as part of a VSAM services job that creates the initial set of database data sets. Figure 88 shows another example of defining a directory data set. Figure 87 shows the complete job.

Figure 88. Defining the Directory Data Set

DEFINE CLUSTER (NAME (SQL.BDISK.DBNAME01.DB) - CNVSZ (512) - CYL (6) - NONINDEXED - VOL (volid1) - RECSZ (505 505) - REUSE - SHR (2) ) - CAT (SQLCAT01)

Notes:

1. The directory data set is defined by the DEFINE CLUSTER command. You can give it any name you like. To avoid confusion, however, you should retain BDISK as part of the name; then give it a qualifier to distinguish it from directories on other databases.

2. You must use the CNVSZ and RECSZ values shown. The directory must have 512-byte control intervals.

3. Set the directory size based on potential database size. Specify it with either CYL(nn) or TRK(nn) for count-key-data devices, or with BLOCKS(nnnn) for fixed block devices.

4. The SHR(2) parameter must be used to allow archiving.

5. You may wish to password-protect your database with the VSAM password protection facility. See Protecting VSAM Data Sets.

Step 3: Setting Up Your Database Job Control

Each time the database manager (program ARISQLDS) is run, the following job controls are needed:

• DLBL statements, which identify the database being accessed (the directory, the log or logs, and the data dbextents)
• LIBDEF statements, which define the DB2 Server for VM libraries and any other needed libraries
• Trace facility statements
• Database archive and log archive statements
• Accounting facility statements.

During the initial installation of the database manager, two procedures are defined that contain the needed LIBDEF statements:

ARIS71PL

runs LIBDEF statements to define the production libraries, which are required for the day-to-day use of the database manager.

ARIS71SL

runs LIBDEF statements to define libraries that are required for database generation and for code link edits.

It is recommended that you also use catalogued procedures for the other job controls, to avoid having to maintain multiple copies of them. Because procedures for the libraries are cataloged during installation, you only need to catalog the DLBL statements that identify the new database. You also should catalog the job control statements needed for the trace, database archive, log archive, and accounting facilities.

Database archiving and log archiving can be directed only to tape, so for these activities, you must use TLBL statements. Trace output and accounting output can be directed to either DASD or tape. For information on specifying job control statements for the trace output file, see the DB2 Server for VSE & VM Operation manual; for information on accounting job control statements, see Setting Up a Job Control for the Accounting Files.

Figure 89 shows an example of the job control statements needed for cataloging the database.

Figure 89. Job for Cataloging Database Job Control

// JOB CATALOG DATABASE JOB CONTROL // EXEC LIBR ACCESS SUBLIB=PRD2.DB2710 CATALOG DBNAME01.PROC // DLBL IJSYSUC,'SQLCAT01',,VSAM // DLBL BDISK,'SQL.BDISK.DBNAME01.DB',,VSAM // DLBL LOGDSK1,'SQL.LOGDSK1.DBNAME01.DB',,VSAM // DLBL LOGDSK2,'SQL.LOGDSK2.DBNAME01.DB',,VSAM // DLBL DDSK1,'SQL.DDSK1.DBNAME01.DB',,VSAM // DLBL DDSK2,'SQL.DDSK2.DBNAME01.DB',,VSAM // TLBL ARITRAC,... // TLBL ARIARCH,... // TLBL ARILARC,... // DLBL ARIACC1,... // EXTENT... // DLBL ARIACC2,... // EXTENT... /+ /* /&

Notes:

1. Specify the sublibrary into which your procedure is to be cataloged. In the above example, PRD2.DB2710 is used.

2. The file names on the DLBL and TLBL statements must be as shown in the example.

3. The data set names on the DLBL and TLBL statements must match those on the DEFINE CLUSTER commands that defined the data sets for the database.

4. You need a DLBL statement for the directory (BDISK).

5. You need a DLBL statement for each log data set (LOGDISK1, LOGDISK2).

6. You need one DLBL statement for each defined dbextent data set (DDSK1, DDSK2).

7. If you plan to use tracing, you need job control for the trace output file. The file name must be ARITRAC. This example shows a TLBL statement; trace output can be directed to disk as well.

8. If you will be running with LOGMODE=A or L, you need a TLBL statement for archiving the database. The file name must be ARIARCH.

9. If you will be running with LOGMODE=L, you also need a TLBL statement for archiving the log. The file name must be ARILARC.

   It is recommended that you do not specify any VOLID parameter on the TLBL statements for log archiving. Because multiple files can be created or read during the same run of the database manager, you would want different VOLIDs for the different files.

10. If you are including job control statements for the accounting file facility, the file name of the first accounting file must be ARIACC1, and that of the second file, if you choose to have it, must be ARIACC2. Only one file is required, but it is recommended that you use two.

Step 4: Generating the Database

To generate a database, modify and run the job control shown in Figure 90 in single user mode (SYSMODE=S). This will run IBM-supplied procedures to do the following:

1. Create the package for the DBS utility using the Assembler preprocessor
2. Finish the database generation process using the DBS utility.

Figure 90. Example of a Job Control for Generating Your Own Database

// JOB GENERATE A DATABASE NAMED DBNAME01 // EXEC PROC=ARIS71SL *-- SERVICE/PRODUCTION LIBRARY ID PROC // EXEC PROC=DBNAME01 *-- DATABASE ID PROC // EXEC ARISQLDS,SIZE=AUTO,PARM='SYSMODE=S,STARTUP=C' CUREXTNT=2 MAXEXTNT=200 The meanings of these MAXDBSPC=1000 parameters are described END in the paragraphs that POOL 2 NOLOG follow this figure. 1 1 2 2 END PUBLIC 12800 1 PUBLIC 2048 1 PUBLIC 8192 1 PUBLIC 1024 1 PUBLIC 512 1 PUBLIC 512 1 PUBLIC 512 1 PUBLIC 512 2 PUBLIC 512 2 PRIVATE 128 1 PRIVATE 128 1 PRIVATE 512 1 PRIVATE 128 2 PRIVATE 128 2 PRIVATE 512 2 INTERNAL 80 1024 1 END /* // EXEC PROC=ARIS040D *-- PREP DBS UTILITY // EXEC PROC=ARIS050D *-- PERFORM REQUIRED DATABASE SET UP // EXEC PROC=ARISDBSD *-- LOAD SAMPLE TABLES AND ROUTINES READ MEMBER ARISAMDB READ MEMBER ARISAMPI /* /&

Notes:

1. The ARIS71SL procedure is cataloged during initial installation. It contains job control statements that identify the appropriate set of service libraries.

2. The DBNAME01 cataloged procedure refers to the job control (DLBL and LIBDEF) statements for the database being generated. You define and create this procedure as explained in Step 3: Setting Up Your Database Job Control.

3. Running the database manager (PGM=ARISQLDS) in single user mode (SYSMODE=S) with STARTUP=C calls the database generation program. This program reads the SYSIPT input control cards that specify how the database is to be generated. These statements are described later. Program ARISQLDS also reads the A-type source member ARISCAT. The contents of this member remain constant for all databases and should not be changed.

4. The ARIS040D procedure should be used without modification. It preprocesses the DBS utility, and references DB2 Server for VSE source members.

5. Procedure ARIS050D uses the DBS utility to process the SQL statements that finish generating the database. Do not change this procedure or the A-type source member it reads (ARISDBU), because you may want to use them to install and generate additional databases in the future. If you want to allocate larger dbspaces for the HELP text, ISQL-stored queries, or sample tables than those defined in ARISDBU, copy and rename both ARIS050D and ARISDBU; then increase the number of pages in the ACQUIRE PUBLIC DBSPACE statements in the renamed member, and update the renamed procedure to use the renamed member as input.

   The member ARISDBU enables you to perform the following:

   • Grant RUN authority to PUBLIC for the DBS utility package SQLDBA.ARIDSQL
   • Acquire the standard database public dbspaces for HELPTEXT, ISQL, and SAMPLE
   • Create the HELP text tables SQLDBA.SYSTEXT1, SQLDBA.SYSTEXT2, and SQLDBA.SYSLANGUAGE
   • Create indexes SQLDBA.SYSTEXT1INDEX, SQLDBA.SYSTEXT2INDEX, and SQLDBA.SYSLANGINDEX on the HELP text tables
   • Create the ISQL sample routine table EXAMPLE.ROUTINE and its index EXAMPLE.RINDEX
   • Create the SYSUSERLIST catalog view and grant access to PUBLIC
   • Grant access to PUBLIC on all catalog tables except SYSTEM.SYSUSERAUTH.

   Note:

   You should not drop the dbspaces or tables that are acquired and created above, even if you are not installing the corresponding facilities. Certain database maintenance operations assume that these tables and dbspaces exist in the database.

6. The procedure ARISDBSD runs the DBS utility in single user mode.

7. The A-type source members ARISAMDB and ARISAMPI contain SQL statements to be run by the DBS utility to build and load the sample tables and routines.

The input (SYSIPT) control statements for the database generation program are divided into three sets of input records, separated by END delimiter control statements. These specify:

• Database generation keyword control statements, which define the number of dbextents to be prepared during the database generation process (CUREXTNT), and establish certain maximum values for the database (MAXPOOLS, MAXEXTNT, and MAXDBSPC). Each statement can be specified on its own input record (card), or multiple statements can be specified on one input record. An END delimiter control statement must be specified after all the keyword control statements. The CUREXTNT control statement must be specified; all the others have default values.
• Initial storage pool and dbextent definitions, which identify the initial set of nonrecoverable storage pools and define the initial set of dbextents. Any dbextent defined here must have a corresponding DLBL statement in your database job control (DBNAME01). You must specify at least one dbextent for each storage pool that is referenced by the initial dbspace definitions. The POOL control statements that define nonrecoverable storage pools must precede the statements that define the dbextents.
• Initial dbspace definitions, which define the initial set of dbspaces, including public dbspaces required by the database manager (system dbspaces), any user public and private dbspaces you need initially, and the internal dbspace allocations for the database. You must specify at least five public dbspaces: first two for the database catalog and package storage, and three more for the HELP text, ISQL tables, and the sample tables. In Figure 90 the first five dbspace keyword control statements define these five dbspaces. The remainder of the public and private dbspaces shown in Figure 90 are user dbspaces of various sizes and storage pool assignments.

  You must also specify the internal dbspaces for the database. You can change the specification of internal dbspaces on any ADD DBSPACE operation. For information, see Adding Dbspaces to the Database.

The details of specifying these database generation control statements are described below.

Specifying Keyword Control Statements

The format for specifying the database generation keyword control statements is:

>>-CUREXTNT=nnn---+--------------+---+--------------+-----------> '-MAXPOOLS=nnn-' '-MAXEXTNT=nnn-' >-----+--------------+--END------------------------------------>< '-MAXDBSPC=nnn-'

CUREXTNT

CUREXTNT specifies the number of dbextents being defined in the database generation. You must specify it; it has no default value. Its value can be from 1 to 999, and must match the number of dbextent definition control statements. You must also have DLBL statements for all the dbextents being defined (in your DBNAME01 procedure). In the example shown in Figure 90, CUREXTNT=2 indicates that two dbextents are being defined.

MAXPOOLS

MAXPOOLS specifies the maximum number of storage pools that can ever be defined for the database. Its value can range from 1 to 999. The default is 32. In the example in Figure 90, the default is used.

MAXEXTNT

MAXEXTNT specifies the maximum number of dbextents that can ever be defined for the database. Its value can range from 1 to 999. The default is 64. In the example in Figure 90, it is set to 200.

MAXDBSPC

MAXDBSPC specifies the maximum number of dbspaces that can ever be defined for the database. Its value can range from the number you specify in your database generation control statements to 32000. The default is 1000. In the example in Figure 90, it is explicitly set to 1000.

The keyword control statements must be coded in columns 1-71. Column 72 is a continuation column, and columns 73-80 are ignored. If you specify more than one keyword control statement on a single input record, separate them with blanks.

Specifying Initial Storage Pools and Dbextents

The control statement format for specifying the initial storage pools and dbextents is:

.-,------------------------------------. V | >>----+--------------------------------+--+---------------------> | .-LOG---. | '-POOL-pool_number----+-------+--' '-NOLOG-' .-.--------------------------------. V | >--------extent_number-+-------------+---+--END---------------->< '-pool_number-'

POOL

Include the POOL control statement only for those storage pools you want to define as nonrecoverable: if you omit it, the pool will be defined as recoverable. You can specify as many nonrecoverable storage pools as you want, up to the MAXPOOLS value. For more information, see Nonrecoverable Storage Pools.

pool_number

The value for pool_number is the number of the storage pool. You cannot specify 1 because storage pool 1 is the default storage pool for dbspaces, so it cannot be defined as nonrecoverable.

LOG

The LOG option, which indicates that the storage pool is to be recoverable, is the default. Specify the NOLOG option if the storage pool is to be nonrecoverable.

extent_number/pool_number

The dbextent definition control statements follow the POOL statements. They define an initial set of dbextents (by number), and the storage pool assignment for each.

The first number in the pair is the extent number, which corresponds to the suffix number in the file name of the dbextent data sets (DDSKn). You must use stylized file names on the DLBL statements describing the dbextents. The file name is DDSKn, where n is the extent number used in the dbextent definition record. You must define the dbextents in consecutive (numeric) order by extent number.

The second number, which must be separated from the first by at least one blank, is the storage pool number. 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 to it.

Each extent number/storage pool number pair must be entered on a separate input record. You can put comments on the dbextent 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 90, dbextent number 1 (DDSK1) is assigned to storage pool number 1, and dbextent number 2 (DDSK2) is assigned to storage pool number 2.

Specifying Initial Dbspaces

The format 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 value must correspond to a pool that already has a dbextent defined for it, as defined by the dbextent control statements.

You must define five public dbspaces for system use: the catalog dbspace, package, HELP text, ISQL tables, and sample tables dbspaces. In the example shown in Figure 90, 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 90, the first five dbspace control statements specify:

• 12800 pages for the catalog dbspace (SYS0001)
• 2048 pages for the package dbspace (SYS0002)
• 8192 pages for the HELPTEXT dbspace
• 1024 pages for the ISQL dbspace
• 512 pages for the SAMPLE dbspace.

The general format for specifying the initial internal dbspace 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 the database manager can use for internal sorting and index creation. The storage_pool_number must correspond to a pool that already has a dbextent in it, as defined by the dbextent control statements. You must not delete the last dbextent from the storage pool that contains the internal dbspaces. 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.

This internal dbspace keyword control statement must be the last dbspace definition input record before the END delimiter control statement. Separate the values you specify in this statement by at least one blank.

In the example in Figure 90, 80 internal dbspaces of 1024 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 you assign the internal dbspaces to some other recoverable storage pool. In this example, they are assigned to storage pool 1, just to keep things simple.

Generally speaking, your input records for initial dbspace definitions would follow this pattern:

Figure 91. Input Records for Initial Dbspace Definitions

The first two dbspaces are public dbspaces: PUBLIC.SYS0001 and PUBLIC.SYS0002, which are both defined and acquired by the generation process for the catalog tables and for the packages, respectively. You are advised to change these control statements only if you want to define and allocate a larger dbspace for the catalog tables or for the package dbspace, respectively. To do this, increase the number_of_pages value in the control statement.

The third, fourth, and fifth dbspaces are public dbspaces that are added by the generation process. They are later acquired when procedure ARIS050D calls the DBS utility to complete the generation of the database. As shown in Figure 90, procedure ARIS050D must be called whenever you generate a database.

Note:

The fifth dbspace, PUBLIC.SAMPLE, is also added by the generation process. It is used to hold the IBM-supplied sample data tables. These tables are created and loaded during the last run of the DBS utility, when the A-type members ARISAMDB and ARISAMPI are processed. Details of ARISAMDB and ARISAMPI are provided in the DB2 Server for VSE Program Directory manual. The data in the sample tables is manipulated by sample application programs, which are called by the IBM-supplied job control members. There is one sample program for each programming language that the database manager supports. Details of these programs are in the DB2 Server for VSE & VM Application Programming manual.

You must specify database generation control statements for all five of these dbspaces. If you omit one, the database generation may fail.

Code the dbspace values in columns 1-71. Columns 72-80 are ignored. You can put comments on the dbspace statements by specifying the storage pool number and separating the comment from this number by at least one blank.

Step 5: Installing the Database Components

After the database is generated, you can install these three components into it:

• HELP text
• Online support
• ISQL.

All of these components are optional; which ones you should install depends on your usage environment. For example, in a query/report writing environment, you should install all three.

Regardless of whether you use these components, you can still install all of them into the database for possible future use. Figure 92 shows job control statements that install all the optional components into the DBNAME01 database. Modify the job control and run it to install the components into your database. (The database manager must be running in single user mode.)

Figure 92. Job Control to Install Optional Database Components

// JOB TO INSTALL DATABASE COMPONENTS // EXEC PROC=ARIS71SL *--SERVICE/PRODUCTION LIBRARY ID PROC // EXEC PROC=DBNAME01 *--DATABASE ID PROC // EXEC PROC=ARIS380D,LANG=AME,HELP=ONLY,CUU=xxx // EXEC PROC=ARIS080D *--INSTALL ONLINE SUPPORT // EXEC PROC=ARIS110D *--INSTALL ISQL // EXEC PROC=ARIS120D *--INSTALL ISQL // EXEC PROC=ARIS130D *--INSTALL ISQL /&

Notes:

1. Procedure ARIS380D loads the English version of the DB2 Server for VSE HELP text into the database. About 40000 rows are inserted, and the job normally takes 10 to 15 minutes. The dbspace PUBLIC.HELPTEXT must exist for this procedure to be run. If you do not want the English version of the HELP text, you can omit the job control statement for this procedure.

   HELP text is loaded from the Help Text Tape, which must be mounted on the tape drive identified by the value assigned to the cuu parameter.

   HELP text is available in other languages as well. To load HELP text for a language other than American English, replace the value for the LANG parameter in the PROC ARIS380D with one of the following values.

   AMENG

   American English

   UCENG

   Uppercase English

   FRANC

   French

   GER

   German

   KANJI

   Kanji (Japanese)

   HANZI

   Simplified Chinese

   Refer to the installation instructions in the DB2 Server for VSE Program Directory manual.

2. Procedure ARIS080D installs the online support into the database, and grants CONNECT authority to ALLUSERS. This allows the online support to implicitly connect users. For information on implicit CONNECT, see the DB2 Server for VSE & VM Database Administration manual.

   If the online support is not required for your database, omit the job control statements for procedures ARIS080D, ARIS110D, ARIS120D, and ARIS130D.

3. Procedures ARIS110D, ARIS120D, and ARIS130D install ISQL support into the database. If you do not want to install the ISQL support, omit the job control statements for these procedures. You may also omit the job control statement for procedure ARIS060D.

After making the necessary job control modifications, submit the job for processing. All steps should end with a return code of 0 or 4. If any step fails to run, remove the EXEC PROC statements for all job steps that completed, and rerun the job. However, do not remove the database identification procedure or the library definition procedure (DBNAME01 and ARIS71SL). For example, if the step EXEC PROC=ARIS130D did not complete successfully, you can rerun the step by running the job control shown in Figure 93:

Figure 93. Job Restart for Installing Optional Components

// JOB RESTART // EXEC PROC=DBNAME01 *--YOUR DATABASE IDENTIFICATION PROCEDURE // EXEC PROC=ARIS71SL *--SERVICE/PRODUCTION LIBRARY ID // EXEC PROC=ARIS130D *--INSTALL ISQL /&

Step 6: Reload CCSID-Related Packages

The database manager and online resource manager use CCSID-related phases for validating and folding characters in SQL statements. The programs used to create these phases depend on packages residing in the database. The job control in Figure 94 can be used to load the package in the new database.

Figure 94. Job Reload for Loading CCSID-Related Phases Package

// JOB RELOAD CCSID-RELATED PHASES PACKAGE // EXEC PROC=ARIS71SL *--SERVICE/PRODUCTION LIBRARY ID // EXEC PROC=DBNAME01 *--YOUR DATABASE IDENTIFICATION PROCEDURE // EXEC PROC=ARIS175D *--RELOAD CCSID-RELATED PHASES PACKAGE /&

Step 7: Optionally Changing the Application Server Default CHARNAME

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 initialization parameter.

For information on creating a new CHARNAME, CCSID, and character set, see Chapter 12, Choosing a National Language and Defining Character Sets.

Step 8: Optionally Changing the Application Server Default Character Subtype

If you use mixed character data (which contains DBCS and SBCS characters), you may want to change the application server default character subtype (CHARSUB) 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.

For information on changing the default character subtype, see Setting the Application Server Default Character Subtype.

Step 9: Optionally Setting the DBCS Option to YES

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).

Step 10: Changing the Password of Authorization ID SQLDBA

One final task you should not omit is to change the password for the authorization ID SQLDBA in your new database. The authorization ID SQLDBA is defined in all databases to have DBA authority. The password is set to SQLDBAPW during database generation. Because this default password for SQLDBA 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 manager as SQLDBA with the following statement:

   CONNECT SQLDBA IDENTIFIED BY SQLDBAPW

Then change the password to one of your own choosing with the following statement:

   GRANT CONNECT TO SQLDBA IDENTIFIED BY newpw

Step 11: Optionally Install the DRDA Code

A DRDA environment provides the application server capability for remote unit of work access to data that is distributed across different installations. For more information on installing this code, see Chapter 14, Using a DRDA Environment.

Step 12: Optionally Load Phases into SVA

The VSE shared virtual area (SVA) allows the DB2 Server for VSE code to be shared. This sharing can reduce the amount of storage required by the database partitions, and reduces the amount of paging done by the system. You can load the eligible phases into the shared virtual area.

Table 16 shows the phases that are eligible to be loaded into the shared virtual area.

Table 16. Phases Eligible for SVA

Component	Phase
DBSS	ARISQLDS
RDS	ARIXRDS
DBSU	ARIDBS
Batch Resource Adapter	ARIRBARM
DBNAME Directory	ARICDIRD
Assembler Preprocessor	ARIPRPA
COBOL Preprocessor	ARIPRPC
FORTRAN Preprocessor	ARIPRPF
PL/I Preprocessor	ARIPRPP

Notes:

1. If you load all of the eligible phases, allocate an additional 4.1 megabytes of storage to the shared virtual area.

2. The DBSS component contains the code for the following components:
   • DBSS
   • DSC

3. The RDS component contains the code for the following components:
   • RDS
   • WUM
   • DRRM
   • CONV

   The DRRM and WUM components are only applicable if the DRDA code is installed.

4. If loaded, the DBSS and RDS components must both be loaded together in the SVA.

Phases can be loaded into the shared virtual area in the following ways:

1. During VSE system IPL, add the SET SDL command into the IPL PROC.
2. After IPL, a separate job control with the SET SDL command can be run anytime after IPL.

The SET SDL command must always be issued from the background partition. Once the phases have been loaded, they cannot be purged until the next VSE system IPL.

The following is a sample job control to load both the DBSS and RDS phase into the shared virtual area:

      // JOB LOADSVA
      // LIBDEF PHASE,SEARCH=(IJSYSRS.SYSLIB,PRD2.DB2710)
         SET SDL
         ARISQLDS,SVA
         ARIXRDS,SVA
      /*
      /&

For more information on the shared virtual area, see the IBM VSE/ESA System Control Statements manual.