DB2 Server for VSE System Administration (Version 7 Release 5)

This entry identifies a DB2 Server for VM database server that executes on the VM

system under which this local VSE system is running as a guest. Any local

requester that connects to DBNAME ’VMDATABASE1’ will access the VM server

via the Guest Sharing facility.

TYPE=REMOTE

DBNAME=SQLMACJR

ALIAS=TOKYO

SYSID=VMC3

REMTPN=JRSERVER

TCPPORT=27

IPADDR=94.83.72.161

This entry identifies a remote DRDA-capable server with a DBNAME of

’SQLMACJR’ and an alias of ’TOKYO’. It can be accessed by CICS requesters via

SNA using a Remote Transaction Program Name (REMTPN) of ’JRSERVER’. It can

also be accessed by CICS and Batch requesters via TCP/IP using IP Address

’94.83.72.161’ and Port number ’27’. Note that Batch requesters cannot access

remote servers via SNA.

CICS CEDA DEF CONNECTIONS Command for a Remote

Entry

Figure 12 shows an example of the CICS CEDA DEF CONNECTIONS command

used to define the connection that matches the remote entry for

″DBNAME=SQLMACJR″ in the example above.

Connection

: VMC3

Group

: DRDA

CONNECTION IDENTIFIERS

Netname

: OECGW001

INDsys

REMOTE ATTRIBUTES

REMOTESystem

REMOTEName

CONNECTION PROPERTIES

ACcessmethod

: Vtam

Vtam | IRc | INdirect

Protocol

: Appc

Appc | Lu61

SInglesess

: No

No | Yes

Datastream

: User

User | 3270 | SCs | STrfield | Lms

RECordformat

: U

U | Vb

OPERATIONAL PROPERTIES

AUtoconnect

: Yes

No | Yes | All

INService

: Yes

Yes | No

SECURITY

SECURITYNAME

ATTACHSEC

Local | Identify | Verify

Bindpassword

PASSWORD NOT SPECIFIED

Figure 12. Define Remote Connection

Choosing the Application Server Default CHARNAME and CCSID

The application server default CHARNAME is set using the CHARNAME

initialization parameter. The database manager uses the CHARNAME value to

determine the classification table and translation table which are used to identify

valid characters and to determine how to fold lowercase characters to uppercase.

For more information on the CHARNAME initialization parameter, see

“CHARNAME” on page 51.

Chapter 2. Planning for Database Generation

The CHARNAME parameter also specifies the application server default coded

character set identifier (CCSID). For a newly installed database, the application

server default CHARNAME is INTERNATIONAL, and the application server

default CCSID is 500. For a migrated database, the application server default

CHARNAME is ENGLISH, and the application server default CCSID is 37. The

application server default CCSID is the value of CCSIDMIXED if it is not zero,

otherwise it is the value of CCSIDSBCS. Refer to “CCSID Conversion” on page 245

and “Determining CCSID Values” on page 248 for more information on CCSIDs.

If you use DBCS characters, you need to use a mixed CCSID as the application

server default. A mixed CCSID has both an SBCS component CCSID, and a DBCS

component CCSID. For more information, see Table 21 on page 247.

The application server default CCSID value is used for the following:

v The CCSID that SQL statements are converted to for processing by the relational

data system (RDS) component

v The CCSID of constants (including hexadecimal constants) which are part of the

SQL statement processed by the RDS component

Depending on the application server default subtype value (that is, the CHARSUB

value), the application server default value for CCSIDMIXED or CCSIDSBCS is

used for the following:

v The CCSID of special registers which represent character data (for example,

CURRENT USER and CURRENT DATE)

v The CCSID of the results of the scalar functions CHAR, DIGITS, and HEX

v The CCSID of the character representation of datetime values (for DRDA

protocol, this is always the CCSIDSBCS value)

v The CCSID of character columns created using the CREATE TABLE or ALTER

TABLE statements (when the CCSID or subtype clause is not explicitly specified

and when package defaults are not specified). See the DB2 Server for VSE & VM

Application Programming manual for more details on package defaults.

It is important that you choose the correct default CHARNAME and CCSID for

your installation. The goals of choosing the correct values are to ensure the

integrity of character data representation, and to reduce the performance overhead

associated with CCSID conversion. The application server and application

requester should have the same CCSID value unless there is a specific reason for

them to be different.

When the application server and application requester have different CCSID

values, character conversion cannot be avoided. This conversion has an associated

performance overhead. Performance degradation also occurs if the CCSID

conversion causes a sargable predicate to become residual. For example, this can

occur on a simple equals predicate like, T1.C1 = T2.C2. For this case, C2 was

created prior to migrating to Version 3 Release 4 and has a CCSID of 37. C1 was

created using Version 3 Release 4 with the application server default CHARNAME

set to INTERNATIONAL (CCSID 500), As a result, since this predicate requires the

CCSID conversion of the data in the columns, it is residual. For more information

on performance, see the DB2 Server for VSE & VM Performance Tuning Handbook.

For example, if your application server is only accessed by local users whose

terminal controllers are generated with code page 37 and character set 697 (CP/CS

37/697) for the US ENGLISH characters, then you should set the application server

System Administration

default CHARNAME to ENGLISH. This is because CP/CS 37/697 corresponds to

the CCSID of 37 which corresponds to the CHARNAME of ENGLISH.

To eliminate unnecessary CCSID conversion, choose an application server default

CCSID to be the same as the CCSID of the application requesters which access

your application server most often.

The following is an example of how these two goals can be in conflict.

The situation has these characteristics:

v An application server is accessed by 5 application requesters which are local

(that is, they have the protocol parameter set to SQLDS).

v This application server is also accessed by 100 application requesters which are

remote (that is, they are using the DRDA protocol).

v The local application requesters have controllers which are defined with CP/CS

37/697 (this corresponds to CCSID 37).

v The remote application requesters use CCSID 285.

If the application server default CHARNAME is set to ENGLISH (CCSID 37), this

keeps the data integrity for the local application requesters. However, CCSID

conversion overhead is incurred for all remote application requesters who have

CHARNAME UK-ENGLISH (CCSID 285).

If the application server default CHARNAME is set to UK-ENGLISH (CCSID 285),

this will avoid the CCSID conversion overhead incurred for the remote application

requesters, but will cause data integrity problems for the local application

requesters. Certain characters will not be displayed correctly for local application

requesters. For example, a British pound sign (£) will be displayed as a dollar sign

($).

These are the trade-offs to consider when choosing your application server default

CHARNAME.

For more information on CCSIDs, see the Character Data Representation Architecture

Reference and Registry manual.

Attention: Immediately following an installation, the application server

CHARNAME is set to INTERNATIONAL and the CCSID is 500. Immediately

following a migration, the application server CHARNAME is set to ENGLISH and

the CCSID is 37. If you do not choose your own application server defaults, these

settings may not be correct for your system.

For information on how to change the application server default CHARNAME and

CCSID, see “Setting the Application Server Default CHARNAME and CCSIDs” on

page 249. For a summary of the considerations for changing these values, see

“Considerations when changing default CHARNAME and CCSID” on page 232.

Choosing the Application Server Default Character Subtype

The database manager supports three types of character data:

v SBCS

v Mixed

v Bit.

Chapter 2. Planning for Database Generation

Note: Character refers to data types CHAR, VARCHAR and LONG VARCHAR in

this discussion.

Each database has a default character subtype (that is, the CHARSUB value) which

can be either SBCS (single-byte character set) or mixed (mixed single and

double-byte character set). The default character subtype is the value used for the

subtype attribute of any new character column that is created by either the

CREATE TABLE statement or the ALTER TABLE statement. The default subtype is

used if a subtype is not specified as a package default option or a preprocessing

option, and is not specified explicitly using a subtype clause, or implicitly using a

CCSID clause.

The CHARSUB value is also used for determining CCSIDs. For more information

on CCSIDs, see “Choosing the Application Server Default CHARNAME and

CCSID” on page 31, “CCSID Conversion” on page 245, and “Determining CCSID

Values” on page 248. For information on how to change the default character

subtype, see “Setting the Application Server Default Character Subtype” on page

253.

Choosing the Default CHARNAME and CCSID for Application

Requesters

It is important that the appropriate application requester default CHARNAME and

appropriate application requester default CCSID be chosen. The goals of choosing the

correct values are to ensure the integrity of character data representation, and to

reduce the performance overhead associated with CCSID conversion.

For example, if your terminal controller is generated with code page 37 and

character set 697 (CP/CS 37/697) for US ENGLISH characters, then the application

requester should set the default CHARNAME to ENGLISH. This is because CP/CS

37/697 corresponds to the CCSID of 37 which corresponds to the CHARNAME of

ENGLISH.

The application requester default CCSID is the value of CCSIDMIXED if it is not

zero; otherwise, it is the value of CCSIDSBCS. The application requester default

CCSID is used for the following:

v The CCSID of SQL statements coded at the application requester

v The CCSID of host variables which represent character data

v The CCSID of character values described by an input or output SQLDA (when

the SQLNAME field is not used to override the CCSID value)

v The CCSID of character data returned in a DESCRIBE SQLDA

v The CCSID of message tokens returned in an SQLCA

For more information on setting the default CHARNAME for an application

requester, see “Setting the Application Requester Default CHARNAME and

CCSIDs” on page 251. For more information on CCSIDs, see “CCSID Conversion”

on page 245 and “Determining CCSID Values” on page 248.

Preparing for Database Regeneration

If the SYS0001 dbspace ever becomes too small to hold the catalog tables, or if the

contents of the directory data set or a dbextent data set are damaged or destroyed

and you do not have archives to restore them, the database can no longer serve

your needs and must be regenerated.

System Administration

The size and complexity of the regeneration task depends on the size and

complexity of the database. This task includes:

v Regenerating the database, including any dbspaces, dbextents, and VM

minidisks that may have been added since the previous generation

v Using the DBS utility to unload and reload all the data in the database,

including the ISQL routines and the ISQL stored queries.

v Repreprocessing all application program packages

v Reestablishing the entire authority scheme

v Recreating all views and indexes.

One way to simplify this task is to keep a record of the various types of

information you would need to reestablish the operating environment that existed

in the previous database. In particular:

v Keep all the ACQUIRE DBSPACE, CREATE TABLE, ALTER TABLE, GRANT,

CREATE INDEX, CREATE VIEW, and CREATE SYNONYM statements for the

database in DBS utility job streams. These job streams can be run easily on the

regenerated database.

Note: If these statements are not kept, you can reconstruct them from

information available in the system catalog tables. However, this could

take a long time for a large production database.

v Keep all the VSAM Access Method Services statements used to define the VSAM

data sets for the database, both for initial generation and for later ADD

DBEXTENT operations. Also keep the statements used for any log

reconfigurations. These statements can be used in one job to redefine the VSAM

data sets.

v Keep all the input control statements for any ADD DBSPACE or ADD

DBEXTENT operations. These statements can be used as input to the job that

regenerates the database.

v Keep the database job control (DLBL, TLBL, and LIBDEF statements) up to date

in a cataloged procedure. This procedure can be used by the job that regenerates

the database.

v Keep the jobs used to preprocess each application program so that they can be

run on the regenerated database (as separate jobs).

Database Generation Worksheet

This section provides two worksheets. Figure 13 covers the items that you must

address in order to define the VSAM data sets for your database, and Table 4

covers the database generation control statements. Fill them out as you design

your database; then refer to them when you do the actual database generation.

Chapter 2. Planning for Database Generation

Need to define VSAM Master Catalog: NO: __

YES: __ CYL./BLOCKS: ____ VOLUME: _________

ORIGIN: ____

Need to define VSAM User Catalog:

NO: __

YES: __ CYL./BLOCKS: ____ VOLUME: _________

ORIGIN: ____

Need to password protect data sets: NO: __

YES: __ Level: ______ Password: ___________

(Only one VSAM Data Space Required)

Data Space 1: ORIGIN: ____

CYL./BLOCKS:

___ VOLUME: _________

Data Space 2: ORIGIN: ____

CYL./BLOCKS:

___ VOLUME: _________

Data Space 3: ORIGIN: ____

CYL./BLOCKS:

___ VOLUME: _________

Data Space n: ORIGIN: ____

CYL./BLOCKS:

___ VOLUME: _________

Directory:

NAME: _____________________ CYL./BLOCKS:

___ VOLUME: __________

(Only one Log Required)

LOGDSK1:

NAME: _____________________ CYL./BLOCKS: ___ VOLUME: __________

LOGDSK2:

NAME: _____________________ CYL./BLOCKS: ___ VOLUME: __________

ALTLGD1: NAME: _____________________ CYL./BLOCKS: ___

VOLUME: __________

ALTLGD2: NAME: _____________________ CYL./BLOCKS: ___

VOLUME: __________

(Only one Dbextent Required)

Dbextent 1:

NAME: _____________________ CYL./BLOCKS:

___ VOLUME: __________

Dbextent 2:

NAME: _____________________ CYL./BLOCKS:

