Introduction to Database Processing

In general, database processing is transaction oriented. Even batch jobs should be pseudo-transactional to allow for checkpointing. An application program accesses one or more database records for each transaction it processes. There are two basic types of DL/I application programs:

• Direct access programs

• Sequential access programs

A direct access program accesses, for every input transaction, segments in one or more database records. These accesses are based on database record and segment identification. This identification is essentially derived from the transaction input and is normally the root-key value and additional (key) field values of dependent segments. For more complex transactions, segments can be accessed in several DL/I databases concurrently.

A sequential access program accesses sequentially selected segments of all of a consecutive subset of a particular database. The sequence is usually determined by the key of the root segment. A sequential access program can also access other databases, but those accesses are direct, unless the root keys of both databases are the same.

A DL/I application program normally processes only particular segments of the DL/I databases. The portion that a given program processes is called an application data structure. This application data structure is defined in the program specification block (PSB). An application data structure always consists of one or more hierarchical data structures, each of which is derived from a DL/I physical or logical database.

At execution time, each application program uses one PSB and it is usually a different PSB than those used by other application programs.

Application Programming Interfaces to IMS

During initialization, both the application program and its associated PSB are loaded from their respective libraries by the IMS system The DL/I modules, which reside together with the application program in one region, interpret and execute database call requests issued by the program.

Calls to DL/I

A call request is composed of a CALL statement with an argument list. The argument list specifies the processing function to be performed, the hierarchic path to the segment to be accessed, and the segment occurrence of that segment. One segment can be operated upon with a single DL/I call. However, a single call never returns more than one occurrence of one segment type.

The arguments contained within any DL/I call request are defined in "Calls to IMS" on page 227. The following code is a sample basic CALL statement for COBOL:

 CALL 'CBLTDLI' USING function,PCB-name,I/O Area, SSA1,...SSAn. 

Table 15-1 describes some of the components of the CALL statement: the basic DL/I call functions to request DL/I database services.

Table 15-1. Basic DL/I Call Function and Descriptions

Database Service Request	DL/I Call Function
GET UNIQUE	[a]
GET NEXT	GN[a]
GET HOLD UNIQUE	GHU [a]
GET HOLD NEXT	GHN[a]
INSERT	'ISRT'
DELETE	'DLET'
REPLACE	'REPL'

^[a] indicates a blank. Each call function is always four characters.

The DL/I calls listed in Table 15-1 fall into four segment access categories. Table 15-2 describes these categories.

Table 15-2. Segment Access Categories

Segment Access Category	DL/I Call Function
Retrieve a segment	'GU[a]' 'GN' 'GHU' 'GHN'
Replace (update) a segment	'REPL'
Delete a segment	'DLET'
Insert (add) a segment	'ISRT'

^[a] indicates a blank. Each call function is always four characters.

In addition to the database calls listed in Table 15-1 and Table 15-2, there are also system service calls. System service calls are used to request system services such as checkpoints and restarts. All the calls in Table 15-1 and Table 15-2 are discussed in detail in the following sections.

Segment Search Arguments (SSAs)

For each segment accessed in a hierarchical path, one segment search argument (SSA) can be provided. The purpose of the SSA is to identify by segment name and, optionally, by field value the segment to be accessed.

The basic function of the SSA permits the application program to apply three different kinds of logic to a call:

• Narrow the field of search to a particular segment type, or to a particular segment occurrence.

• Request that either one segment or a path of segments be processed.

• Alter DL/I's position in the database for a subsequent call.

SSA names represent the fourth (fifth for PL/I) through last arguments (SSA1 through SSAn) in the call statement. There can be zero or one SSA per level, and, because DL/I permits a maximum of 15 levels per database, a call can contain from zero to 15 SSA names. In the code examples in this section, an SSA consists of one, two, or three of the following elements:

• Segment name: The segment name must be eight bytes long, left-justified with trailing blanks required. The segment name is the name of the segment as defined in a physical or logical DBD that is referenced in the PCB for an application program.

