Standards and procedures for database systems

You must develop standards and procedures for your database system.

Adequate standards and procedures improve:

• The quality of application systems, because setting up and following standards and procedures gives you greater control over your entire application development process
• The productivity in application and database design, because guidelines for design decisions exist
• The productivity of application coding, because coding standards and procedures exist
• The communication between you and application developers, because you each have clearly defined responsibilities
• The reliability and recoverability in operations, because you have clear and well-understood operating procedures

You must set up and test procedures and standards for database design, application development, application programs' use of the database, application design, and for batch operation. These standards are guidelines that change when installation requirements change.

You can establish standard practices for the following aspects of database design:

• Database structure and segmentation
  • Number of segments within a database
  • Placement of segments
  • Size of segments
  • Use of variable-length segments
  • When to use segment edit/compression
  • When to use secondary data set groups
  • Number of databases within an application
  • When and how to use field-level sensitivity
  • Database size
• Access methods
  • When to use HISAM
  • Choice of record size for HISAM
  • HISAM organization using VSAM
  • When to use GSAM
  • Use of physical child/physical twin pointers
  • Use of twin backward pointers
  • Use of child last pointers
  • HIDAM or PHIDAM index organization using VSAM
  • HIDAM or PHIDAM pointer options at the root level
  • Sequencing twin chains
  • Use of HD free space
  • When to use HDAM or PHDAM
  • Processing an HDAM or a PHDAM database sequentially
  • Use of the byte limit count for HDAM or PHDAM
  • Use of twin backward pointer for HDAM or PHDAM roots
  • Use of free space with HDAM or PHDAM
  • When to use DEDBs
  • Processing DEDBs sequentially
  • Use of DEDB parameters
  • Use of subset pointers
  • Use of multiple area data sets
• Secondary indexing
  • For sequential processing
  • On volatile segments
  • In HISAM databases
  • Use of unique secondary indexes
  • Use of sparse indexing
  • Processing of the secondary index as a separate database
• Logical relationships
  • Use of direct pointers versus symbolic pointers
  • Avoidance of long logical twin chains
  • Sequencing of the logical twin chain
  • Placement of the real logical child segment

You can also establish standards for the ways in which application programs use the database, for example:

• Requiring update and read functions to be in separate programs
• How many transaction types to allow per application program
• When applications are to issue a deliberate abnormal termination and the range of abend codes that is permitted to applications
• Whether application programs are permitted to issue messages to the master terminal
• The method of referencing data in the IOAREA, and referencing IMS variables (such as PCBs and SSAs)
• Use of predefined structures, such as PCB masks, SSAs, or database segment formats, by applications
• Use of GU calls to the message queue
• Re-usability of MPP and BMP programs
• Use of qualified calls and SSAs
• Use of path calls
• Use of the CHANGE call
• Use of the system calls: PURG, LOG, STAT, SNAP, GCMD, and CMD

Establish procedures to govern the following aspects of application design:

• The interaction between you and the application designer
• Use of the dictionary or COPY or STRUCTURE libraries for data elements and structures
• The requirement of design reviews and inspections

For operations, consider developing:

• Procedures to limit access to computer facilities
• A control point, to ensure that:
  • Jobs contain complete and proper submittal documentation
  • Jobs are executed successfully on schedule
  • Correct input and output volumes are used, and output is properly distributed
  • Test programs are executed only in accordance with a defined test plan
  • An incident report is maintained to ensure that all problems are recorded and reported to the responsible parties
• Normal operating procedures, including operations schedules, procedures for cold start, warm start, and shutdown, and scheduling and execution of batch programs.
• Procedures for emergency situations. During an emergency, the environment is one of stress. Documented procedures provide step-by-step guidance to resolve such situations. Include procedures for emergency restart, database backout, database recovery, log recovery, and batch program restart.
• A master terminal operator's guide for the installation. This guide should be supplemented by IMS Version 14 Operations and Automation.
• A master operations log. This log could contain a record of system availability, time and type of failure, cause of the failure, recovery steps taken, and type of system termination if normal.
• A system maintenance log. This log could contain a record of all release and modification levels, release dependencies, program temporary fixes (PTFs) applied, the status of APARs and date submitted, and bypass solutions.