___ VOLUME: __________

Dbextent 3:

NAME: _____________________ CYL./BLOCKS:

___ VOLUME: __________

Dbextent n:

NAME: _____________________ CYL./BLOCKS:

___ VOLUME: __________

Figure 13. Important Factors for Installing Your Own Database

Table 4. Database Generation Worksheet

Database Name

Server Name

______________________________

APPLID

______________________________

Database Capacity Parameters:

CUREXTNT _____________ (A value from 1 to 999 must be specified.)

MAXPOOLS _____________ (Default is 32. Value can be from 1 to 999.)

MAXEXTNT _____________ (Default is 64. Value can be from 1 to 999.)

MAXDBSPC _____________ (Default is 1 000. Value can be up to 32 000.)

System Administration

Table 4. Database Generation Worksheet (continued)

Nonrecoverable Storage Pools:

POOL ________ NOLOG

(Storage pool 1 cannot be specified.)

POOL ________ NOLOG

Database Extent (Dbextent) Placement:

Dbextent

Storage Pool

Number

(Default is 1)

--------

--------------

___

Note: The number of dbextents must equal CUREXTNT, but one is required. The MAXEXTNT value determines the

maximum number of database extents.

Public Dbspaces:

SIZE

Storage Pool

Purpose

(In 4K Pages)

(Default is 1)

---------------------------------

-------------

--------------

Catalog Tables

____

Packages

____

___

HELP Text

____

___

ISQL

1024

(minimum)

___

Sample Tables

512

(minimum)

___

_________________________________

____

___

_________________________________

____

___

_________________________________

____

___

_________________________________

____

___

_________________________________

____

___

Note: The public dbspaces for the catalog tables, packages, HELP text, ISQL, and the sample tables are required.

The catalog tables must be in storage pool 1.

Chapter 2. Planning for Database Generation

Table 4. Database Generation Worksheet (continued)

Private Dbspaces:

SIZE

Storage Pool

Purpose

(In 4K Pages)

(Default is 1)

---------------------------------

-------------

--------------

_________________________________

________

_________________________________

________

_________________________________

________

_________________________________

________

_________________________________

________

_________________________________

________

Internal Dbspaces:

Number: _____

Size in 4K Pages: ____

Storage Pool: ____

Note: The MAXDBSPC value determines the maximum total number of public, private, and internal dbspaces

possible.

System Administration

Chapter

3. Planning for Database Migration

If your installation already has a previous release of the database manager

installed, you must consider the effect that migration to the new release will have

on your existing databases and applications.

You can migrate to a DB2 Server for VSE Version 7 Release 5 database from:

v Version 7 Release 4

v Version 7 Release 3

v Version 7 Release 2

v Version 7 Release 1

v Version 6 Release 1

v Version 5 Release 1

v Version 3 Release 5

v Version 3 Release 4

v Version 3 Release 2

v Version 3 Release 1

Note: If you are on an earlier release, you will have to migrate to Version 3

Release 5 first and then to Version 7 Release 5.

This chapter also contains a section on:

v Release coexistence considerations

It can be impractical to migrate all the databases in a local or distributed

environment to the current level at the same time. For information on the level

of coexistence that is possible see “Release Coexistence Considerations” on page

46.

If you will be migrating databases on a VSE system to a VM system, see the

DB2 Server for VM System Administration manual.

Migration Considerations

For users of an earlier version of the database manager, installing Version 7

Release 5 means loading the new code by running one or more IBM supplied

programs, and migrating any existing databases. This section highlights the

considerations that you should be aware of when doing this.

The topics are grouped by the release level of the database that is being migrated.

Start at your release level and read to the end of this chapter. For example, if your

database is Version 3 Release 1, you must review all the topics; if it is Version 3

Release 2, you need only read from that topic to the end of the chapter.

Increasing the HELPTEXT Dbspace

A database that is migrated keeps its existing HELPTEXT dbspace, which may not

be large enough to support the Version 7 Release 5 HELP text. The size required

for this dbspace depends on the number of national languages for which you have

HELP text. It should be:

2,304 pages x number of languages installed.

This dbspace can be increased at any time before you install the current HELP text.

For information, see the DB2 Server for VSE & VM Database Administration manual.

Migrating from Version 3 Release 1

Considerations for Invalid Indexes

Before you migrate, at least four dbspace blocks must be available in the database

directory to allow for expansion of the invalid entities table. During migration, any

entries in the invalid entities table are migrated to the new format. The new table

format requires additional space in the directory. If there are any entries in the

invalid entities table, it is possible that there may not be enough room in the

directory to allow the table to be modified during migration.

For information about directory space verification, see the DB2 Server for VSE

Program Directory.

Conversion of Packages

After migration, all packages are dynamically repreprocessed on first use. This

conversion can cause a performance degradation over the first few days as the

packages are referenced and repreprocessed.

To help minimize this degradation, the REBIND PACKAGE command is provided

so that all packages can be recreated, if desired, after migration but before

production. For information about this command, see the DB2 Server for VSE &

VM Database Services Utility manual.

Migrating from Version 3 Release 2

Choosing a Server Name

With Version 3 Release 4 and later, you can specify a server name of up to 18

characters. See “Choosing an Application Server Name” on page 23.

Elimination of the SET XPCC Command

Before Version 3 Release 4 an application program could only access one database.

In Version 3 Release 4 and later, up to 36 application servers can be active at the

same time in your VSE system.

To make use of this new facility, you must remove the SET XPCC command and

use the SET APPCVM command. For details on this command, see Chapter 5,

“Operating the Online Support ,” on page 81.

However, if you continue to access only one database, the SET XPCC command

can still be used.

Choosing an Application Server Default CHARNAME

After migration, the database manager sets the application server default

CHARNAME to ENGLISH, and sets the application server CCSID values as

follows:

v CCSIDSBCS = 37

v CCSIDMIXED = 0

v CCSIDGRAPHIC = 0.

You can change the value of the default CHARNAME, which in turn determines

the values for the three application server default CCSIDs. These four values are

stored in the VALUE column of the SYSTEM.SYSOPTIONS catalog table. The

System Administration

corresponding values in the SQLOPTION column for these defaults are

CHARNAME, CCSIDSBCS, CCSIDMIXED, and CCSIDGRAPHIC.

The value you choose for the default CHARNAME should accurately reflect the

type of data that will be stored in the database: that is, the type of code page and

character set that describes the data, and whether or not the database manager is

to support DBCS characters or MBCS characters, or both. For more information,

see “Character Set Considerations at Startup” on page 51, “Determining CCSID

Values” on page 248, and “CCSID Conversion” on page 245. For a summary of the

considerations for changing these values, see “Considerations when changing

default CHARNAME and CCSID” on page 232.

Setting Migration CCSID Values

After choosing your default CHARNAME, you must also set your CCSID values

for character and graphic data that existed before the migration to Version 3

Release 4. The CCSID value of character and graphic data stored in tables that

were created before Version 3 Release 4 are specified by the three other rows (with

SQLOPTION value MCCSIDSBCS, MCCSIDMIXED and MCCSIDGRAPHIC) in the

SYSTEM.SYSOPTIONS catalog table. The migration CCSID values (MCCSIDSBCS,

MCCSIDMIXED, and MCCSIDGRAPHIC) are used for single byte, mixed, and

graphic data that was created prior to Version 3 Release 4 and therefore does not

have a CCSID associated with it. The database manager sets the migration CCSID

values as follows:

v MCCSIDSBCS = 37

v MCCSIDMIXED = 0

v MCCSIDGRAPHIC = 0.

If the code page and character set used to create the migrated data (that is, the

data that was inserted into the database prior to Version 3 Release 4) is not CP/CS

37/697, these settings are not correct for your installation and must be changed.

You can determine the CCSIDs for migrated data from the code page and character

set that was used to generate the terminal controller where the data was entered.

For an example of how your choice of migration CCSID value affects the

characters displayed, refer to page 250.

To determine if your database contains graphic or mixed data, issue the following

query:

SELECT COUNT(*) FROM SYSTEM.SYSCOLUMNS

WHERE COLTYPE = ’GRAPHIC’ OR

COLTYPE = ’VARGRAPH’ OR

COLTYPE = ’LONGVARG’ OR

SUBTYPE = ’M’

If the query returns a result of zero rows, the database contains neither graphic nor

mixed data; a nonzero result indicates the number of columns in your database

that do contain such data.

Handling SBCS Data: If your database contains only SBCS data (that is, the

above query returns a result of zero) prior to Version 3 Release 4, the migrated

CCSID values for mixed and graphic data (MCCSIDMIXED and

MCCSIDGRAPHIC) must remain 0.

If the MCCSIDSBCS value of 37 is not correct for your installation, this must be

changed to correspond to the code page and character set used to create the

migrated data. For example, if the data was created with CP/CS 273/697

Chapter 3. Planning for Database Migration

(GERMAN), the CCSID value you should use is 273. For a list of some of the SBCS

CCSIDs and their character set and code page values, see Table 21 on page 247.

The row that you must update for data in tables created before Version 3

Release 4 is:

v SQLOPTION='MCCSIDSBCS'

Change the value in the VALUE column to the appropriate SBCS CCSID (for

example, 273 for GERMAN). The following statements show how to update or

insert the row using this value:

UPDATE SYSTEM.SYSOPTIONS SET VALUE = ’273’

WHERE SQLOPTION = ’MCCSIDSBCS’

INSERT INTO SYSTEM.SYSOPTIONS VALUES

(’MCCSIDSBCS’, ’273’,

’DEFAULT CCSID FOR MIGRATED SBCS CHARACTER COLUMNS’)

Handling Mixed Data: If your database contains graphic or mixed data prior to

Version 3 Release 4, you must update the VALUE column of

SYSTEM.SYSOPTIONS for the row where SQLOPTION='MCCSIDMIXED' with the

appropriate nonzero CCSID value. You must also update the row where

SQLOPTION='MCCSIDSBCS' to the value of the SBCS component of the mixed

CCSID, and the row where SQLOPTION='MCCSIDGRAPHIC' to the value of the

DBCS component of the mixed CCSID. If these CCSIDs do not correspond to the

components of the mixed CCSID, the wrong conversion selection tables are being

used. For a list of some of the mixed CCSIDs and their component SBCS and

DBCS CCSIDs, see Table 21 on page 247.

The rows that you must update for data in tables created before Version 3

Release 4 are:

v SQLOPTION='MCCSIDMIXED'

Change the value in the VALUE column to the appropriate mixed CCSID. If you

used DBCS characters before Version 3 Release 4, specify the appropriate CCSID

value. For example, if you used Kanji characters, specify the value 5035. The

following statements show how to update or insert the row using this value:

UPDATE SYSTEM.SYSOPTIONS SET VALUE = ’5035’

WHERE SQLOPTION = ’MCCSIDMIXED’

INSERT INTO SYSTEM.SYSOPTIONS VALUES

(’MCCSIDMIXED’, ’5035’,

’DEFAULT CCSID FOR MIGRATED MIXED CHARACTER COLUMNS’)

v SQLOPTION='MCCSIDSBCS'

Change the value in the VALUE column to the appropriate SBCS CCSID. If you

used DBCS characters before Version 3 Release 4, you must specify the SBCS

component CCSID of the MCCSIDMIXED value. For example, if

MCCSIDMIXED is set to 5035, specify 1027. The following statements show how

System Administration

to update or insert the row using this value:

UPDATE SYSTEM.SYSOPTIONS SET VALUE = ’1027’

WHERE SQLOPTION = ’MCCSIDSBCS’

INSERT INTO SYSTEM.SYSOPTIONS VALUES

(’MCCSIDSBCS’, ’1027’,

’DEFAULT CCSID FOR MIGRATED SBCS CHARACTER COLUMNS’)

v SQLOPTION='MCCSIDGRAPHIC'

Change the value in the VALUE column to the appropriate graphic CCSID. If

you used DBCS characters before Version 3 Release 4, this value must be the

DBCS component CCSID of the MCCSIDMIXED value that you used. For

example, if you used Kanji characters, specify 4396. The following statements

show how to update or insert the row using this value:

UPDATE SYSTEM.SYSOPTIONS SET VALUE = ’4396’

WHERE SQLOPTION = ’MCCSIDGRAPHIC’

INSERT INTO SYSTEM.SYSOPTIONS VALUES

(’MCCSIDGRAPHIC’, ’4396’,

’DEFAULT CCSID FOR MIGRATED GRAPHIC COLUMNS’)

Considerations for Mixed Primary Keys with Field Procedures

If you are migrating from Version 3 Release 1 or Version 3 Release 2, the value of

CCSID in SYSTEM.SYSKEYCOLS is NULL. For some primary keys, this value is

not correct. In this case, you should drop and recreate the primary keys, which you

can identify by running the ARIS341D procedure after migrating. (For information

on this procedure, see the DB2 Server for VSE Program Directory manual.)

Considerations for EXPLAIN Tables

