DSNTIJUZ - installing dsnzparm

DSNTIJUZ

DSNTIJUZ is the IBM supplied jcl used to update / install DSNZPARM.DSNTIJUZ usually resides in SDSNSAMP.We use Clist/rexx while installing (SDSNCLIST) .

Always recommended to use same DSNTIJUZ each time to avoid change in values or discrepancies.

Zparms resides on system libraries, so we need external tools or ibm supplied clist/rexx (DSNZWP) to view existing system parameters in system.

DB2 uses zparm as complied load modules.

Dynamic update

Print existing DSNZPARM

Ø  Confirm with customer whether its dynamic or permanent change

Ø  If it is dynamic update DSNZPARM jcl with new parameters.Update DSNZPARM name as well

Ø  Submit jcl

Ø  Issue set command to make new zparm name

-SET SYSPARM LOAD(newzparm)

Ø  Print current DSNZPARM,verify updated system parameters.

Permanent Change

Ø  Check dynamic or permanent change and its feasibility

Ø  Print current DSNZPARM

Ø  Edit DSNTIJUZ jcl for changes in parameters

Ø  Bring down DB2 subsystem

Ø  Submit DSNTIJUZ jcl

Ø  While submitting DSNTIJUZ we will get RC=0 eventough DB2 is up.SO ensure to stop DB2 before submitting DSNTIJUZ.

Ø  Bring up DB2 subsystem

Ø  Print DSNZPARM and verify changes.

Commands

-SET SYSPARM LOAD(newzparm)

            Used to update DSNZPARM

-SET SYSPARM STARTUP

            Update existing permanent DSNZPARM, which was there during startup.

Online Updateable List

You would find the complete list of parameters in the Installation and Migration manual.

DB2 SYSTEM CONFIGURATION PARAMERTERS - DSNZPARM

DSNZPARM Dissected

What isDSNZPARM

Dataonly,subsystemparameterloadmodulecontainingtheDB2execution-timeparameters

InitiallysetatinstalltimethroughtheinstallationISPFpanels

Includesmacros:

o   DSN6ARVP–Archivedatasetparameters

o   DSN6ENV– DB2environmentsettings(removed)

o   DSN6FAC– DDF

o   DSN6LOGP–Logstuff

o   DSN6SPRM– InitializationparametersforDBM1

o   DSN6SYSP–Miscellaneoussystemparameters

o   DSN6GRP–Groupstufffordatasharing

Install DSNZPARM

SomeDSNZPARMsaresetoutsidetheinstallpanels

o   Hidden

§  Justwhattheword implies,theyareburiedwithinthemacros and notintended tobemodified bythegeneralpublic .IBM intervention needed to change those.

o   Opaque

§  Arenotavailableforchangeusingthepanels

o   Visible

§  Changedusingtheinstallpanels

DSNZPARM Values

Default values (recommended) / Minimum  values / Maximum values

Updating DSNZPARM

Ø  Permanent change

o   Need to recycle DB2 .

o   Changes will be permanent and will get updated in SDSNLOAD

o   New ZPARM name is recommended for each change

Ø  Temporary Change

o   Its Dynamic change – No need to recycle DB2

o   Not all values can be updated dynamically

o   Change will get rolled back , post recycle of DB2.

Datasharing

Multiple database shares common buffers and objects.

Log Range sequence number(LRSN)  used while logging .

LRSN = RBA+Timer

DB2 system component Architecture

Ø  Catalog tables

Ø  Directory

Ø  Logs

Ø  BSDS

Catalog tables

o   We used to have more than 120+ tables in a system

o   Each tables have specific functions

o   We need system Authority (SYSADM/DBADM) to use catalog tables

System tables

Maintains high level information about tables, table owners, schema, created date, respective  Table spaces,DB,Any existing foreign key. While querying tables we use schema names, since we are using logical objects.

SYSIBM.SYSTABLES

SYSIBM.SYSTABLESPACES

SYSIBM.SYSDATABASES

SYSIBM.SYSCOPY

SYSIBM.SYSUSERALL

SYSIBM.PLANS

ETC..,

Directory blocks

We use less than 10 blocks

Non accessible using SQL

To access IBM supplied rexx required.

SKCT01                 -              pkg table

SKPT01                 -              Plan table

SYSLRGX              -              stores information about compiled plan/pkgs including access paths

SYSUTILX             -              Have entry of utilities which we run on a system

Note : Commited work units only will be available in SYSCATALOG / DIRECTORY

LOGS

Logs will have entries with timestamps and RBA value for each entry mainly used for recovery

LOG STATUS

ACTIVE                                 -              in use

Archieve              -              offloading(old logs)

Archieve logs will reside in tapes often , depends on cost factor of shops.

Active logs must reside in DASD,to enable fast access.we can 32 active log dataset to a DB.

Dual Copy

                Each active log dataset will have a backup copy for the datace redundancy.Having a backup of existing datasets.

