© Logicalis Group

Using DB2/400 effectively

Data integrity facilities

Traditional iSeries database usage

Applications are responsible for data integrity

Back door access possible

Defensive coding required

Data integrity built in

Application may assume data integrity

Code is smaller

Data cannot be corrupted ... assuming correct database design

Changes to database files

Databasefile

RPG programin batch job

Visual Basicprogram using

ODBC RPG programin interactive

job

DFUYWRKF

Data integrity facilities

Referential integrity forces internal consistency of the database

Order present implies customer details present

Triggers force the database to comply with local company rules

Field/record validation before database change

Additional processing after database change

Integrated Language Environment

Develop code in most suitable language(s), and in small modules, without traditional performance trade-off

Multiple activation groups within job

Commitment control in one activation group is independent of that in another

Original Program Model

Completely dynamic

Convenient

Maintainable

Slow

One entry point per program

Integrated Language Environment

Static (*PGM) or dynamic (*SRVPGM)

Calls to OPM programs supported but slow

OPM may call ILE *PGM’s main entry point only

Much, much faster than OPM

Referential constraints

Customer file CUSNBR CUSNAM . . .

Order headers ORHNBR CUSNBR

Order details ORHNBR PRDNBR

Parentkey Foreign

key

PK

FK

Compare Synon/2OWNED BY and REFERS TOrelationships

Parent file

Dependent file

Parent file

Dependent file

Referential constraints: types

RESTRICT (update or delete)

CASCADE (delete)

NO ACTION (update or delete: *BEFORE trigger is invoked, but database is not updated)

SET DEFAULT (delete)

SET NULL (delete)

Referential constraints:when the checks are made

Delete from parent file

Update to parent file (where constrained key is being updated) or to dependent file

Insert into dependent file

Referential constraints: journalling and access paths

RESTRICT does not require journalling

For all other rules

parent and dependent files must be journalled to the same journal

implicit commitment control is started

Constraint access paths are created

May share existing access paths

Referential constraints: primary and unique keys

Physical file with UNIQUE access path specified in its DDS has a primary key (Synon/2 KNOWN BY) for use as a parent key

All other parent keys are called unique keys

For consistency with other DBMS

Referential constraints: implementation

ADDPFCST or SQL ALTER TABLE

Not in DDS, so change control implications

May sometimes want to disable constraints temporarily (CHGPFCST)

integrity is automatically verified when constraint is re-enabled

Display via DSPFD, DSPDBR

Referential constraints:re-establishing

Verification of constraints follows e.g. any restore of a constrained file

Verification failure results in check pending status

EDTCPCST (also appears at manual IPL) to display check pending constraints across the system

Disable constraint, fix records, re-enable

Triggers

ADDPFTRG command (or via SQL), not in DDS

Program written in any language and passed a trigger buffer

No data may be returned by the trigger, only ‘OK’ or ‘Error’

Runs synchronously within your job: *LIBL, QTEMP, may share existing open data paths

Not invoked by APYJRNCHG

Record level, not field level

Triggers: types

*INSERT, *UPDATE, *DELETE

*BEFORE, *AFTER

Update trigger may be *ALWAYS or *CHANGE

Trigger buffer

File name

Library name

Member name

‘1’=insert, ‘2’=delete, ‘3’=update

‘1’=before, ‘2’=after

commitment control status

CCSID

Old record offset

Old record length

Old record null map offset

Old record null map length

New record offset

New record length

New record null map offset

New record null map length

Old record image

Old record null map

New record image

New record null map

Trigger feedback

*BEFORE triggers indicate problems by sending escape messages (QMHSNDPM API). I/O operation then fails, which sets activating program’s error indicator

The same happens if the trigger itself fails

Specific exception returned cannot be picked up by activating program - need standard for e.g. use of *LDA to communicate details of problem

Exceptions returned by *AFTER triggers are ignored

Triggers and data integrity

Trigger may not change the record that activated it

Either

share existing commitment control definition and do not COMMIT or ROLLBACK, or

start trigger’s own commitment control definition and be sure to COMMIT or ROLLBACK

If only trigger has commitment control, trigger must be run in a separate ILE activation group, so that immediate rollback occurs if the trigger fails

Additional SQL capability

ALTER TABLE

System-wide catalog:

SYSTABLES, SYSCOLUMNS

Describes all PFs, whether or not in SQL collections

Auxiliary storage implications

Two-phase commit

System A,running application

System B

System C

• Commitment control with DDM• SQL: Distributed Unit of Work