Several changes and enhancements were made to the EXPLAIN tables in Version 3

Release 4. If you have existing EXPLAIN tables they must either be renamed, or,

dropped and recreated before using the EXPLAIN statement.

An IBM-supplied macro, ARISEXP, recreates the EXPLAIN tables for you.

For additional information on using EXPLAIN tables, see the DB2 Server for VSE &

VM Performance Tuning Handbook manual.

Considerations for VSE Guest Sharing

VSE batch applications can access an application server on VM that is either

remote or local. If the application server is in a remote network, the SET XPCC

TARGET SYSARI command in the VSE IPL procedure must be replaced by the SET

APPCVM TARGET command. If the application server is local, the SET XPCC

TARGET SYSARI command in the VSE IPL procedure is not needed, and can be

deleted.

Chapter 3. Planning for Database Migration

Regardless of whether the application server is remote or local, an entry in the

DBNAME directory may also be necessary to map the DBNAME to the resid when

the DBNAME is greater than 8 characters, or when the DBNAME and the resid are

different. For more information on the DBNAME directory, see “Setting Up the

DBNAME Directory” on page 23.

Migrating from Version 3 Release 4

Considerations for Assembler Even Precision Packed Decimal

Prior to Version 3 Release 5, assembler host variables declared as even precision

packed decimal were converted to odd precision by the preprocessor. As of

Version 3 Release 5, the database manager supports assembler host variables

defined as even precision packed decimal, and they are not converted to odd

precision. In some cases, the lack of conversion may cause a datatype mismatch

between a host variable and a column. To prevent potential performance

degradation, applications affected by this change should be modified so the

datatypes of the host variables exactly match the datatypes of the columns to

which they will be compared.

Considerations for SQLSTATE Changes for SQL92 Support

The SQLSTATEs returned by several conditions were changed to comply with

SQL92. Application programs that have a dependency on the SQLSTATE returned

may be affected by these changes. See DB2 Server for VM Messages and Codes for

information on the changed SQLSTATEs.

Migrating from Version 3 Release 5

Considerations for Uncommitted Read

Prior to Version 5 Release 1, the database manager accepted isolation level

uncommitted read as a preprocessor parameter, but internally the isolation level

was escalated. As of Version 5 Release 1, isolation level uncommitted read is fully

supported. However, this isolation level to take effect, packages that were prepped

with uncommitted read in a previous release must be explicitly repreprocessed

after migration.

Considerations for Support of ESA-mode Processors Only

Any user exits (date, time, or accounting), field procedures, or applications that

run in single user mode that are dependent on running in a 370 mode virtual

machine must be converted to execute in an ESA mode virtual machine. AMODE

24 is still supported, so exits, field procedures, and single user mode applications

that require AMODE 24 are not affected.

Considerations for the Renaming of the Product

The text of several messages was modified as the result of the renaming of the

product. Applications with dependencies on the text of messages may be affected.

Considerations for the Removal of the User Facility Subset

The User Facility Subset is no longer supported; machines on which the subset was

previously installed must now contain the full product.

System Administration

Migrating from Version 5 Release 1

Choosing the Default CHARNAME for All Application

Requesters

After migration, the application requester default CHARNAME is determined from

the SQLGLOB file. By default it is set to INTERNATIONAL, and the application

requester CCSID values are as follows:

v CCSIDSBCS = 500

v CCSIDMIXED = 0

v CCSIDGRAPHIC = 0.

To ensure the integrity of character data representation and to reduce the

performance overhead associated with CCSID conversion, it is important to choose

the appropriate CHARNAME for the code page used by each application requester.

See “Choosing the Default CHARNAME and CCSID for Application Requesters”

on page 34 and “Setting the Application Requester Default CHARNAME and

CCSIDs” on page 251. For more general information on CCSIDs, see “CCSID

Conversion” on page 245 and “Determining CCSID Values” on page 248.

Considerations for VSE DRDA Online Requester Support

The format of the DBNAME directory source file member, ARISDIRD, has changed

and must be modified and a new phase created. See “Setting Up the DBNAME

Directory” on page 23.

Considerations for RDS Above 16M

After migration, the RDS component will be loaded above 16M whenever possible.

For information, see “V6R1 and V5R1 Incompatibilities” on page 421.

Migrating from Version 6 Release 1

Considerations for the DBNAME Directory

The format of the DBNAME directory has changed. As a result, you must modify

the DBNAME directory source file member (ARISDIRD), and create a new phase.

See “V7R1 and V6R1 Incompatibilities” on page 421 and “Setting Up the DBNAME

Directory” on page 23, for more information.

Considerations for Key Enablement

When running VSE/ESA 2.5 or later, DB2 Server for VSE is key-enabled. For

information on setting up the DB2 key, see the DB2 Server for VSE Program

Directory.

Migrating from Version 7 Release 1

There are no issues to consider when migrating from Version 7 Release 1 to

Version 7 Release 5.

Migrating from Version 7 Release 2

There are no issues to consider when migrating from Version 7 Release 2 to

Version 7 Release 5.

Chapter 3. Planning for Database Migration

Migrating from Version 7 Release 3

There are no issues to consider when migrating from Version 7 Release 3 to

Version 7 Release 5.

Migrating from Version 7 Release 4

There are no issues to consider when migrating from Version 7 Release 4 to

Version 7 Release 5.

Release Coexistence Considerations

For installations with multiple databases, you should migrate all your databases to

the current level. All users have the same features available to them, and future

database migrations are easier.

Applications at any supported release level can access application servers at any

supported release level. However, if an application requester and application

server are at different release levels, any functions used must be available in both

release levels. That is, you cannot use any new release facilities from ISQL, DBS

Utility, or application programs when the application server is running a different

level of DB2 Server for VSE & VM than the application requester.

All existing applications that accessed a database before the database was migrated

to another release level continue to work after migration.

See Appendix I, “Incompatibilities Between Releases,” on page 389 for

incompatibilities that exist between each release and the next release.

Changing the Server Name and Application Server Identifier

Situations exist where you may want to change the application server name

(DBNAME), application identifier (APPLID), or CICS transaction program name

(TPN).

These changes are made in the DBNAME directory. For details, see “Setting Up the

DBNAME Directory” on page 23.

Moving a Database

Using the SQLDBDEF Utility

The SQLDBDEF can be helpful if you are moving your database. This utility

extracts the definition of database objects from a DB2 Server for VSE & VM

database, and generates a DBSU job that can be used to create the same objects on

another DB2 database. The target database can be any DB2 database, for example,

DB2 Server for VSE & VM, DB2 UDB for OS/390, DB2 UDB for Linux, etc. Once

the objects have been created on the target platform, the load utilities of the target

database can be used to load the data. Packages can be unloaded from the source

database and reloaded to the target database so that existing client applications can

continue to be used.

For more information on the SQLDBDEF utility, see Appendix G, “Service and

Maintenance Utilities,” on page 381.

System Administration

Chapter 4. Planning for Operation of the Database Manager

Once the DB2 Server for VSE code is installed and your database generated, the

operator can start the application server so that users can access the databases and

submit SQL statements. This chapter explains the planning tasks associated with

starting, running, and stopping the application server. For information on the

actual operator commands, see the DB2 Server for VSE & VM Operation manual.

The examples in this book assume that you have loaded the IBM-supplied

procedures containing the job control statements needed for each database and for

referencing the DB2 Server for VSE library.

Starting the Application Server

This section discusses the following topics:

v Modes of operation

v Multiple user mode initialization parameters

v Single user mode initialization parameters

v Tape support

v Starting the application server in multiple user mode

v Running multiple user mode applications

v Starting the application server in single user mode

v Overriding initialization parameters

v Creating a parameter data set

Modes of Operation

The database manager can be operated in either multiple user mode or single user

mode.

In multiple user mode, more than one user or application can concurrently access the

same database. The database manager runs in one VSE system partition while

applications run in other partitions. The initialization parameter SYSMODE=M

defines this mode.

In single user mode, only one user or application can be run at one time. Both the

database manager and the application program run in the same VSE system

partition. The initialization parameter SYSMODE=S defines this mode.

Many of the database manager facilities, including support for ISQL, CICS

transactions, and VSE/ICCF, are available only in multiple user mode. Support for

the DBS utility, preprocessors, and batch applications is available in both multiple

and single user modes. Support for special facilities (such as ADD DBEXTENT) is

available only in single user mode.

Multiple User Mode Initialization Parameters

Table 5 on page 48 identifies the initialization parameters that apply when the

database manager is operating in multiple user mode, and lists their defaults. A

discussion of the appropriate settings for these parameters follows.

Table 5. Multiple User Mode Initialization Parameters

Parameter

Default

Minimum

Maximum

Environment Parameters

From DBNAME

DBNAME=name

—

directory

RMTUSERS=nnnnn

65535

SYSMODE=M

—

STARTUP=W|R|F|U

—

PARMID=name

None

—

DBPSWD=password

None

—

CHARNAME=name

INTERNATIONAL

—

ACCOUNT=T|D|E|N

—

SYNCPNT=Y|N

If RMTUSERS > 0, Y

—

DSPSTATS=nn

TCPDISPB

100

TCPMAXRT=n

158

9999

TCPPORT=n

DBNAME Directory

65535

TCPRETRY=Y|N

—

SECALVER=Y|N

—

SECTYPE=DB2|ESM

DB2

—

Performance Parameters

NCUSERS=n

251

NPACKAGE=n

32766

NPACKPCT=n

100

NPAGBUF=n

10 + NCUSERS x 4

40000

NDIRBUF=n

NPAGBUF

40000

NLRBU=n

1000

583333

(2 x NCUSERS) +

larger of

NLRBS=n

(NLRBU x NCUSERS)/2

+10

(2 x NCUSERS)

DISPBIAS=n

NCSCANS=n

655

LTIMEOUT=n

99999

PTIMEOUT=n

180

99999

PROCMXAB=n

255

Recovery Parameters

LOGMODE=Y|A|L

—

CHKINTVL=n

99999999

SLOGCUSH=n

ARCHPCT=n

TAPEMGR=N|Y

—

ARCHTAPE=REW|UNL

REW

—

SOSLEVEL=n

100

System Administration

Table 5. Multiple User Mode Initialization Parameters (continued)

Parameter

Default

Minimum

Maximum

Service Parameters

DSPLYDEV=L|C|B

—

DUMPTYPE=P|F|N

—

EXTEND=Y|N

—

TRACDBSS=nnn...

000...

222...

TRACRDS=nnnnnnn

0000000

2222222

TRACWUM=n

TRACDRRM=nnnn

0000

2222

TRACDSC=nn

TRACCONV=n

TRACSTG=n

TRACEBUF=n

99999

Environment Parameters

DBNAME

This parameter specifies the application server to be started. Different application

servers can be started in different partitions (up to a maximum of 36). With

multiple server support, different procedures can be written to link the appropriate

disks for each database. When starting the application server, correlate the

procedure name with this parameter. If not specified, the application server is

started with the default specified in the DBNAME directory. For more details, see

“Choosing an Application Server Name” on page 23.

The following examples show the DBNAME parameter specified correctly with

two procedures to start two different application servers.

JOB xxxxx

EXEC PROC=ARIS75SL

EXEC PROC=SQLDB1

EXEC PGM=ARISQLDS,SIZE=AUTO,PARM=’STARTUP=W,DBNAME=SQLDB1_NEWYORK_INV’

JOB yyyyy

EXEC PROC=ARIS75SL

EXEC PROC=SQLDB36

EXEC PGM=ARISQLDS,SIZE=AUTO,PARM=’STARTUP=W,DBNAME=SQLDB36_TORONTO_INV’

Figure 14. Examples of Job Control to Start a Database in Multiple User Mode

RMTUSERS

This parameter can be specified only if the DRDA code can be installed.

Chapter 4. Planning for Operation of the Database Manager

The value specified for RMTUSERS is the maximum number of remote users that

can access the application server, and can be set to any number from 1 to 65535

(inclusive). The default is 0. The appropriate value for RMTUSERS depends on the

availability of virtual storage.

If RMTUSERS is not specified or the value is 0, remote users will not be able to

access the application server.

SYSMODE

This parameter is used to specify either single(S) or multiple(M) user mode. Set it

to M to initialize the database manager for multiple user mode operation. This is

the default mode.

STARTUP

This parameter specifies how the database will be started:

v Most of the time let STARTUP default to W (warm start).

v Use STARTUP=R (restore) to restart the application server and restore the

database from an archive tape file. This setting causes the VSAM data sets to be

reset before the data is restored.

v STARTUP=F (fast restore) also restores the database from an archive tape, but

does not format the data sets. Only use it if you have not changed the database

files. (The database files would be changed, for example, when there is a media

failure.)

v Specify STARTUP=U (user restore) if you have archived and restored the

database with user facilities.

For more information, see “Restoring the Database” on page 158.

PARMID

This parameter can be used to specify an A-type source member containing the

values for the other initialization parameters. Application program parameters