• Command codes: The command codes are optional and provide functional variations to be applied to the call for that segment type. An asterisk (*) following the segment name indicates the presence of one or more command codes. A blank or a left parenthesis is the ending delimiter for command codes. A blank is used when no qualification statement exists. For more information, see "Calls with Command Codes" on page 255.

• Qualification statement: The presence of a qualification statement is indicated by a left parenthesis following the segment name or, if present, command codes. The qualification statement consists of a field name, a relational operator, and a comparative value. The qualification statement consists of the following elements:

  - Start of qualification statement character: A left parenthesis indicates the beginning of a qualification statement. If the SSA is unqualified, the eight-byte segment name or, if used, the command codes should be followed by a blank.
  
  

  - Field name: The field name is the name of a field that appears in the description of the specified segment type in the DBD. The name is up to eight characters long, left-justified with trailing blanks as required. The named field can be either the key field or any data field within a segment. The field name is used for searching the database and must have been defined in the physical DBD.
  
  

  - Relational operator: The relational operator is a set of two characters which express the manner in which the contents of the field, referred to by the field name, are to be tested against the comparative value. See Table 15-3 on page 245 for a list of the possible values for the relational operator.
  
  

  Table 15-3. Relational Operator Values^[a]

  Operator	Meaning
  ''= or 'EQ'	Must be equal to
  '>=' or 'GE'	Must be greater than or equal to
  '<=' or 'LE'	Must be less than or equal to
  '>' or 'GT'	Must be greater than
  '<' or 'LT'	Must be less than
  '<>' or 'NE'	Must be not equal to

  
  

  ^[a] represents a blank character.

  - Comparative value: The comparative value is the value against which the content of the field, referred to by the field name, is tested. The length of the comparative value field must be equal to the length of the named field in the segment of the database. That is, the length includes leading or trailing blanks (for alphanumeric fields) or zeros (usually needed for numeric fields) as required. DL/I performs a collating sequence comparison, not an arithmetic comparison.

  - End of qualification statement character: A right parenthesis indicates the end of the qualification statement.

Qualification of SSAs

Just as calls are qualified by the presence of an SSA, SSAs are categorized as either qualified or unqualified, depending on the presence or absence of a qualification statement. Command codes can be included in or omitted from either qualified or unqualified SSAs.

In its simplest form, an SSA is unqualified and consists only of the name of a specific segment type as defined in the DBD. In this simple form, the SSA provides DL/I with enough information to define the segment type required by the call. In the following example, the last character is a blank, which indicates the SSA is unqualified:

 SEGNAME 

Qualified SSAs, which are optional, contain a qualification statement composed of three parts:

• A field name that is defined in the DBD

• A relational operator

• A comparative value

DL/I uses the information in the qualification statement to test the value of the segment's key or data fields within the database, and thus to determine whether the segment meets the user's specifications. Using this approach, DL/I performs the database segment searching. The program need process only those segments that precisely meet some logical criteria. For example:

 SEGNAME(fieldxxx>=value) 

The qualification statement test is terminated either when the test is satisfied by an occurrence of the segment type, or when DL/I determines that the request cannot be satisfied.

Command Codes in SSAs

Both unqualified and qualified SSAs can contain one or more optional command codes which specify functional variations applicable to the call function or the segment qualification. For more information about command codes, see "Calls with Command Codes" on page 255.

General Characteristics of SSAs

General characteristics of segment search arguments:

• An SSA can consist of the segment name only (unqualified). It can optionally also include one or more command codes and a qualification statement.

• SSAs following the first SSA must proceed down the hierarchical path. Not all SSAs in the hierarchical path need to be specified because there might be missing levels in the path. However, IBM strongly recommends that you always include SSAs for every segment level.

Examples of SSAs are given with the sample calls at each DL/I call discussion in "Processing a Single Database Record."