We can use force offload command to make active to archive logs.

Jobs should commit or offloading will not take place.So all active queries should comit before offloading.

BSDS

Boot Strap Data Set

·         Inventory of logs

·         It holds details about RBA range the archieve log datasets archieved.

·         We can use DSNJU004 to get information about logs.Its a separate physical datasets.

HLQ.BSDS01

HLQ.BSDS02                      

Utilities

·         Online utilities

·         Offline utilities (stand alone utilities)

Utilities will be provided by  IBM as well as different vendors .

DSNSPAS

DB2 Stored Procedure address Space

  Ø  Available prior to DB2-V9

  Ø  Used to process stored procedure

  Ø  Facilititres independent environment for stored procedure

  Ø  V9 and later we have WLM concept

DSNDIST

  Ø  Distributed Data Facility – DDF

     Ø  Distributed environment provides flexibility to access data located at different sites.

     Ø  Services data requests than come from DRDA(Distributed relational DB architecture)

     Ø  Optional address space – Required when distributed DB functionality required

Allied Address space

  Ø  Reponsible for handling global lock requests

  Ø  Requests to read from group buffer spool

  Ø  Available in datasharing environment

DSNIRLM

Inter Resource lock Manager   

     Ø  Manages locks

     Ø  Controlling access to DB Resources

     Ø  Serialization

     Ø  Isolating Data

DSNDBM1

  

•     Database service address space / ReadIN-writeIN / Physical component
•     Database services which is responsible for managing Physical structure of DB.
•     Handles SQL related queries
•     Core logic of DB2
•     Update SYSLGRNX/Interaction with coupling facility 

   

Buffer Spool management

•   Relational Data system (RDS)
•   Data Manager (DM)
•   Buffer Manager (BM)

Relational Data System

o   SQL Compiler (compiles all SQL)

o   Runtime Executor

o   Catalog services

o   Manages Objects

Data Manager

o   DB2 Engine

o   Makes requests to get/create/alter data

o   Invokes buffer manager

o   Interface with IRLM

Buffer Manager

o   Access Physical data for data manager / Index Manager

o   Searches for page in Buffer spool , if there is no page then VSAM media manager to return from DASD

DSNMSTR

SYSTEM Service component/ System service address space / Thread Factory

Ø  Controls connection to other MVS subsystem

Ø  Handles/Initiates system startup and shutdown

Ø  Handles Operator communication

Ø  Manages system Log  and archiving logs

Ø  Thread Creation /termination (Thread factory)

Ø  Manages DSNZPARM

Ø  Initial level authority

Ø  Supports recovery management

System Architecture

DB2 Address spaces

Ø DSNMSTR
Ø DSNDBM1
Ø DSNDIST
Ø DSNIRLM
Ø DSN-ALLIED

Version - chronology

Here we see each version/release of DB2 in its thirty year history, along with its date of general availability. The other two columns, EoM and EoS, are end-of-marketing and end-of-service dates. An EoM date means that IBM will no longer sell that version of DB2 as of that date; EoS means that IBM will no longer officially support that version of DB2 as of that date. 

Version	GA	EoM	EoS		SKIP	Code
1.1	1985-04-02			No Skip Level		ASCII/EBCID
1.2	1986-03-07			No Skip Level		ASCII/EBCID
1.3	1987-06-26			No Skip Level		ASCII/EBCID
2.1	1988-09-23			No Skip Level		ASCII/EBCID
2.2	1989-09-22			No Skip Level		ASCII/EBCID
2.3	1991-10-25			No Skip Level		ASCII/EBCID
3	1993-12-17	1999-11-30		SKIP Level		ASCII/EBCID
4	1995-10-30	2000-12-01		SKIP Level		ASCII/EBCID
5	1997-06-27	2001-12-31	2002-12-31	SKIP Level		ASCII/EBCID
6	1999-06-15	2002-06-30	2005-06-30	SKIP Level		ASCII/EBCID
7	2001-03-30	2007-03-05	2008-03-30	SKIP Level		ASCII/EBCID
8	2004-03-26	2009-09-08	2012-04-30	SKIP Level Mode level		UNICODE/ASCII/EBCID
9	2007-03-06	2012-12-10	2014-06-27	SKIP Level Mode level		UNICODE/ASCII/EBCID
10	2010-10-22	2015-07-06	2017-09-30	SKIP Level Mode level		UNICODE/ASCII/EBCID
11	2013-10-25			SKIP Level Mode level		UNICODE/ASCII/EBCID
12				No SKIP / No Mode		UNICODE/ASCII/EBCID

From DB2 V8 unicode has been introduced to avoid ASCII/EBCID . Also Mode level in upgradation introduced.

CM      -           Compatabilty Mode

ENFM  -           Enable new function mode

NFM    -           New Function Mode

DB2V9 catmaint can run on ENFM .We can fall back from ENFM to CM

V10 -> V11 –> V12 allowed

V10 -> V12 Not allowed