(user parameters) cannot be included. Figure 15 shows an example of startup of the

application server that uses the PARMID initialization parameter.

DBPSWD

When you define the data sets for your database, you can define a password to

protect them from unintentional or malicious access. All the data sets for a

database must have the same VSAM password, which is defined with the

VSE/VSAM DEFINE CLUSTER command. Then, when starting the application

server, the operator must specify this password with the DBPSWD parameter, as

shown in Figure 15. If the specified password does not match the one defined for

the data sets, the operator is prompted to supply the correct one.

// JOB MULTI

// EXEC PROC=ARIS75SL

// EXEC PROC=ARIS75DB

// EXEC PGM=ARISQLDS,SIZE=AUTO,PARM=’PARMID=WARM1,DBPSWD=password’

Figure 15. Job Control to Start in Multiple User Mode with Password-Protected Data Sets

System Administration

CHARNAME

This section discusses the following:

v Character set considerations at startup

v National language considerations at startup.

Character Set Considerations at Startup: Use the CHARNAME parameter to

specify the CCSIDs to be used as the application server defaults. The default

CCSIDs determine the character sets and code pages to be used to interpret

statements and return results.

The valid CHARNAME values you can specify are ENGLISH (CCSID=37),

INTERNATIONAL (CCSID=500), and all the values that are in the CHARNAME

column of the SYSTEM.SYSCCSIDS catalog table.

The database manager obtains the CCSIDs associated with the CHARNAME by

looking up the row of the SYSTEM.SYSCCSIDS catalog table where the

CHARNAME column matches the CHARNAME parameter. It also obtains the

classification and translation tables associated with the CHARNAME by looking

up the row of the SYSTEM.SYSCHARSETS catalog table where the NAME column

matches the CHARNAME parameter. The classification table is used to identify

valid characters in identifiers. The translation table is used to indicate how to fold

ordinary lowercase identifiers to uppercase.

For CHARNAMEs ENGLISH and INTERNATIONAL, their CCSID values, the

classification table and the translation table are stored internally. The rows in

SYSTEM.SYSCCSIDS and SYSTEM.SYSCHARSETS for these CHARNAMEs are for

reference purposes only and are not used by the database manager.

During startup, if you do not specify the CHARNAME parameter, the application

server uses the same CHARNAME that was used the last time it was started. The

values stored in the rows where SQLOPTION equals CHARNAME, CCSIDSBCS,

CCSIDMIXED, and CCSIDGRAPHIC are for reference purposes only. They reflect

the current values associated with the system. The only way to change the default

values is by starting the application server with a different CHARNAME

parameter. Any updates to the values in the SYSTEM.SYSOPTIONS table are

ignored during startup.

Note: The database manager determines the current default CHARNAME from the

CCSID attribute of the CNAME character column in the

SYSTEM.SYSCOLUMNS catalog table. If this value is null, then 37 is used (a

CCSID of 37 corresponds to a CHARNAME of ENGLISH). The database

manager uses the CCSID value to locate the corresponding row in the

SYSTEM.SYSCCSIDS catalog table to obtain the associated CHARNAME.

The value in the CHARNAME column of this row is the current application

server default CHARNAME.

When you specify a value for the CHARNAME parameter that is different from

the current application server default CHARNAME, you are prompted to choose

whether or not you want to change the application server default CHARNAME. If

you specify YES and have supplied a valid CHARNAME value, the database

manager updates the application server default values for CHARNAME,

CCSIDSBCS, CCSIDMIXED, and CCSIDGRAPHIC. It also modifies the CCSID

attribute of all character columns that are part of the catalog tables to the

application server default CCSID. The CCSID attribute of character columns that

are not part of the catalog tables are not modified. If the value for CCSIDMIXED is

Chapter 4. Planning for Operation of the Database Manager

not zero, this value is used as the application server default CCSID. If the value for

CCSIDMIXED is zero, then the application server default CCSID is the value of

CCSIDSBCS.

Note that the tables which have their CCSID modified when the CHARNAME is

changed include:

v All tables created by SYSTEM

v The following tables created by SQLDBA:

- SQLDBA.ROUTINE

- SQLDBA.STORED QUERIES

- SQLDBA.SYSLANGUAGE

- SQLDBA.SYSTEXT2

- SQLDBA.SYSUSERLIST

When a CHARNAME is changed, the following should be considered:

The FIPS Flagger package must be reloaded by using the ARIS360D procedure.

Failure to do this can cause SQLCODE=-931 (SQLSTATE=58004). This will

render the agent reporting the SQLCODE error unable to preprocess packages

until the application server is started. Once the FIPS Flagger package is

reloaded or repreprocessed, this error will not occur.

All views which are dependent on the tables that had their CCSID modified

must be dropped and recreated.

The following query lists all such view packages:

SELECT CREATOR, TNAME, PLABEL

FROM SYSTEM.SYSACCESS

WHERE TABTYPE

= ’V’

AND VALID = ’N’

This query is useful in that owners of affected views can be notified to drop

and recreate their view before they try and use the view and get an error

(SQLCODE=-835, SQLSTATE=56049, with SQLERRD1 set to -833).

All packages which are dependent on the tables that had their CCSID modified

must be dropped and recreated.

The following query lists all such packages:

SELECT CREATOR, TNAME, PLABEL

FROM SYSTEM.SYSACCESS

WHERE TABTYPE

= ’X’

AND VALID = ’N’

This query is useful in that owners of affected packages can be notified to

rebind the packages instead of having them dynamically repreprocessed at run

time. The DBS utility REBIND PACKAGE command can be used to rebind the

packages listed.

The ISQL package (SQLDBA.ARIISQL) and DBS utility package

(SQLDBA.ARIDSQL) can be reloaded and recreated using the ARIS360D

procedure. If this is not done, the first time these packages are used, they will

be dynamically repreprocessed.

To check if all the above activities have been done, run the following query:

SELECT CREATOR, TNAME, PLABEL

FROM SYSTEM.SYSACCESS

WHERE VALID = ’N’

System Administration

If there are no rows found, all packages have been either recreated, reloaded,

rebound or dynamically repreprocessed and the VALID column value for the

package in SYSTEM.SYSACCESS has been changed to “Y”.

Note that CCSID conversion of the data in catalog tables does not occur: only the

CCSID attribute of the columns is modified. If you change the application server

default CHARNAME, system objects of the character data type (for example, table

names and column names) stored in the catalog may be displayed differently. The

reason for this is that a code point may represent different characters in different

code pages.

If you want to change the application server default CHARNAME, the default will

not be changed if:

v You specify an invalid value for the CHARNAME parameter

v An error occurs in the verification of the

- New CHARNAME CCSID values

- Classification table

- Translation table.

When the application server is started, it records the application server default

values for CHARNAME, CCSIDSBCS, CCSIDMIXED, and CCSIDGRAPHIC in the

SYSTEM.SYSOPTIONS catalog table. To obtain these values, you can query the

table. For example, to determine the name of the character set that is currently in

use, issue:

SELECT VALUE

FROM SYSTEM.SYSOPTIONS

WHERE SQLOPTION = ’CHARNAME’

For more information about character sets, see Chapter 12, “Choosing a National

Language and Defining Character Sets,” on page 231.

National Language Considerations at Startup: You can use the SET LANGUAGE

command from the operator console to choose a national language so that DB2

Server for VSE messages can be received in the selected language. (You cannot

choose a double-byte character set (DBCS) language, as the VSE operator console

does not support DBCS.) For more information see “National Language Support

for Messages and HELP Text” on page 259.

ACCOUNT

This parameter enables the accounting facility. If ACCOUNT=T or ACCOUNT=D

or ACCOUNT=E is specified, accounting records will be generated and directed to

either a tape file, a SAM DASD file or a VSAM ESDS file, respectively. (The tape or

DASD file must be identified in your job control for starting the application

server.) If the default value of ACCOUNT=N is specified, accounting information

is not generated.

For a complete description of the accounting facility, see Chapter 10, “Using the

Accounting Facility,” on page 187.

SYNCPNT

This parameter specifies whether or not a sync point manager (SPM) will be used

to coordinate DRDA2 DUOW two-phase commit and resynchronization activity. It

is only meaningful when the RMTUSERS parameter is greater than zero.

If Y is specified, the server will use a sync point manager, if possible, to coordinate

two-phase commits and resynchronization activity. If N is specified, the server will

Chapter 4. Planning for Operation of the Database Manager

not use an SPM to perform two-phase commits. If N is specified, the database

manager is limited to multi-read, single-write distributed units of work and it can

be the single write site. If Y is specified, but the database manager finds that a

sync point manager is not available, then the server will operate as if N was

specified.

The default is SYNCPNT=Y, if RMTUSERS is greater than zero.

DSPSTATS

This two digit parameter specifies what information is displayed and what level of

detail is displayed. If 0 is specified, nothing is displayed. If 1 is specified, the

minimum information is displayed. If 2 is specified, more detail is displayed. The

positional digits correspond to the following informational displays: the first is

checkpoint performance information and the second is counter information to be

displayed at system shutdown.

If the first option is 1, then format 1 of message ARI2052I is displayed every time a

checkpoint occurs. This is useful in determining how often checkpoints occur. If

the first option is 2, then format 2 of message ARI2052I is displayed every time a

checkpoint occurs. This is useful in determining if checkpoint processing is causing

a performance problem.

If the second option is 1, then the “COUNTER *” operator command is issued just

before the application server is shutdown. This is useful for performance tuning.

The SET command changes the value of this parameter without having to stop and

restart the application server. For more information on the SET operator command,

see the DB2 Server for VSE & VM Operation manual.

SECALVER

This parameter determines if the application server will accept users that have

already been verified by another system. If SECALVER=Y, verified users will be

accepted. The requester only needs to send a user ID to be validated. If

SECALVER=N, verified users will not be accepted. The requester must send a user

ID and password to be verified.

Note: This parameter is only used when validating users are connecting via

TCP/IP or when users send the ACCSEC and SECCHK DRDA datastreams

in their connect request.

SECTYPE

This parameter determines if the application server will validate a user ID and

password for connect authority using an external security manager or by checking

the DB2 SYSUSERAUTH catalog table. If SECTYPE=ESM an external security

manager will be used to validate the user ID and password. The external security

manager must support the RACROUTE application programming interface. If

SECTYPE=DB2, the user ID and password are validated by checking the

SYSUSERAUTH catalog table.

Note: This parameter is only used when validating users are connecting via

TCP/IP or when users send the ACCSEC and SECCHK DRDA datastreams

in their connect request.

System Administration

TCPDISPB

This value specifies how frequently the TCPIP agent is dispatched when there are

no agents ready to run and a system wait must be done. The TCPIP agent will be

dispatched every n times a system wait must be done. Otherwise, the system wait

is performed by the DB2/VSE dispatcher.

Valid values are 1 to 100.

Setting the value to a high number can improve the performance of agents that are

doing I/O intensive queries and are not using TCP/IP as the communications

protocol. This setting will not affect the performance of CPU intensive queries as

much as it will affect I/O intensive queries.

Setting the value to a high number can degrade the performance of users that are

using TCP/IP as the communications protocol.

This value is ignored if RMTUSERS=0. It is only active if TCP/IP support is

enabled.

TCPMAXRT

This parameter specifies the maximum number of times the application server will

attempt to re-enable TCP/IP support if it was disabled.

For a complete description of TCP/IP support, see Chapter 15, “Using TCP/IP

with DB2 Server for VSE,” on page 335.

TCPPORT

This parameter specifies the TCP/IP port number that the application server will

use to listen for incoming TCP/IP connect requests.

If this parameter is not specified, TCP/IP support will be initialized and the

DBNAME Directory on the TCP/IP client disk will be searched to determine the

port number that the application server will use.

If this parameter is specified with a non-zero value, TCP/IP support will be

initialized and the value specified will be used as the port number that the

application server will use.

If this parameter is specified with a value of 0, TCP/IP support will not be

initialized.

For a complete description of TCP/IP support, see Chapter 15, “Using TCP/IP

with DB2 Server for VSE,” on page 335.

TCPRETRY

This parameter determines if the application server will automatically attempt to

re-enable TCP/IP support if it becomes disabled.

For a complete description of TCP/IP support, see Chapter 15, “Using TCP/IP

with DB2 Server for VSE,” on page 335.

Performance Parameters

NCUSERS

This parameter defines the maximum number of real agents that the database

manager can actively handle at any one time, limiting the number of users that can

Chapter 4. Planning for Operation of the Database Manager

be supported by the database manager. The value of NCUSERS is usually less than

the number of connected users anticipated, because not all users will be accessing

data at the same time. This value directly affects the size of the database partition

required.

The number of NCUSERS is limited because some static agent storage for each real

agent is obtained below 16 megabytes.

Figure 16 provides guidelines for setting the NCUSERS parameter. Because these

are only guidelines, you should modify them to concur with the activity on your

system. For additional information, see the DB2 Server for VSE & VM Performance

Tuning Handbook.

