Using DB2/400 effectively
© Logicalis Group
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
Visual Basic
program using
ODBC
RPG program
in batch job
RPG program
in interactive
job
Database
file
YWRKF
DFU
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
Parent
key
Order headers
Dependent file
ORHNBR
PK
Order details
FK
ORHNBR
Compare Synon/2
OWNED BY and REFERS TO
relationships
CUSNAM
Parent file
Foreign
key
CUSNBR
Parent file
Dependent file
PRDNBR
...
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
Old record null map offset
Library name
Old record null map length
Member name
New record offset
‘1’=insert, ‘2’=delete, ‘3’=update
New record length
‘1’=before, ‘2’=after
New record null map offset
commitment control status
New record null map length
CCSID
Old record image
Old record offset
Old record null map
Old record length
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 C
System B
• Commitment control with DDM
• SQL: Distributed Unit of Work