NCUSERS=

1 for each 1-2 users of ISQL (or other query products)

+ 1 for each 2-5 application program developers (VSE/ICCF users)

+ 1 for each 4-10 non-ISQL CICS users

+ 1 for each batch partition supported

+ 1 for each 4-10 remote users

Figure 16. Guidelines for the NCUSERS Parameter

Each ISQL user can generate a high level of system activity. If you set NCUSERS

so that all ISQL users can be active at the same time (NCUSERS=number of ISQL

users), you minimize the time that any one user must wait for services. However,

if this number is large, it may cause the database manager to be overloaded. To

prevent this, you should also use the CICS DFHSIT parameter CMXT, which limits

the number of users who can be logged on to ISQL. For information on this

parameter, see “Controlling Access by ISQL Users” on page 119.

Application developers (VSE/ICCF users) typically do a considerable amount of

other activity (such as VSE/ICCF file editing or output scanning). These users

require less service from the database manager, so NCUSERS can be lowered

accordingly.

If you are using VSE guest sharing, the NCUSERS of the VM database machine

should be increased by the number required for the VSE guest. The demand for

services from CICS transaction processing can vary widely, depending on the

nature of the transactions.

The demand for services from batch application programs can also vary

considerably. If you have online or interactive activity on the database manager,

consider limiting the amount of concurrent SQL batch processing.

Note: When the application server is started, there may be one or more in-doubt

logical units of work (LUWs). The value of NCUSERS must be large enough

to handle these. When they have been resolved, the DB2 Server for VSE

agent structures are used to handle new users. The creation and use of agent

structures for resolving in-doubt LUWs takes precedence over all new user

logical units of work. For more information about in-doubt LUWs, see

“Resolving In-Doubt Transactions” on page 98.

NPACKAGE

This parameter defines the maximum number of packages in an LUW, and

together with the value specified for NCUSERS, determines the size of the package

cache. The size of the package cache limits the number of packages that can be

System Administration

present in storage simultaneously. (Package cache size =

NPACKAGE x NCUSERS.) The default value of NPACKAGE is 10, and that for

NCUSERS is 5, giving a default package cache of 50, allowing 50 packages to be

present in storage simultaneously.

In general, increasing the size of the package cache improves performance of the

database manager. However, do not increase it to the point where system paging

becomes too great. For more information, see the DB2 Server for VSE & VM

Performance Tuning Handbook.

NPACKPCT

This parameter defines the percentage of the package cache that is used in the

calculation of the package cache threshold. The size of the threshold determines the

number of loaded packages that are kept in storage at the end of an LUW.

(Threshold = NPACKPCT percent of package cache.) If the threshold is exceeded,

the loaded packages are freed and returned to the package cache.

The default values for NPACKPCT and the package cache are 30 and 50

respectively, giving a threshold of 15. In general, increasing the size of the

threshold improves performance. For more information, see the DB2 Server for VSE

& VM Performance Tuning Handbook.

NPAGBUF

This parameter specifies the number of 4096-byte data pages kept in storage

buffers at one time. The number of data buffers you want depends on the number

of active users and the nature of their request. The default for NPAGBUF assumes

an average of four buffer pages for each potentially active user (NCUSERS x 4),

plus ten buffer pages for the buffering of catalog and log information.

In general, increasing NPAGBUF improves the performance of the database

manager. However, increasing it also requires an increase in the size of the

database partition. Also -- and more importantly -- it can cause an increase in the

paging rate of the system. It is more efficient to let the database manager do more

I/O operations than it is to let the system do more paging; database I/O

operations are overlapped whereas system paging operations are not. Therefore do

not increase NPAGBUF to the point where system paging becomes too great.

For more information about NPAGBUF, see the DB2 Server for VSE & VM Diagnosis

Guide and Reference manual.

NDIRBUF

This parameter determines the number of 512-byte directory pages to be kept in

storage. Increasing it reduces the number of I/O operations. Again, bigger is better,

until you either run out of virtual storage or cause too much system paging. Each

directory page addresses 128 data pages.

When you set NPAGBUF and NDIRBUF, you have to choose how to split buffer

space between data pages and directory pages. At least initially, you should set

them to the same value. Issue the COUNTER commands to see the actual I/O

activity; then adjust NPAGBUF and NDIRBUF.

For more information about NDIRBUF, see the DB2 Server for VSE & VM Diagnosis

Guide and Reference manual.

Chapter 4. Planning for Operation of the Database Manager

NLRBU and NLRBS

NLRBU specifies the maximum number of lock request blocks allowed for one

active user, while NLRBS specifies the number allowed for all active users.

(Usually, two lock request blocks are used for every lock that a user holds.)

The database manager can perform lock escalations, increasing the granularity of

data being locked from either row or page level to dbspace level. In general, you

only need to change the default values of NLRBU and NLRBS if contention

problems occur. Increasing them reduces the number of lock escalations performed

by the database manager.

When either the NLRBU limit for a user is reached or the NLRBS limit is

approached, lock escalation occurs. This results in fewer locks being required, and

lock request blocks being freed. This in turn reduces the opportunities to share

data. For example, when locking is done at a row level, many users may be

updating the same dbspace at the same time. When it is escalated to the dbspace

level, only one user can update rows in that dbspace. Everyone else must wait

until that person’s update is committed or rolled back.

Escalation can also cause deadlocks. A deadlock occurs when two or more LUWs

are in wait states and dependent on the completion of LUWs that are also in wait

states. For example, suppose two users are updating tables in a dbspace. When the

lock size is escalated to a dbspace level, both users can be locked out, with each

waiting for the other to complete an LUW. The database manager resolves

situations like these by rolling back the newest LUW. For more about locking, see

the DB2 Server for VSE & VM Application Programming manual.

If the default values for NCUSERS (5) and NLRBU (1000) are used, the database

manager defines 2520 lock request blocks, each of which requires 24 bytes; 60480

bytes of virtual storage are required for lock request blocks. With these defaults,

one application could use 1000 lock request blocks and four other applications

could simultaneously use an average of 370 lock request blocks each, before

causing an escalation.

Even though two lock request blocks are needed for each lock, the default values

allow a large number of locks for each application. With the defaults, one

application could use 500 locks while four other applications use an average of 185

locks each.

You should use the NLRBU and NLRBS default values at first, and increase them if

users either are experiencing delays when they access the database manager, or if

they are receiving SQLCODEs of -911, -912, or -915 (rollbacks that occur because of

deadlock, insufficient lock request blocks for the database manager, or insufficient

lock request blocks for a user application, respectively).

Note: These SQLCODEs may also be received during preprocessing, as the locks

are required then as well.

To test the frequency of lock escalations and of deadlocks, use the COUNTER

operator command. Specify both the ESCALATE and the LOCKLMT counters to

get the number of successful escalations and the number of unsuccessful escalation

attempts respectively. (An escalation can fail if the LUW that reached the lock limit

is rolled back because of a deadlock, or if a sufficient number of lock request

blocks cannot be freed.) For example, suppose the operator issues the command

COUNTER ESCALATE LOCKLMT a few times a day and normally receives results in the

System Administration

range of 10 to 150 for ESCALATE, and 0 to 5 for LOCKLMT. If, one day, the results

are 428 for ESCALATE and 23 for LOCKLMT, a locking problem would be

indicated.

In addition, the SHOW LOCK MATRIX command can be used to display information

about lock request block usage to determine whether unexpected delays are caused

by locking; to monitor how the database manager is using lock request blocks; and

to determine the lock request blocks required for a single application or for a run

of a preprocessor.

One of the values displayed is called MAX USED BY LUW: the maximum number

of lock request blocks used by any one application during an LUW. (When any

LUW starts to exceed NLRBU and the escalation process occurs, MAX USED BY

LUW is set to zero.) All this information can help you determine the required

values for NLRBU and NLRBS.

To establish the lock request block requirements for running a preprocessor, or for

an application that is causing contention problems:

1. Start the application server in multiple user mode with NCUSERS=1, NLRBU

about five times its current setting, and NLRBS set to the same value as

NLRBU.

2. Start the application and allow it to complete processing.

3. Verify that no escalation occurred by displaying the ESCALATE and LOCKLMT

counters. If no escalation occurred, MAX USED BY LUW will show the number

of lock request blocks required.

4. If an escalation did occur, set NLRBU to a value greater than or equal to MAX

USED BY LUW, then start the application server again, and rerun the

application.

If necessary, reset NLRBS. For example, suppose NLRBU is set to 1100, and two

users will run their applications -- each requiring 1100 lock request blocks -- at the

same time. Also assume that any other application requires about 500 lock request

blocks. If NCUSERS is 5, then set NLRBS to at least 3700 (1100 for each of two

applications and 500 for each of three additional applications).

If an application requires more lock request blocks than you have virtual storage

for, you should consider the following alternatives:

v Use either the SQL ALTER DBSPACE or the SQL LOCK statement to change the

locking level of the dbspace used by the application. The ALTER statement

permanently changes the locking level for all applications, while the LOCK

statement can be inserted into an application, and used to change the locking

level only when that application runs. The LOCK statement is the preferred way

to temporarily modify the locking level, because it involves no update to the

catalog tables.

v Consider changing the application: perhaps it is holding locks longer than

necessary. Additional SQL COMMIT WORK statements in the application may

necessitate fewer locks.

v Consider running the application by itself: either in single user mode, where no

locking is required, or in multiple user mode with a reduced NCUSERS and

with NLRBU and NLRBS set as required.

For more information about locking problems and how to solve them, see the DB2

Server for VSE & VM Diagnosis Guide and Reference manual.

Chapter 4. Planning for Operation of the Database Manager

DISPBIAS

This parameter determines how the dispatcher selects the order in which agents

get serviced by the database manager. To set it, you need to understand how the

dispatcher works. Only one agent at a time can be serviced; the other agents wait

in a queue. Within this queue, agents are prioritized according to their estimated

resource consumption: those estimated to consume the least are placed at the top,

while those estimated to consume the most are placed at the bottom.

When the active agent returns to the dispatcher, the next agent at the top of the

queue is dispatched. Every time an agent is dispatched, the database manager

reevaluates the priority of the remaining agents, and requeues them according to

their new priorities.

A pure priority dispatcher can present some problems, however. If many

short-running LUWs are present, the longer-running ones may never get serviced:

they are always at the bottom of the queue. To avoid this problem, fair-share

auditing is used, whereby all the agents in the queue are checked periodically to

see if they are receiving adequate service. When one is found that is not, its

priority is changed and it is moved to the top of the queue.

If fair-share auditing is done frequently, the dispatcher tends to operate more like a

round-robin dispatcher: agents get equal service because those at the bottom of the

queue get bumped to the top more frequently. If it is done infrequently, the

dispatcher tends to operate more like a priority dispatcher: agents get prioritized

service because long-running agents are forced to wait at the bottom of the queue

longer. (Eventually, fair-share auditing causes these agents to get service.)

The DISPBIAS parameter determines how often fair-share auditing is done. When

it is set low (near 1), fair-share auditing is done frequently, and the dispatcher

operates more in round-robin mode. When it is set high (near 10), fair-share

auditing is done infrequently, and the dispatcher operates more in priority mode.

Initially, you should use the DISPBIAS default of 7. If your long-running LUWs are

getting poor service, you may want to use a lower value; if your ISQL users are

often waiting for long-running applications to complete, you may want to use a

higher value. You can use the SET operator command to change the value of

DISPBIAS without having to stop and restart the application server. See the DB2

Server for VSE & VM Operation manual for more information on the SET operator

command.

Note: Any changes you make using the SET command are only in effect while the

application server is running. If you stop and restart the application server,

it will use the settings you specified in the startup procedure.

You may be tempted to set DISPBIAS to 10 to get good response time for ISQL

users. Keep in mind, however, that a long-running LUW can hold a large number

of locks. If other users are waiting for those locks, they must wait until the

application frees them. If the application is waiting at the bottom of the queue,

everyone is waiting. In this situation, you would want to have fair-share auditing

occur more frequently, so the long-running unit can free the resources it has

locked. The default of seven represents a balance between the interests of

long-running and short-running LUWs.

NCSCANS

This parameter determines the number of internal control scan blocks kept for

accessing tables and indexes. These blocks can vary in size and number depending

System Administration

on the type of query being performed. This discussion is concerned with

long-running requests that might be queries or database change operations.

Scan control blocks contain positioning information related to a query. The

positioning information can result from a user-defined cursor or by an internal

cursor created by RDS. If an index is involved in the query, the size of the scan

control block depends on the key size for that index. An average scan control block

is assumed to be 50 bytes (32 bytes for control information, and an average key

length of 18 bytes).

The maximum table size to hold the scan control block entries for each agent is 32

kilobytes (32768 bytes). This can contain 655 entries of 50-byte scan control blocks,

which in general, is enough to support 255 user-declared cursors. If, however, the

key lengths for indexes are long, the scan table supports fewer user cursors. For

example, if the key length for a given index associated with a cursor is 255 bytes,

an entry would require 287 (255 + 32) bytes, and the maximum number of cursors

possible using that index would be 114 (32 kilobytes divided by 287). That number

would be reduced if the DB2 Server for VSE requests caused internal cursors to be

created. Internal cursors are always smaller than 50 bytes, and cannot use index

keys.

If you have many complex requests, you may have to increase NCSCANS. If it is

not set to a high enough value, users will get SQLCODE -522. For information on

the virtual storage used by NCSCANS, see the DB2 Server for VM Program Directory

LTIMEOUT

This parameter specifies a general lock wait timeout period for any SQL

application, and especially as the way to avoid global deadlocks for DUOW

applications.

The range of the LTIMEOUT value is 0 to 99999 seconds. The value of zero

indicates that no lock timeout should be enforced for agents connected to this

database. This is the default value for a database.

A nonzero lock timeout value will cause any agents waiting for a lock to have their

current transaction rolled back when the lock timeout period has expired. The

agent will notify the application that a lock timeout has occurred with SQLCODE

-911

(SQLSTATE 40001). A reason code will be returned to indicate whether it is a

deadlock or lock timeout situation (reason code 2 for a deadlock situation and

reason code 68 for a lock timeout situation). The lock timeout period begins at the

moment an agent requests a lock on any database resource. The full lock timeout

period is allowed for each lock request.

The lock timeout control parameter should be adjusted in those environments

where lock contention between applications has started to affect the desired

performance and concurrency levels.

If a lock timeout is required for your environment, it is recommended that your

starting value be equivalent to the maximum period of time that you want an

application to wait for a lock.

Note: The LTIMEOUT parameter is changed through the SET operator command.

The timeout value will affect any users currently in LOCK WAIT. If a user

has been in a LOCK WAIT for 100 seconds and the value of LTIMEOUT is

Chapter 4. Planning for Operation of the Database Manager

set to a value less than 100, that user will receive a timeout. For more

information on the SET operator command, see the DB2 Server for VSE &

VM Operation manual.

If lock timeout control is activated, you should ensure that all applications

recognize and can handle the -911 SQLCODE that may be received as the result of

a lock timeout initiated rollback.

Note: New units of work that are waiting to begin because a log archive

checkpoint is running or is scheduled to run are in a lock wait. The SHOW

LOCK WANTLOCK operator command shows these units of work waiting

to acquire an IX lock on the database. Because log archive checkpoints can

potentially take a significant amount of time to complete, units of work in

this particular type of lock wait are ignored by the lock timeout function.

PROCMXAB

This parameter specifies the number of times a stored procedure is allowed to

terminate abnormally, after which a STOP PROC ACTION REJECT is performed

against the procedure and all subsequent SQL CALL statements for that procedure

are rejected. Note that a timeout that occurs while waiting for a stored procedure

server to be assigned for an SQL CALL statement is not included in this count.

PROCMXAB must be an integer between 0 and 255. The default, 0, means that the

first abend of a stored procedure causes SQL CALLs to that procedure to be

rejected. For production systems, you should accept the default.

PTIMEOUT

This parameter specifies:

v The number of seconds before DB2 Server for VSE & VM ceases to wait for an

SQL CALL to be assigned to a stored procedure server. If the PTIMEOUT

interval expires, the SQL CALL statement fails.

v The number of seconds before DB2 Server for VSE & VM ceases to wait for the

START PSERVER command to complete. If the PTIMEOUT interval expires, a

message is displayed and the START PSERVER command terminates.

The default for PTIMEOUT is 180.

Recovery Parameters

LOGMODE

This parameter determines whether archives will be taken for the database and the

log. Specify LOGMODE=A to maintain an archive of the database, LOGMODE=L

to maintain an archive of the log, and LOGMODE=Y if you want logging but do

not want the log archived.

LOGMODE=A allows you to restore the database and apply the current log.

LOGMODE=L allows you to maintain a database archive as well as log archives.

The database archive followed by the log archives are applied during restore, then

the current log is applied.

Use LOGMODE=A or L if it is important to protect the database against media

(DASD) failures; otherwise use LOGMODE=Y.

Note: Each sequence of log archives must be preceded by a database archive, so if

you use LOGMODE=L, you must occasionally take a database archive. You

do not need to switch to LOGMODE=A to do so.

System Administration

For more information on LOGMODE, see “Choosing a Log Mode” on page 148.

CHKINTVL

This parameter determines how often a checkpoint is taken. A checkpoint is an

internal operation in which data and status information is written to permanent

(DASD) storage, and a summary status record is written to the log data set. A

checkpoint causes two important events:

v Storage pool space is freed.

As updates to data occur, duplicate copies of changed data pages are

maintained. These copies (called shadow pages) are kept in the storage pools of

the pages that were changed. A checkpoint frees the shadow pages, and thereby

frees the storage pool space where they are kept.

v Log space may be freed.

If LOGMODE=Y, a checkpoint typically frees log space by moving the logical

beginning of the log forward to the beginning of the oldest LUW still active at

the time of the checkpoint. If LOGMODE=A or L, log space is only freed when

an archive is taken; not on every checkpoint.

Checkpoints are taken periodically: however, by the time one is taken, there may

be a large amount of data to be committed. If a failure should occur before it is

committed, much processing may need to be redone after the database is restored.

The CHKINTVL parameter lets you take checkpoints at predetermined intervals.

Its value is specified in terms of the number of log pages written between

checkpoints. You can use the SET operator command to change the value of

CHKINTVL without having to stop and restart the application server. See the DB2

Server for VSE & VM Operation manual for more information on the SET operator

command.

Note: Any changes you make using the SET command are only in effect while the

application server is running. If you stop and restart the application server,

it will use the settings you specified in the startup procedure.

By setting it low, you minimize the risk of filling the log or storage pools.

However, because checkpoints are time-consuming operations that suspend SQL

processing until they are completed, they should be taken infrequently. For more

information on setting CHKINTVL, see the DB2 Server for VSE & VM Performance

Tuning Handbook.

SLOGCUSH

This parameter defines the point at which the log cushion is entered and log-full

processing begins. Its value is expressed in terms of the percentage of the log size.

The default of 90 means that when the log is 90% full, log-full processing will be

initiated.

In log-full processing, the oldest active LUWs are rolled back until enough log

space is freed to bring the percentage of the log in use below the SLOGCUSH

level. Ideally, checkpoints and archiving would continually free log space so that

the log would never reach the SLOGCUSH level.

If the log should become 100% full, the database manager would end abnormally,

so you should set SLOGCUSH to a value that allows log-full processing to take

effect (free some log space) before this happens. If the database manager is ending

with log-full conditions, you may want to lower the SLOGCUSH value or increase

the size of your log data sets.

Chapter 4. Planning for Operation of the Database Manager

ARCHPCT

This parameter can be used to define a point at which an archive is automatically

initiated or when an attempt to switch to the inactive log is automatically initiated.

It is used only when LOGMODE=A or L is specified. Like SLOGCUSH, its value is

expressed in terms of a percentage of the log.

Archives free up log space; however, they take some time to complete. If the

SLOGCUSH value is reached during an online archive operation, all SQL

processing is suspended until the archive is done. For this reason, it is best to

ensure that archives are initiated in time to finish before the log fills to the

SLOGCUSH percentage. This is done by setting the value of ARCHPCT lower than

the value of SLOGCUSH.

When the log becomes full to the ARCHPCT value and alternate logging is not

enabled, a message is issued to the VSE system operator to mount an archive tape

and identify the cuu of the tape drive. The database manager then takes a database

or log archive depending on whether you have LOGMODE set to A (database) or

L (log).

If alternate logging is enabled, an attempt is made to switch to the inactive log. If

the switch cannot be made because the inactive log has not been archived, the

archive of both the inactive log and the active log will be initiated.

Normally, the operator explicitly archives the database or the log before the

ARCHPCT value is reached, by issuing one of the archive commands. If the

ARCHPCT is reached, meaning that the log is almost full, the action that the

database manager takes depends on the LOGMODE that is in effect. See Table 6

for

a summary of these actions.

Table 6. Summary of Activity When ARCHPCT Level Is Reached

LOGMODE

Parameter

Activity When ARCHPCT is Reached

An operator message is issued that requests a database archive.

L and

An operator message is issued that requests a log archive.

ALTLOG=N

L and

An attempt is made to switch to the inactive log.

ALTLOG=Y

Because the log cannot be archived, the value for ARCHPCT is ignored.

When the log is full it wraps. If an LUW spans the entire log, a

ROLLBACK WORK is forced for that LUW.

Note: To see how full the log is, you can issue the SHOW LOG command. For a

description of this command, see the DB2 Server for VSE & VM Operation

manual.

TAPEMGR

This parameter indicates whether there is a tape manager available to handle tape

assigns during database and log archives. Y indicates there is a tape manager; N

indicates there is no tape manager.

If TAPEMGR=N, the operator is prompted to enter the virtual device address for

the database or log archive (with message ARI0299A).

System Administration

If TAPEMGR=Y, the tape assign is handled by the tape manager and the operator

is not prompted to enter the virtual device number (cuu) of the database or log

archive.

ARCHTAPE

This parameter controls when archive tapes are unloaded. UNL indicates that at

the end of writing to each tape of a log or database archive, the tape will be

unloaded from the tape drive. This occurs regardless of whether the archives are

dynamically or statically assigned; REW indicates that only archives taken using

dynamic allocation will be unloaded at end of tape. If it is the last tape of the

archive, and end of tape has not been reached, the tape will remain in the drive

and must be unloaded manually by the operator.

SOSLEVEL

This parameter defines the storage cushion for storage pools. Its value is expressed

as a percentage of space remaining in a storage pool. In multiple user mode

processing (and single user mode processing where LOGMODE is not N), if any

storage pool gets full to the point where only the SOSLEVEL percentage of storage

pool pages is still free, a checkpoint is taken to free any shadow pages in use.

If, following this, only enough pages are freed to bring the number of free pages

just above the SOSLEVEL, frequent checkpointing could occur. For more

information, see the DB2 Server for VSE & VM Diagnosis Guide and Reference

manual. If, however, the number of free storage pool pages is still at or below

SOSLEVEL, message ARI0202I is issued once to inform the user that the number of

free pages left in the storage pool is fewer than the SOSLEVEL. This message is

also issued once in single user mode with LOGMODE=N, but no checkpoint is

taken.

Attention: If message ARI0202I is received, it indicates some action may be

needed to prevent imminent filling of the storage pool.

One possible action is to stop the application server and extend that storage pool

by adding dbextents to it. However, you can remedy the situation without

stopping the application server if you have set SOSLEVEL high enough to give

you adequate warning. When the message is received, proceed to remove

unneeded data from the storage pool, either by dropping dbspaces or tables, or by

reorganizing the data with a smaller percentage of free space for each page. In

order to do this, you must have adequate warning to schedule the necessary

processing.

Service Parameters

DSPLYDEV

This parameter:

v Defines where certain informational and error messages are to be routed

v Governs the display of startup messages including initialization parameters

derived from combining the DB2 Server for VSE defaults, parameters read from

a source member, and parameters specified with the EXEC command or job

control statement

v Controls the routing of any DB2 Server for VSE mini-dumps and shutdown

messages.

Depending on the operating procedures at your installation, set DSPLYDEV=C if

the output should be sent to SYSLOG; to L if the output should be sent to SYSLST;

and to B if the output should be sent to both SYSLOG and SYSLST.

Chapter 4. Planning for Operation of the Database Manager

Generally, you will want to set DSPLYDEV to either C or B for debugging a

problem from the operator’s console; and to L for normal operations.

DUMPTYPE

This parameter defines whether or not dumps are to be taken, and the amount of

information to be dumped if they are.

DUMPTYPE=N indicates that a dump is not taken.

DUMPTYPE=F gives you a full partition dump on some error conditions,

including trace points.

DUMPTYPE=P gives you a partial dump of the database partition, excluding major

phases (read-only code), on certain error conditions. A dump is not taken when a

limit error (message ARI0039E) or hardware error (message ARI0041E) occurs, or

when a user specification error is detected. It is recommended that you always use

DUMPTYPE=F and not DUMPTYPE=P, as partial dumps generally do not contain

enough information for debugging problems. The partial dump output is also

generated to the trace tape for some trace points.

Generally, you should not run with DUMPTYPE=N (no dumps), but you may find

occasions when you want to prevent dumping.

You can use the SET operator command to change the value of DUMPTYPE

without having to stop and restart the application server. See the DB2 Server for

VSE & VM Operation manual for more information on the SET operator command.

Note: Any changes you make using the SET command are only in effect while the

application server is running. If you stop and restart the application server,

it will use the settings you specified in the startup procedure.

For more information on dumps, see the DB2 Server for VSE & VM Diagnosis Guide

and Reference manual.

EXTEND

This parameter specifies whether or not special recovery commands are processed

at startup. Only set it to Y when you have a DBSS processing error or a severe user

error. For more information on this parameter, see the discussion on starting the

application server to recover from DBSS errors in the DB2 Server for VSE & VM

Diagnosis Guide and Reference manual.

TRACDBSS, TRACRDS, TRACWUM, TRACDRRM, TRACDSC,

TRACCONV, and TRACSTG

These parameters call the trace facilities during startup (as opposed to the TRACE

operator command). Except for TRACWUM and TRACDRRM (which are not

supported in single user mode), they are used primarily for tracing in single user

mode, but can be set in multiple user mode if you want to start tracing as soon as

possible. For information about tracing, refer to the DB2 Server for VSE & VM

Operation manual.

Security Auditing: The TRACRDS parameter is also used to start security audit

tracing during startup. A security audit is a special case of the normal trace facility.

Unlike other traces, which are usually only started for problem determination, a

security audit trace may be continually active while the database manager is

running. This may be a standard procedure for some installations.

System Administration

If you do not want the security audit to be continually active, you can start and

stop it with the TRACE operator command instead.

For more information, see the discussion on security auditing in the DB2 Server for

VSE & VM Database Administration manual.

TRACEBUF

This parameter specifies the amount of memory (in kilobytes) to allocate to the

trace buffer. Specifying a nonzero value causes trace output to be stored in a fixed

size buffer in memory. Trace records are stored in wrap-around mode in this buffer,

and when tracing is turned off, the contents of the buffer are written to disk or to

tape (as specified by the ARITRAC FILEDEF statement). The trace buffer is only

created if you specify TRACEBUF with at least one of the startup initialization

parameters TRACRDS, TRACDBSS, TRACDSC, TRACCONV, TRACDRRM,

TRACWUM, or TRACSTG; it is not created if the TRACEBUF default (n=0) is

specified. A suggested size for the trace buffer is 100 kilobytes or more. If you do

not specify TRACEBUF and tracing is requested, trace records are written directly

to disk or tape as the trace points are processed.

Single User Mode Initialization Parameters

Table 7 identifies the initialization parameters that apply when the database

manager is operating in single user mode.

Table 7. Single User Mode Initialization Parameters

Parameter

Default

Minimum

Maximum

Environment Parameters

DBNAME=name

From DBNAME directory

—

SYSMODE=S

—

STARTUP=W|R|F|U

—

PARMID=name

None

—

CHARNAME=name

INTERNATIONAL

—

ACCOUNT=T|D|E|N

—

DBPSWD=password

None

—

PROGNAME=name

None

—

DSPSTATS=nn

Performance Parameters

NPACKAGE=n

32766

NPACKPCT=n

100

NPAGBUF=n

10 + NCUSERS x 4

3500

NDIRBUF=n

NPAGBUF

28000

NCSCANS=n

655

Recovery Parameters

LOGMODE=Y|A|N|L

—

CHKINTVL=n

99999999

SLOGCUSH=n

ARCHPCT=n

TAPEMGR=N|Y

—

ARCHTAPE=REW|UNL

REW

—

Chapter 4. Planning for Operation of the Database Manager

Table 7. Single User Mode Initialization Parameters (continued)

Parameter

Default

Minimum

Maximum

Environment Parameters

SOSLEVEL=n

100

Service Parameters

DSPLYDEV=L|C|B

—

DUMPTYPE=P|F|N

—

EXTEND=Y|N

—

TRACDBSS=nnn...

000...

222...

TRACRDS=nnnnnnn

0000000

2222222

TRACDSC=nn

TRACCONV=n

TRACSTG=n

TRACEBUF=n

99999

Most of the considerations for setting these parameters are the same as those

described under “Multiple User Mode Initialization Parameters” on page 47, with

the following exceptions:

v The RMTUSERS parameter does not apply.

v The SYNCPNT parameter does not apply.

v The value of SYSMODE is S, which specifies that the database manager is

dedicated to a single application.

v The database manager does not generate accounting records when

STARTUP=C|E|L|S|I|M|P, which are special situations. For more information,

see the DB2 Server for VSE & VM Operation manual.

v The PROGNAME parameter is required (except when

STARTUP=C|E|L|S|I|M|P, which are special cases), to identify the application

program to be run.

v The NCUSERS parameter is not used; it defaults to 1.

v The DISPBIAS parameter does not apply.

v The NLRBS and NLRBU parameters are omitted (there is no locking in single

user mode).

v The LOGMODE parameter can take the value N, which specifies that changes

made by the application program are not to be logged.

If LOGMODE=N, database changes are only committed when a checkpoint is

explicitly taken (with COMMIT WORK statements).

The ARCHPCT parameter cannot be specified if LOGMODE=N.

v The TRACDRRM and TRACWUM parameters do not apply.

Tape Support

The database manager can write archive information, trace output, and accounting

output to tape files. You can use tape files for input and output to the DBS utility.

To assign tape files, use the usual TLBL job control statements. Most installations

place these statements for the trace, database archive, log archive, and accounting

tapes in the catalogued procedure used to identify the database data sets. An

System Administration

example of this is under “Step 3: Setting Up Your Database Job Control” on page

217. Other examples are shown throughout the manual as needed.

Note: All tapes used by the database manager must use IBM standard (EBCDIC)

labels. Unlabeled tapes are not supported.

Tape Manager Support

If you have a tape manager, you can take advantage of it when performing

archives. The initialization parameter TAPEMGR indicates whether a tape manager

is being used. During a database or log archive, if a tape manager exists and

TAPEMGR = Y, the tape manager handles the tape assign, eliminating the need to

enter the virtual device address of the archive output manually.

The archive initialization parameter ARCHTAPE enables you to specify whether

the database should unload archive tapes upon completion of the archive. Also, if

archives are statically assigned, each tape that is part of a multivolume database or

log archive can be unloaded upon completion of writing to each tape. This

parameter allows the operator to perform archives with minimal operator

intervention.

Starting the Application Server in Multiple User Mode

When the application server is started in multiple user mode, operator commands

can be issued and the operator may receive messages requesting that specific

actions be done (for example, mounting a tape).

If you have a single database, start the application server like any batch job, by

submitting job control statements or entering an EXEC command for ARISQLDS

from the system operator console. To simplify the startup process, keep the DLBL

and TLBL job control statements in the standard label area.

The job control example in Figure 17 shows how to start the application server by

allowing the default initialization parameters to set up a normal multiple user

mode environment.

// JOB MULTI

// EXEC PROC=ARIS75PL

// EXEC PROC=ARIS75DB

// EXEC PGM=ARISQLDS,SIZE=AUTO,PARM=’DBNAME=SQLDB1_NEWYORK_INV’

Figure 17. Job Control to Start in Multiple User Mode

Notes:

1. ARIS75PL is a cataloged procedure that contains the LIBDEF statements that

refer to the DB2 Server for VSE production libraries. It is updated during the

initial installation of the database manager. See the DB2 Server for VSE Program

Directory manual for instructions on how to create this procedure.

2. ARIS75DB is a cataloged procedure that contains the DLBL job control for

operating the database manager on your database. It (or one similar to it) is

defined when you generate the database and should be updated when (or if)

you add dbextents. For more information, see “Step 3: Setting Up Your

Database Job Control” on page 217.

3. For procedures ARIS75PL and ARIS75DB, substitute your own procedures or

job control statements to identify the database and the production libraries.

Chapter 4. Planning for Operation of the Database Manager

If you have generated more than one DB2 Server for VSE database, you would

have a job control procedure for each (for example, ARIS75DB, DBNAME01, and

DBNAME02). To start the application server, you would reference the appropriate

cataloged procedure.

There is nothing special about using cataloged procedures as shown in Figure 17:

this is just one of the ways you can use VSE job control facilities to run the

database manager. For other techniques, see your VSE manuals.

The job control statements and procedures must include:

An EXEC statement to run the program ARISQLDS. This statement can

optionally specify parameters for overriding the default initialization parameters.

A DLBL statement for the database directory, which must refer to the directory

data set (BDISK) defined for the database being accessed.

A DLBL statement for each log. Although one log is adequate, two are

recommended to protect against media failures on a log. The logs are named

LOGDSK1, LOGDSK2, ALTLGD1, and ALTLGD2.

One DLBL statement for each dbextent currently defined for the database. The

dbextents are named DDSK1, DDSK2, ..., DDSKnnn.

LIBDEF (and, perhaps, DLBL and EXTENT) statements that identify the

production libraries and any other needed libraries (for example, user

applications for exits).

If you intend to use archiving, a TLBL statement for the database archive file.

The file name on this statement must be ARIARCH.

If you intend to use log archiving, one TLBL statement for the log archive file

for the active log data set, and one for the database archive file that must

precede each sequence of log archives. If alternate logging is enabled, a TLBL

statement will be needed for the log archive file for the inactive log data set. The

file name on the TLBL statements must be ARILARC (active log data set) and

ARILALT (inactive log data set).

If you intend to use tracing, job control statements for the trace output file.

The trace output file can be a tape file or a DASD file. If it is to be a tape file,

you need a TLBL statement, and the file name on this statement must be

ARITRAC. If it is to be a disk file, you need a DLBL, an EXTENT, and an

ASSGN statement. If the disk file is managed by the VSE/VSAM Space

Management for SAM Feature, the EXTENT statement is optional, and the

ASSGN statement is not applicable. The file name on the DLBL statement must

be ARITRAC. For examples of job control statements that you can use for tracing

to disk, see the DB2 Server for VSE & VM Diagnosis Guide and Reference manual.

If you intend to use the accounting facility, a job control statement for each

accounting file. (You can use just one accounting file, but two are

recommended.) An accounting file, like a trace output file, can reside on tape or

disk. For an example of job control statements that can be used with the

accounting facility, see “Setting Up a Job Control for the Accounting Files” on

page 187.

Running Multiple User Mode Application Programs

Batch Application Programs

When the application server is started in multiple user mode, batch SQL

application programs can be started by normal means. Figure 18 on page 71 shows

the job control statements for starting a batch program and for passing user

parameters directly to that program.

System Administration

Note: If you plan to run your application programs in both multiple user mode

and single user mode, follow the protocols discussed in the section

“CALL/RETURN Protocols for Application Programs in Single User Mode”

on page 74.

// JOB USER PROGRAM WITH USER PARMS

// EXEC USERPROG,SIZE=AUTO,PARM=’parm1,parm2’

Figure 18. Job Control to Start a Batch Application Program

Notes:

1. The AUTO keyword is not required, but is recommended.

2. The user program must be preprocessed by the database manager before being

run.

VSE/ICCF Application Programs

Running SQL application programs under VSE/ICCF is the same as running any

program except it is recommended that you set GETVIS to AUTO on the

/OPTION statement. To run user SQL programs, the VSE/ICCF user would do an

/EXEC for the file containing the VSE/ICCF control statements. These statements

load the program and specify the GETVIS=AUTO option, as suggested in

Figure 19.

/LOAD MYPROG,PARM=’...’

/OPTION GETVIS=AUTO

/DATA

•

Figure 19. Example of VSE/ICCF Control Statements for Running an Application Program

CICS Transactions

All CICS transaction programs written to use the database manager can be called

using any of the means available under CICS. Usually, transactions are called

directly from a terminal. If the terminal user has signed on to CICS, the CICS user

ID is used as the default user ID for SQL operations done by the transaction only

if the transaction does not issue an SQL CONNECT statement. If the terminal user

has not signed on, the default user ID for CICS users is used. This ID was defined

when online support was started through the CIRB or CIRA transaction. For a

more complete discussion, see the DB2 Server for VSE & VM Application

Programming manual.

CICS transactions can also be initiated by other means not directly tied to users. In

these situations, the default user ID will be the one defined by the CIRB or CIRA

transaction.

For CICS SQL transactions to be run, the database manager must be running in

multiple user mode, and the online support must have been started with either the

CIRB or CIRA transaction.

CICS Pseudo-Conversational Transaction Considerations:

“Pseudo-

conversational” refers to a technique for coding CICS transactions that interact

Chapter 4. Planning for Operation of the Database Manager

with a user at a terminal. The transaction is not active while it is waiting for the

user to enter a response. The following scenario shows one method of coding a

pseudo-conversational transaction:

1. The transaction writes a question on the terminal.

2. The transaction issues a CICS RETURN with the TRANSID parameter specified.

3. The user enters the response.

4. CICS restarts the transaction automatically.

5. The transaction interprets the response.

6. The transaction can then ask another question or end.

ISQL is not pseudo-conversational. It runs as two CICS transactions (named ISQL

and CISQ). When a long-running SQL statement is being processed, the ISQL

transaction:

1. Issues message ARI7044I:

Command in progress. Terminal is now free.

2. Times out

3. Ends with a CICS RETURN without the TRANSID parameter.

This allows the user to enter ISQL CANCEL to cancel a long-running SQL

statement. If this is not done, the ISQL transaction is restarted by the CISQ

transaction when the SQL statement completes. The results of the SQL statement

are displayed when the ISQL transaction is restarted by the CISQ transaction.

If the ISQL transaction times-out (ends with message ARI7044I) and a

pseudo-conversational transaction is started, the following events can cause

confusion:

v If the pseudo-conversational transaction requests input from the user (and issues

a RETURN with TRANSID specified), the user is not able to cancel ISQL with an

ISQL CANCEL command, because the ISQL CANCEL is interpreted by CICS as

data to the pseudo-conversational transaction.

v If the pseudo-conversational transaction requests input from the user (and issues

a RETURN with TRANSID specified), and processing of the long-running SQL

statement ends before the user completes input and presses the ENTER key,

ISQL will display the SQL statement output on the terminal. This will overlay

any input that the user may have typed on the terminal for the

pseudo-conversational transaction. The transaction is waiting for input, but the

request for the input has been overlaid by the ISQL output. The

pseudo-conversational transaction continues to wait for input, so the user can

enter input to it after the ISQL transaction either times-out or ends.

To eliminate this confusion, avoid running pseudo-conversational transactions and

ISQL on the same terminal at the same time.

Starting the Application Server in Single User Mode

An application program running in single user mode runs in the database partition

under the control of the database manager. The application server is started in

single user mode (SYSMODE=S), and the program name is provided as an

initialization parameter (PROGNAME=name).

Figure 20 shows an example. When the application server is started, it passes

control to the application program specified by the PROGNAME parameter. All

other initialization parameters are allowed to default.

System Administration

Note: The PROGNAME parameter is not used if STARTUP is specified as C

(database generation), E (adding dbextents), L (log reformatting or

reconfiguration), S (adding dbspaces), I (reorganization of catalog indexes),

or M (catalog migration). These types of startup specify the operation to be

performed, so a program name is not needed.

// JOB SINGLE

// EXEC PROC=ARIS75PL

// EXEC PROC=ARIS75DB

// EXEC PGM=ARISQLDS,SIZE=AUTO,PARM=’SYSMODE=S,PROGNAME=name’

Figure 20. Job Control to Start in Single User Mode

Note: It may be necessary to specify SIZE=(AUTO,nK) for ARISQLDS, where the

nK value specifies the amount of storage required by the programming

language to load run-time routines and perform dynamic storage allocation.

Specifying User Parameters

When starting the application server in single user mode, you can also specify user

parameters to be passed to the application program, along with initialization

parameters passed to the application server. A slash (/) must be placed between

the application server parameters and the application program parameters, as

shown in Figure 21.

// JOB SINGLE WITH USER PARMS

// EXEC PROC=ARIS75PL

// EXEC PROC=ARIS75DB

// EXEC PGM=ARISQLDS,SIZE=AUTO,PARM=’SYSMODE=S,PROGNAME=PROG1/parm1,parm2’

Figure 21. Job Control to Start in Single User Mode and Provide User Parameters

Note: Up to 100 characters can be specified as parameters on the EXEC statement

or command. Each parameter must be separated by at least one comma or

blank; these commas and blanks also count as characters. The parameter

string cannot extend past column 71. If a continuation is needed, column 72

must contain a continuation character (any non-blank character), and the

parameters must continue in column 16 of the next line.

Parameters are passed to the application program by the standard VSE/ESA

protocol, as shown in Figure 22. When the database manager has processed its

initialization parameters, it passes the address (in register 1) of a pointer to the

application program specified by the PROGNAME parameter. (If there are no user

parameters, the pointer contains binary zeros.)

Chapter 4. Planning for Operation of the Database Manager

Pointer to

Length

User Parameters

Pointer

Parameters

(2 bytes)

(0 to 100 bytes)

(or zeros)

One way of using this protocol is:

1,15

NOPARM

CLC

0(4,1),=F ' 0 '

NOPARM

Process User Parameters

NOPARM EQU

Figure 22. Passing User Parameters to a User Application Program

Application program parameters are not displayed along with the initialization

parameters. Application program parameters also cannot be specified in a DB2

Server for VSE parameter data set.

CALL/RETURN Protocols for Application Programs in Single

User Mode

In single user mode, an application is called using normal CALL/RETURN

protocols, as follows:

Pointer to pointer to user parameters

Pointer to DB2 Server for VSE save area

Return point to the database manager

Entry point of the user program.

Note: This same protocol can also be used by programs running in multiple user

mode.

Upon entry, the application program must store the registers in the DB2 Server for

VSE save area, and restore them before returning control to the database manager.

Failure to do so causes unpredictable results.

The database manager sets an abnormal task termination routine to intercept

abnormal end conditions, including program checks. If the user program issues an

STXIT AB macro instruction, this macro overrides the DB2 Server for VSE STXIT

AB macro instruction. If the user program issues an STXIT PC macro instruction,

System Administration

this macro overrides the DB2 Server for VSE STXIT AB macro instruction for

program checks. A user program should not issue one of these STXIT macro

instructions.

Notes:

1. A PL/I application program can issue an STXIT PC macro instruction to

override the DB2 Server for VSE exit. If this is done, the database manager

cannot handle a program check, but it can still handle other abnormal end

conditions.

2. When a user runs an application with the TRAP(ON) run-time option of

LE/VSE and the DB2 Server for VSE application is running in single user

mode, LE/VSE and DB2 Server for VSE keep track of calls to and returns from

the database. If a program interrupt or abend occurs when the application is

running, the LE/VSE condition manager is informed whether the problem

occurred in the application or in the database manager. If the program interrupt

or abend occurs in the database manager, the LE/VSE condition handler passes

the condition back to DB2 Server for VSE. For more information, see the section

“Condition Handling with LE/VSE” in the DB2 Server for VSE & VM

Application Programming manual.

An application program should always return control to the database manager (if

possible). It should never issue a CANCEL, DETACH, DUMP, JDUMP, RETURN or

EOJ (or equivalent macro) instruction. These instructions prevent the database

manager from doing its normal shutdown processing, such as closing the database

files and the trace tape file (if one is being used).

The DB2 Server for VSE abnormal end routines issue CLOSE macro instructions for

the database, the trace and accounting files if those facilities were activated, and

the SYSLST file if it was opened. This same close process is also done when the

application program returns control to the database manager at the end of the job.

If you do not return control to the database manager, the files cannot be closed.

However, the database manager does not have to close these files. The VSAM

automatic close function will be started and the application server will still be

accessible. When the application server is next started, VSAM may issue an

informational message stating that the files were not closed in the previous run. If

tracing or accounting were active, their output files may not have had the last

buffer (or buffers) written. And, if the output files were on tape, no tape mark

would be written.

The database manager uses an “eye-catcher” technique for determining when a

specific module is in error. The eye-catcher is displayed in the DB2 Server for VSE

mini-dump. An application program can use the same technique in single user

mode, assuming that the DB2 Server for VSE abnormal end exit has not been

overridden by a user STXIT AB or STXIT PC macro instruction. A suggested

coding example in assembler language is shown in Figure 23.

Chapter 4. Planning for Operation of the Database Manager

USING

*,15

SKIPEYE

BRANCH AROUND EYE-CATCHER

AL1(16)

LENGTH OF CHARACTER STRING

CL8’progname’

PROGRAM NAME EYE-CATCHER

CL8’&SYSDATE’

DATE PROGRAM COMPILED

SKIPEYE EQU

STM

14,12,12(13) SAVE DB2 Server for VSE REGISTERS

BALR

12,0

ESTABLISH BASE REGISTERS

DROP

USING

*,12

11,MYSAVEAR

GET ADDRESSABILITY TO MY SAVE AREA

11,8(13)

SAVE ADDRESS OF SAVE AREA IN DB2 Server for VSE SAVE AREA

13,MYSAVEAR+4

SAVE ADDRESS OF DB2 Server for VSE SAVE AREA IN SAVE AREA

13,11

SET REGISTER 13 TO MY SAVE AREA

•

Body of the Application Program

•

EXIT

15,RETCOD

SET RETURN CODE (OR SET TO ZERO)

13,4(13)

GET DB2 Server for VSE SAVE AREA

14,12(13)

GET DB2 Server for VSE REGISTER 14

0,12,20(13)

GET OTHER DB2 Server for VSE REGISTERS

RETURN TO DATABASE MANAGER

Figure 23. Use of an Eye-catcher by an Application Program

Notes:

1. The instruction BALR 15,0 can be used just ahead of the USING *,15 instruction

as long as other registers are not used until the DB2 Server for VSE registers

have been saved.

2. The techniques shown here work whether the application program is called by

the database manager, or is called as a job itself. Thus, the same application

program can be run in either single or multiple user mode.

3. The techniques shown here may not always be achievable by a FORTRAN, C,

COBOL, or PL/I program. A program written in one of these languages may

need to be called by a pre-entry routine, to ensure that register 15 contains a

zero (or valid return code) upon return to the database manager. A PL/I

program can use PLIRETC/PLIRETV.

Overriding Initialization Parameters

When starting the application server, you can change the default parameter values

in either of two ways:

v You can specify the parameters in the PARM field of the job control EXEC

statement or command

v You can create a DB2 Server for VSE parameter data set as an A-type source

member, and invoke it with the PARMID initialization parameter. See Figure 15

on page 50 for an example.

You can also combine the two methods. Parameters specified in the parameter data

set override the default values, while those specified with the EXEC override both

the default values and those specified in the parameter data set. Thus, a user who

has a parameter data set with an incorrect parameter value can override the error

with a correct specification on the EXEC statement or command.

When all the values of the initialization parameters have been resolved, the final

values (or defaults, if no values have been overridden) are displayed on SYSLOG,

SYSLST, or both (according to the value of the DSPLYDEV parameter).

System Administration

You can use up to 100 characters on the EXEC command for specifying parameters.

Separate each parameter by at least one comma or blank, but the commas and

blanks also count as characters. An example of specifying parameters with the

EXEC command is:

EXEC ARISQLDS,SIZE=AUTO,PARM=’DSPLYDEV=B,DUMPTYPE=F’

You can use up to three ’PARM=’ clauses of the EXEC statement for specifying

parameters. Each ’PARM=’ can be up to 100 characters. If PARM=’value’ was

specified twice or three times, the values are concatenated according to their

sequence.

As an option, you may choose to set up your initialization parameters in one or

more A-type source members. Such an arrangement allows you to specify more

user parameters (if any) when running application programs in single user mode.

User parameters (those for the application program itself), cannot be specified in a

source member, and must be specified in the PARM field of the job control EXEC

statement or command. If you plan to use application program parameters, refer to

“Specifying User Parameters” on page 73.

Creating a Parameter Data Set

You can store various parameters in A-type source members. You can have as

many A-type source members as you need. Each one can start the application

server for a slightly different environment. To use the parameters, specify the

member name in the PARMID initialization parameter. Figure 24 shows an

example of a job that catalogs a source member.

// JOB CATALPRM

// EXEC LIBR

ACCESS SUBLIB=LIBRARY.SUBLIB

CATALOG PARMXMPL.A

DBNAME=SQLDB1_NEWYORK_INV,RMTUSERS=50,

DSPLYDEV=B,NDIRBUF=20,SYSMODE=S,

PROGNAME=USERPROG,NPAGBUF=20,

DUMPTYPE=F

COMMENT - FULL PARTITION DUMP

NCSCANS=20

Figure 24. Job to Catalog a Source Member

The rules for specifying parameters in a member are a little different from those

specifying parameters in the job control. In particular:

v The parameters must be in uppercase in a parameter file.

v A blank after a parameter ends the processing of the line, so do not put a blank

between parameters -- anything on the line after the first blank will be ignored.

You can, however, use blanks to put comments in the member, as shown for the

DUMPTYPE parameter in Figure 24.

v A comma at the end of a line is not required, but can make the statement easier

to read.

v User parameters (those destined for the application program itself), are not

allowed in a member containing DB2 Server for VSE initialization parameters. If

the database manager detects any parameters other than its own initialization

parameters, it issues error messages and stops.

Chapter 4. Planning for Operation of the Database Manager

Stopping the Application Server

This section discusses the following topics:

v Taking an archive

v Verifying the directory

v Online support considerations

In single user mode, the application server stops itself when the task is completed.

In multiple user mode, the operator stops it by issuing the SQLEND operator

command. In both modes, the database files and the trace file (if active) are closed.

The SQLEND command is described in the DB2 Server for VSE & VM Operation

manual.

The SQLEND command can be entered from the VSE system operator console

only. Its format is shown in Figure 25. The ARCHIVE, LARCHIVE, and

UARCHIVE parameters are used to initiate archive activities after the database has

been shut down, and are discussed in the next section. The NORMAL parameter is

used to shut down the database when all work in progress is completed. The

QUICK parameter is used to stop all work in progress and shut down

immediately. The TRCPURGE parameter is used if you want to purge the contents

of the trace buffer at DB2 Server for VSE shut down. You can also specify the

DVERIFY parameter to do a directory verification.

NORMAL

►►

SQLEND

►◄

DB2 Server for VSE System Administration (Version 7 Release 5) - page 2