Natural-Adabas

Adabas Security

2006-06-20T06:53:00.000-07:00

ADABAS SECURITY
ADABAS provides the following facilities to prevent unauthorized access to and/or updating of ADABAS database files:
ADABAS Data Encryption (ciphering) which provides data security;
ADABAS Multiclient Files to control access to records in a file;
ADABAS SECURITY and the related security utility ADASCR, a selectable unit, which provides selective user access/update protection at a file, field, and field value level; and
ADABAS EXTERNAL SECURITY INTERFACE (ADAESI), a selectable unit, which
provides control of ADABAS resources at a database/utility, command, or file level through the widely used non-Software AG security packages RACF, CA–ACF2 and CA–TOP–SECRET.
ADAESI is available for MVS/ESA and OS IV/F4 (FACOM) only.
Security is accomplished by comparing passwords and authorization levels.
Data Encryption
Data encryption is an integral feature of ADABAS and requires no options or extra modules.
Data may be enciphered before being placed in the database. The user must provide the cipher key at the time records are stored. This key is not stored and must be available to request or decipher the data. This minimizes the chances that data encryption can be compromised if unauthorized access to the system occurs.
To retain maximum control over cipher codes, an ADABAS user exit program can be created to insert the currently valid cipher code into user applications; this removes the need to make the codes known to users, and protects the file from corruption that can occur by adding data that is encrypted with the wrong cipher code.
Multiclient Files
Also available as an integral feature of ADABAS that requires no options or special modules is the multiclient file.
A single ADABAS physical file defined as “multiclient” can store records for multiple users or groups of users. The multiclient feature divides the physical file into multiple logical files by attaching an internal owner ID to each record.
The owner ID is assigned to a user ID. A user ID can have only one owner ID, but an owner ID can belong to more than one user. Each user can access only the subset of records that is associated with the user’s owner ID.
Note:
For any installed external security package such as RACF or CA-TOP SECRET, a user is still identified by either NATURAL ETID or LOGON ID.
All database requests to multiclient files are handled by the ADABAS nucleus.
ADABAS SECURITY and ADASCR
Access/update control is available only with ADABAS SECURITY and the related security utility ADASCR that defines and controls ADABAS SECURITY functions.
ADABAS SECURITY provides two types of access/update protection:
􀀀 “Access-/update-level” protection applies a basic level of security on a file-by-file basis.
Access/update protection can be defined for some files and not for others. It restricts use of a file or field within the file to those having an appropriate access/update profile definition and a password specified by the user of the file.
Access/update permission values ranging from 0 to 14 are defined for each user and attached to that user’s password, and each protected file (and selected field or fields, if desired) has equivalent access/update “threshold” protection values of the same range. Only a user whose permission value equals or is greater than the protection level of the specified file (and, when applicable, field) is permitted to perform that operation type (access or update) on the file or field. An access/update permission level of 0 only allows access/update of unprotected files or fields with protection level 0 or no defined protection password.
ADABAS Security
􀀀 “Value-level” protection applies restrictions on the type and range of values that can be accessed or updated in specific fields. The restrictions are applied according to user password (files with fields using value-level protection must be password-protected), can be for specific values or for value ranges, and can be either “accept” or “reject” criteria.
ADABAS EXTERNAL SECURITY INTERFACE
(ADAESI)
ADAESI allows the definition and protection of ADABAS resources using standard external (i.e., non-Software AG) security packages such as CA-ACF2, CA-TOP SECRET, and RACF installed on ADABAS systems running under MVS/ESA and OS IV/F4 (FACOM).
Generally, a security package allows the system administrator to authorize a user’s access to system resources. The security package then monitors all users and their resource usage to ensure that no unauthorized access or change occurs. Attempts by unauthorized users to use either the system or specific system resources are recorded and reported.
A user profile, which can be for a single user or a group of users, defines which system hardware and software resources a user is allowed to use. A resource profile defines access/update privileges for one or more devices, volumes, and/or programs (resources that must be used together to perform certain functions can be defined together in the same profile). When a user logs on to the system, the security package uses the user’s logon ID to identify that user’s profile. Each time the user attempts to perform a task or access information, the security package uses information in its resource profiles to allow or deny access. Using the profile
concept, the security package expands the single point of authorization—the logon ID—to provide extensive control over all system resources. ADAESI extends the ability of the related security packages to include the ADABAS database and users. Using ADAESI, the security packages can define and control access to the following
ADABAS resources: database nucleus; database files; database commands; utilities
(MODE=MULTI only); and ADABAS operator commands issued from an MVS console.

Related Security Options
ADABAS ONLINE SYSTEM/Basic Services Security
The DBA facility ADABAS ONLINE SYSTEM/Basic Services also provides a security facility for restricting access to the ADABAS online facilities. Basic Services Security requires NATURAL SECURITY as a prerequisite.
The NATURAL SECURITY system provides extensive security for ADABAS/NATURAL
users. See the NATURAL SECURITY Manual for additional information.

Utilities

2006-06-20T06:34:00.000-07:00

4

ADABAS UTILITIES
Database services such as loading or deleting files are handled by an integrated set of online and
batch-mode “utilities”. Most utilities can be run in parallel with normal database activity to
preclude interruption of daily production. See the ADABAS Utilities Manual for more
information.
ADABAS utilities address initial design and load operations, backup/restore/recovery routines,
database modification routines, and audit/control/tuning procedures.
Note:
See the Optional Extensions chapter starting on page 71 for information about ADABAS
ONLINE SYSTEM/Basic Services, a menu-driven, interactive DBA tool.
Initial Design and Load Operations
ADACMP : Compress / Decompress
ADACMP COMPRESS is used to edit and compress data records to be loaded into the database
using ADALOD; ADACMP DECOMPRESS is used to decompress individual files for data
structure or field definition changes, or for use as input to non-ADABAS programs.
COMPRESS
Input
ADACMP input data must be in a sequential dataset/file. Indexed sequential and VSAM input
cannot be used. The records may be fixed, variable, or of undefined length. The maximum input
record length permitted depends on the operating system. The maximum compressed record
length is restricted by the Data Storage block size in use and the maximum compressed record
length set for the file (see the MAXRECL parameter, ADALOD utility). The input records can
be in either blocked or unblocked format.
It is possible to omit the input dataset if the parameter NUMREC=0 is supplied.
ADABAS Concepts and Facilities
The logical structure and characteristics of the data for input to COMPRESS are described with
field definitions statements (FNDEF to define fields or groups of fields; SUBFN and SUPFN
to define sub- or superfields, respectively; HYPDE, PHONDE, SUBDE, and SUPDE to define
various types of descriptors). Field definitions are used to create the ADABAS Field Definition
Table (FDT).
By default, input data records are processed in the order of the field definition statements. The
FORMAT parameter allows you to change the order of field processing or skip fields.
Processing
ADACMP COMPRESS edits and compresses the data records.
Editing includes checking each field defined with a “packed” (P) or “unpacked” (U) format to
ensure that the field value is numeric and in the correct format. Any record that contains invalid
data is written to the ADACMP error dataset and is not written to the compressed dataset.
ADABAS user exit 6 can be used to specify additional editing to be performed during ADACMP
COMPRESS processing. See the ADABAS DBA Reference Manual for information about user
exits.
Compression includes removing trailing blanks from alphanumeric fields; removing leading
zeros from numeric fields; removing trailing zeros in floating-point format fields; and packing
numeric unpacked fields. Fields with the fixed (FI) option are not compressed, and empty fields
located at the end of the record are neither stored nor compressed. Null value fields are processed
differently depending on options being used. SQL null value processing is supported.
Output
Processed data records are written out together with the file definition information to a
sequential dataset with the “variable blocked” record format. This dataset, or several such
datasets from multiple ADACMP executions, can be used as input to the ADALOD utility. The
dataset can be used as input to ADALOD even if it contains no records, meaning that no records
were provided on the input dataset or all records were rejected during editing.
The ADACMP processing report indicates the approximate amount of space required in Data
Storage for the compressed records by device type (specified with the DEVICE parameter) and
for Data Storage padding factors between 5 and 30 percent. The compression rate is computed
based on the real amount of data used as input to the compression routine.
Utilities 4
51
DECOMPRESS
ADACMP DECOMPRESS accepts as input data records from existing ADABAS files, either
directly without separate file unloading, or already unloaded with the ADAULD utility. If a file
is directly decompressed, it is unloaded without FDT information as part of the decomperssion
process, which can save time when decompressing larger files.
Direct decompression of multiclient files can be limited to records for a specific user only when
a valid owner ID (ETID parameter) is specified.
The FORMAT parameter may be used to decompress the record to a format other than that
specified by the FDT. This is particularly useful when the FDT of an existing file is to be
changed.
Processed data records are written to a sequential dataset with the “variable blocked” record
format. Rejected data records are written to the error dataset.
ADALOD : Loader
The ADALOD LOAD function loads a file into the database. Compressed records produced by
the ADACMP or ADAULD utility may be used as input.
ADALOD loads each compressed record into Data Storage, builds the Address Converter for
the file, and enters the field definitions for the file into the Field Definition Table (FDT).
ADALOD also extracts the values for all descriptors in the file together with the ISNs of all
records in which the value is present, to an intermediate dataset. This dataset is then sorted into
value/ISN sequence and entered into the Associator inverted lists.
The ADALOD UPDATE function is used to add or delete a large number of records to/from an
ADABAS file. The UPDATE function requires considerably less processing time than the
repetitive execution of the ADABAS add/delete record commands. Records to be added may
be the compressed records produced by the ADACMP or ADAULD utility. The ISNs of records
to be deleted can be provided either in an input dataset or by using control statements.
Records may be added and other records deleted during a single execution of ADALOD.
ADABAS Concepts and Facilities
ADAULD : Unload
The ADAULD utility unloads an ADABAS file. ADABAS files are unloaded to
􀀀 permit the data to be processed by a non-ADABAS program. In this case, the file must also be
decompressed after unloading using the DECOMPRESS function of the ADACMP utility.
􀀀 create one or more test files, all of which contain the same data. This procedure requires that
a file be unloaded, and then reloaded as a test file with a different file number.
􀀀 change the Field Definition Table (FDT). This requires that the file be unloaded, decompressed,
compressed using the modified field definitions, and reloaded. If the ADADBS utility is used
to add field definitions to a file, the file does not need to be unloaded first.
The sequence in which the records are unloaded may be
physical the order in which they are physically positioned within Data Storage.
logical a sequence controlled by the values of a user-specified descriptor.
ISN ascending ISN sequence.
The unloaded record output is in compressed format. The output records have the same format
as the records produced by the ADACMP utility.
Utilities
Backup / Restore / Recovery Routines
ADAPLP : Protection Log / Work Print
The ADAPLP utility prints data protection records contained on the ADABAS Work dataset or
the ADABAS data protection log. You can specify whether to print
ALL all protection records—the default
ASSO just Associator protection records
DATA just Data Storage protection records
C1 records resulting from ADABAS C1 commands
C5 records resulting from ADABAS C5 commands
EEKZ records written at completion of a nucleus buffer flush
ET records resulting from ADABAS ET commands
REPR Work dataset records used by Autorestart to repair the index
SAVO records resulting from online SAVE database/file operations
VEKZ records written at completion of update commands
The number of protection records printed can be reduced even more by specifying a file, ISN,
or RABN.
ADARAI : Recovery Aid
The ADABAS Recovery Aid utility ADARAI can be used to automate and optimize database
recovery. See also the restart/recovery information in the ADABAS Operations Manual.
ADARAI supports all ADABAS-compatible tape management systems.
The ADARAI utility prepares the recovery log files (RLOGs), lists the information contained
in the RLOGs, creates the job control statements to recover the database, and disables ADARAI
logging.
The RLOGs record the information about datasets, utility parameters, and protection logs
needed to build the recovery job control statements. There are two RLOGs: the primary file
(DDRLOGR1 or RLOGR1) and a mirror file (DDRLOGM1 or RLOGM1). The mirror file must
always exist; it can be used to recover the database if the primary file is not accessible.
ADABAS Concepts and Facilities 4
54
Information is stored on the RLOG by generations. A “generation” includes all activity between
consecutive ADASAV SAVE/RESTORE (database) and/or RESTORE GCB operations. The
first generation includes the first ADASAV SAVE/RESTORE (database) or RESTORE GCB
operation and extends to (but excludes) the second.
Minimally, the RLOG retains the number of generations specified by the MINGENS parameter
during the ADARAI PREPARE step. However, a maximum of 32 generations will be stored on
the RLOG if there is enough space available.
Systems using the Recovery Aid feature require a formatted recovery log (RLOG) dataset pair
(normal and mirrored), which must first be formatted with the ADAFRM utility and then
defined using the ADARAI utility.
ADARES : Restart
The ADARES utility performs functions related to database recovery:
􀀀 BACKOUT removes all the updates applied between two checkpoints. The checkpoints used
are normally the result of a non-synchronized checkpoint command (C1) but may also be
synchronized checkpoints. The complete database may be included in the backout process, or
backout may be limited to selected files.
􀀀 CLCOPY copies a command log dataset from disk to a sequential dataset. This function is
necessary only if dual command logging is in effect for an ADABAS session.
􀀀 COPY copies a sequential ADABAS protection log dataset. This function should be executed
if the ADABAS session in which the sequential protection log dataset was created was
terminated abnormally.
􀀀 PLCOPY copies a protection log dataset from disk to a sequential dataset. This function is
necessary only if dual protection logging is in effect for an ADABAS session.
􀀀 REGENERATE reapplies all the updates performed between two user-specified checkpoints.
The checkpoints specified may be the result of a non-synchronized checkpoint command (C1)
but may also be synchronized checkpoints. The REGENERATE function may process all files
or be limited to one or more files. It is most often used after the database (or one or more files)
has been restored to a previous status with the RESTORE or RESTONL function of the
ADASAV utility.
􀀀 REPAIR repairs one or more blocks in Data Storage that, for any reason, have become unusable.
The most recent save tape of the database and any protection log tapes created thereafter are used
as input to this function.
Utilities
ADASAV : Save / Restore Database or Files
The ADASAV utility saves and restores the contents of the database, or one or more files, to or
from a sequential dataset. ADASAV should be run as often as required for the number and size
of the files contained in the database, and the amount and type of updating. For large databases,
ADASAV functions may be run in parallel for the various disk packs on which the database is
contained.
Special ADASAV functions are available for use with the ADABAS DELTA SAVE FACILITY.
For more information, see the ADABAS DELTA SAVE FACILITY Manual.
RESTONL functions restore from a SAVE dataset created while the ADABAS nucleus was
active (that is, online); RESTORE functions restore from a SAVE dataset created while the
ADABAS nucleus was inactive (that is, offline).
RESTONL and RESTORE have the subfunctions GCB, FILES, and FMOVE:
􀀀 Without a subfunction, RESTONL and RESTORE restore entire databases.
􀀀 With the GCB subfunction, they restore the General Control Block, Associator RABNs 2–30
of the database, and specified files.
􀀀 With the FILES subfunction, they restore one or more files into an existing database to their
original RABNs.
􀀀 With the FMOVE subfunction, they restore one or more files into an existing database to any
free space, allowing changes to extent sizes.
If changes occurred during the online SAVE, the RESTONL function is followed automatically
by the RESTPLOG function. RESTPLOG applies the updates that occurred during, and
therefore were not included in, the online SAVE.
RESTPLOG is also executed following a RESTONL or RESTONL FILES function that ended
before the protection log (PLOG) updates were completely restored. RESTPLOG applies the
database updates not applied by the unsuccessful RESTONL function.
The SAVE function to save a database or one or more files may be executed while the ADABAS
nucleus is active (online) or inactive (offline). If the Recovery Aid option is active, a SAVE
database operation begins a new RLOG generation.
ADABAS Concepts and Facilities
ADASEL : Select Protection Data
The ADASEL utility selects information in the ADABAS sequential (SIBA) or dual (PLOG)
protection log. ADASEL decompresses the information and writes it to a print dataset
(DDDRUCK or DRUCK) or to a user-specified output dataset.
The protection log contains information on all updates applied to the database during a given
ADABAS session. Information selected by ADASEL can be used for auditing or as input to a
NATURAL or non-ADABAS program.
You can select before-images, after-images, or both for new, updated, and deleted records. You
can also select data written to the protection log by an ADABAS C5 command.
Database Modification Routines
ADADBS : Database Services
All ADADBS functions can also be performed using ADABAS ONLINE SYSTEM/Basic
Services. When the ADABAS Recovery Aid is active, using Basic Services is preferable for file
change operations because it writes checkpoints that are necessary for recovery operation.
ADADBS offers a variety of functions, any number of which may be performed during a single
execution of the utility.
Database Functions
The ADD function adds a new dataset to the Associator or Data Storage. The dataset to be added
may be on a device type that is the same as that currently being used or different. A maximum
of five datasets each may be assigned to the Associator and Data Storage.
The DECREASE function decreases the size of the last dataset currently being used for
Associator or Data Storage. The space to be released must be available in the Free Space Table
(FST).
The DECREASE function does not deallocate any of the specified physical extent space. To
deallocate space, you must decrease the database with the DECREASE function; save it with
ADASAV SAVE; reformat the datasets with ADAFRM; and restore the database with ADASAV.
Utilities
The INCREASE function increases the size of the last dataset currently being used for the
Associator or Data Storage. This function may be executed any number of times for the
Associator. The maximum of five Data Storage Space Tables (DSSTs) limits Data Storage
increases to four before all five Data Storage extents must be combined into a single extent with
either the REORASSO or REORDB function of the ADAORD utility.
The NEWALTS function assigns additional alternate RABN blocks for the Associator or Data
Storage. Existing alternate RABN definitions cannot be changed with NEWALTS.
Alternate RABN blocks can be used in place of RABN blocks that are physically damaged. If
ADABAS detects that a write operation is not successful, ADABAS selects an alternate block
of the same type, and the data is written to it. This alternate RABN is then used in place of the
original block for all subsequent read and write operations.
The RENAME function changes the name assigned to a (file or) database. If a file is not
specified or is specified with file number zero, the database is renamed.
File Functions
The ALLOCATE function is used to allocate a logical extent (an Address Converter, Data
Storage, Normal or Upper Index) of a specific size. The DEALLOCATE function is used to
deallocate a logical extent. Only one extent may be allocated or deallocated per ADADBS
execution.
The CHANGE function changes the standard length of an ADABAS field. No modifications to
records in Data Storage are made by this function. The user is, therefore, responsible for
preventing references to the field that would cause invalid results because of an inconsistency
between the new standard length as defined to ADABAS and the actual number of bytes
contained in the record.
The DELETE function deletes an ADABAS file from the database. The file may not be coupled.
If an ADABAS expanded file is specified, the complete expanded file (the anchor and all
component files) is deleted. This function results in the deallocation of all logical extents
assigned to the file. The released space may be used for a new file or for a new extent of an
existing file.
The DSREUSE function determines, for a specified file, whether Data Storage blocks that
become free as a result of record deletion are reused. Block reuse is originally determined when
a file is loaded into the database with the ADALOD FILE function, or when the system file is
defined with the ADADEF DEFINE function. In both cases, block reuse defaults to “YES” if
not specified.
ADABAS Concepts and Facilities
The ISNREUSE function determines, for a specified file, whether ADABAS reuses the ISN of
a deleted record for a new record. If not, each new record is assigned the next higher unused ISN.
For a specified ADABAS file that is not a system file, the MODFCB function modifies
parameters such as file padding factors for the Associator or Data Storage; maximum size of
secondary logical extent allocations for Data Storage, Normal Index, and Upper Index;
maximum compressed record length permitted; and whether a user program is allowed to
perform a file refresh operation by issuing a special E1 command.
The NEWFIELD function adds one or more fields to a specified ADABAS file that is not a
system file. The new field definition is added to the end of the Field Description Table (FDT).
NEWFIELD cannot be used to specify actual Data Storage data for the new field; the data can
be specified later using ADABAS add or update commands, or NATURAL commands.
The REFRESH function sets the file to “0” records loaded; sets the first extent for the Address
Converter, Data Storage, Normal Index, and Upper Index to “empty” status; and deallocates
other extents.
The RELEASE function releases a descriptor from descriptor status. All space currently
occupied in the Associator inverted list for this descriptor is released. The space can then be
reused for this file by reordering or by ADALOD UPDATE. No changes are made to Data
Storage.
The RENAME function changes the name assigned to a file or database. If a file is not specified
or is specified with file number zero, the database is renamed.
The RENUMBER function changes the number of an ADABAS file that is not a system file.
If the new number specified is already assigned to another file, the RENUMBER function will
not execute.
The UNCOUPLE function eliminates the coupling relationship between two files.
Other Functions
The CVOLSER function prints the ADABAS file extents that are contained on a disk volume
specified by its volume serial number.
The DELCP function deletes checkpoint information recorded up to and including a specified
date; checkpoint information recorded after the date specified is not deleted. After running
ADADBS DELCP, the remaining records are reassigned ISNs to include those ISNs made
available when the checkpoint records were deleted. The lower ISNs are assigned but the
chronological order of checkpoints is maintained.
Utilities
The OPERCOM function issues operator commands to the ADABAS nucleus. ADABAS issues
a message to the operator, confirming command execution. Only the update ADABAS nucleus
(NUC01) running in an ADASMP multiprocessing or an ADAPLEX+ nucleus cluster is allowed
to run ADABAS utilities such as ADADBS. The optional SMPID or PLXID parameter,
respectively, allows you to redirect the OPERCOM commands to another (read-only) nucleus
in the cluster for execution, just as though the command had been issued by a locally run
ADADBS OPERCOM operation.
The PRIORITY function sets or changes the ADABAS priority of a user. A user’s priority can
range from 0 (the lowest) to 255 (the highest, and the default). The priority value is added to
the operating system priority by the interregion communications mechanism. The user for
which a priority is to be set or changed is identified by the same user ID provided in the
ADABAS Control Block (OP command, Additions 1 field).
The RECOVER function recovers space allocated by rebuilding the Free Space Table (FST).
RECOVER subtracts file, DSST, and alternate RABN extents from the total available space.
The REFRESHSTATS function resets statistical values maintained by the ADABAS nucleus for
its current session. Parameters may be used to restrict the function to particular groups of
statistical values:
􀀀 ALL (the default) resets values for the combination of CMDUSAGE, COUNTERS,
FILEUSAGE, POOLUSAGE, and THREADUSAGE.
􀀀 CMDUSAGE resets the counters for ADABAS direct call commands such as Lx, Sx, or A1.
􀀀 COUNTERS resets the counter fields for local or remote, physical or logical calls, ADABAS
STAR calls, format translations, format overwrites, autorestarts, protection log switches, buffer
flushes, and command throw-backs.
􀀀 FILEUSAGE resets the count of commands for each file.
􀀀 POOLUSAGE resets the high-water marks for the nucleus pools such as the Work pool, the
Command Queue, or the User Queue.
􀀀 THREADUSAGE resets the count of commands for each ADABAS thread.
ADABAS maintains a list of the files used by each ADABAS utility in the Data Integrity Block
(DIB). The DDIB operator command (or ADABAS ONLINE SYSTEM/Basic Services)
displays this block to determine which jobs are using which files. A utility removes its entry
from the DIB when it terminates normally. If a utility terminates abnormally (for example, the
job is cancelled by the operator), the files used by that utility remain “in use”. The RESETDIB
function releases any such files and resets the DIB entries for a specified job and/or a particular
utility execution.
ADABAS Concepts and Facilities
ADADEF : Define a Database
The ADADEF utility is used to define a new database, including the Checkpoint file, or to define
a new Work file (NEWWORK function) for an existing database.
Databases are defined with name, ID, components (Associator, Data Storage, and Work) with
device type and size.
ADABAS uses certain files to store system information. The Checkpoint file is used to store
checkpoint data as well as user data provided with the ADABAS CL and ET commands. It is
required and must be specified in the ADADEF DEFINE (database) function.
Before database components (Associator, Data Storage, and Work) can be defined with
ADADEF, each must be formatted by the ADAFRM utility.
ADAFRM : Format Datasets
The ADAFRM utility formats the ADABAS direct access (DASD) datasets; that is, the
Associator, Data Storage, and Work datasets as well as the intermediate storage (Temp, Sort,
and command/dual protection/recovery logging) datasets.
Formatting with ADAFRM comprises two basic operations: creating blocks (that is, RABNs)
on the specified tracks/cylinders; and filling the created blocks with binary zeros (nulls).
Any new dataset must be formatted before it can be used by the ADABAS nucleus or an
ADABAS utility. After increasing a dataset with the ADADBS INCREASE or ADD function,
new RABNs must also be formatted.
ADAFRM also provides functions to “reset” existing Associator, Data Storage, or Work blocks
to binary zeros (nulls).
More than one ADAFRM function (ASSOFRM, DATAFRM, RLOGFRM, and so on) can be
performed in the same job. However, each function must be specified on separate statements.
Utilities
ADAINV : Invert
The ADAINV utility is used to
􀀀 create a descriptor (INVERT function); or
􀀀 couple two files (COUPLE function).
The INVERT function
􀀀 modifies the Field Definition Table (FDT) to indicate that the specified field is a descriptor; and
􀀀 adds all values and corresponding ISN lists for the field to the inverted list.
The newly defined descriptor may then be used in the same manner as any other descriptor. This
function may also be used to create a subdescriptor, superdescriptor, phonetic descriptor, or
hyperdescriptor.
The COUPLE function adds a common descriptor to two files (updates their inverted lists). Any
two files may be coupled provided that a common descriptor with identical format and length
definitions is present in both files. A single file may be coupled with up to 18 other files, but
only one coupling relationship may exist between any two files at any one time. A file may not
be coupled to itself.
Note:
Only files with numbers 255 or lower can be coupled.
Changes affecting a coupled file’s inverted lists are automatically made to the other file. The
DBA should consider the additional overhead required to update the coupling lists when the
descriptor used as the basis for coupling is updated, or when records are added to or deleted from
either file. For example, if a field used as the basis for coupling contains a large number of null
values and is not defined with the NU (null suppression) option, the result may be a significant
increase in execution time and required disk space to store the coupling lists.
An interrupted ADAINV operation can be restarted without first having to restore the file.
ADABAS Concepts and Facilities
ADAORD : Reorder
Three types of functions are available within the ADAORD utility; only one function may be
executed during a given execution of ADAORD.
Reorder Functions
The REORASSO function physically reorders all Associator blocks for all files; REORFASSO
reorders the Associator for a single file. This eliminates Associator space fragmentation, and
combines multiple Address Converter, Normal and Upper Index, and Data Storage Space Table
(DSST) component extents into a single logical extent for each component.
The REORDATA function reorders Data Storage for all files in the database; REORFDATA
reorders Data Storage for a single file. This condenses extents containing only empty blocks,
and also eliminates any Data Storage fragmentation caused by file deletion.
The REORDB function performs both the REORASSO and REORDATA functions in a single
ADAORD execution; the REORFILE function performs both the REORFASSO and
REORFDATA functions in a single ADAORD execution. The records may be reordered in the
logical sequence by a descriptor, by ISN, or in the current sequence.
Restructure Functions
The RESTURCTURE functions are used to relocate a database or specified files to a different
physical device.The RESTRUCTUREDB function unloads an entire database to a sequential dataset;
RESTRUCTUREF unloads one or more files to a sequential dataset. This dataset can be used
as input to the STORE function.
Store Function
The STORE function loads one or more files into an existing database using the output produced
by the RESTRUCTURE functions or the REORDB function.
Utilities
Audit / Control / Tuning Procedures
ADAACK : Check Address Converter
ADAACK should only be used for diagnostic purposes. It checks
􀀀 the Address Converter for a specified file(s) and ISN range. It is used in conjunction with
ADAICK.
􀀀 each Address Converter element to determine whether the Data Storage RABN is within the
used portion of the Data Storage extents specified in the File Control Block.
􀀀 the ISN for each record in each Data Storage block within the specified ISN range to ensure that
the Address Converter element for that ISN contains the correct Data Storage RABN.
ADADCK : Check Data Storage
ADADCK should only be used for diagnostic purposes. It checks the Data Storage and the Data
Storage Space Table (DSST) of a specific file (or files) in the database.
ADADCK reads each used Data Storage block (according to the Data Storage extents in the File
Control Block) and checks whether:
􀀀 the block length is within the permitted range (4 􀀀􀀀block length 􀀀􀀀physical block size).
􀀀 the sum of the lengths of all records in the Data Storage block plus 4 equals the block length.
􀀀 any record exists with a record length greater than the maximum compressed record length for
the file or with a length 􀀀􀀀0.
􀀀 any duplicate ISNs exist within one block.
􀀀 the associated DSST element contains the correct value. If not, the DSST must be repaired (see
REPAIR parameter).
ADABAS Concepts and Facilities
ADAICK : Check Index and Address Converter
ADAICK should only be used for diagnostic purposes. It checks the physical structure of the
Associator. This includes validating the index based upon the descriptor value structures and
the Associator extents defined by the General Control Block (GCB) and File Control Block
(FCB).
ADAICK can
􀀀 check index and Address Converter for specific files;
􀀀 print/dump the contents of any Associator or Data Storage block in the database; or
􀀀 produce a formatted print/dump of the contents of the GCB, FCBs, and FDTs.
ADAMER : ADAM Estimation
The ADAMER utility produces statistics that indicate the number of Data Storage accesses
required to find and read a record when using an ADAM descriptor. This information is used
to determine
􀀀 whether the number of accesses required to retrieve a record using an ADAM descriptor would
be less than the standard ADABAS accessing method;
􀀀 the amount of Data Storage space required to produce an optimum distribution of records based
on the randomization of the ADAM descriptor.
The input data for ADAMER is a dataset containing the compressed records of a file produced
by the ADACMP or ADAULD utility.
The field to be used as the ADAM descriptor is specified with the ADAMDE parameter. A
multiple value field or a field contained within a periodic group may not be used. The ISN
assigned to the record may be used instead of a descriptor as the basis for randomization
(ADAMDE=ISN).
The ADAM descriptor must contain a different value in each record, since the file cannot be
successfully loaded with the ADAM option of the ADALOD utility if duplicate values are
present for the ADAM descriptor. The ADAMER utility requires a descriptor field defined as
unique (UQ), but does not check for unique values; checking for unique descriptor values is done
by the ADALOD utility when loading the file as an ADAM file.
Utilities
The BITRANGE parameter may be used to specify that a given number of bits are to be
truncated from each ADAM descriptor value before the value is used as input to the
randomization algorithm. This permits records containing ADAM descriptor values beginning
with the same value (for example, 40643210, 40643220, 40643344) to be loaded into the same
physical block in Data Storage. This technique can be used to optimize sequential reading of
the file when using the ADAM descriptor to control the read sequence, or to remove
insignificant information such as a check digit.
ADAREP : Report
The ADAREP utility produces the database status report, which provides information
concerning the current physical layout and logical contents of the database.
The information provided in this report includes
􀀀 a database overview: the database name, number, creation date/time, file status, and current log
number.
􀀀 current space resources for Associator, Data Storage, and Work: amount and locations of
currently used space, allocated but unused space, and alternate RABN blocks.
􀀀 summary and detailed file information: summary by file of ISN, extent, padding factor,
used/unused Associator and Data Storage space, and file options; and detailed, optionally by
file, that includes all summary information plus MINISN/MAXISN settings, detailed space
information, creation and last use date/time, Field Definition Table (FDT) contents, and general
or extended Checkpoint file information.
􀀀 checkpoint information: general and extended Checkpoint file information.
􀀀 physical structure: Associator/Data Storage RABN information including device type,
VOLSER number, file number (if appropriate), and usage (AC, NI/UI, Data Storage, DSST,
alternate, or unused).
ADABAS Concepts and Facilities
ADAVAL : Validate the Database
The ADAVAL utility validates any or all files within an ADABAS database except the
Checkpoint and Security files.
ADAVAL compares the actual descriptor values contained in the records in Data Storage with
the corresponding values stored in the Associator to ensure that the Associator and Data Storage
are synchronized, and that there are no values missing from the Associator.
Before running ADAVAL, the consistency of the inverted lists should be checked with the
ADAICK utility.
ADAPRI : Print Selected ADABAS Blocks
The ADAPRI utility prints the contents of a block (or range of blocks) contained in the
Associator, Data Storage, Work, Temp, Sort, dual command log (CLOG), dual data protection
log (PLOG), the recovery log (RLOG), or the DELTA SAVE images (DSIM) dataset.

Using Adabas

2006-06-20T06:30:00.000-07:00

3
35
USING ADABAS
Generally, ADABAS uses between 10% and 50% of the data processing resources (disk storage,
CPU time, elapsed processing time) used by other database management systems. Since fewer
hardware facilities are used, more can be accomplished with less. Very large online applications
using several gigabytes of data have been successfully implemented, with thousands of terminal
workstations, and with the response times and the cost of much smaller systems.
Accessing a Database from Programs
ADABAS access is field-oriented: user programs access and retrieve only the fields they need.
User program statements invoke ADABAS search and retrieval operations automatically.
Direct Call Interface
ADABAS provides a powerful and flexible set of direct call commands for performing database
operations. ADABAS direct call commands provide a direct interface to the ADABAS database
when NATURAL or another fourth-generation database language is not being used.
The commands can be categorized by function:
􀀀 Database query
􀀀 Read (Data Storage or Associator)
􀀀 Database modification
􀀀 Logical transaction processing
􀀀 Special commands
ADABAS Concepts and Facilities 3
36
Database Query Commands (Sx)
Database query commands (S1/S4, S2, S5)) search for and return the ISNs of specified records
or record groups according to specified search criteria. Other commands in this category (S8,
S9) sort the resulting ISN lists in preparation for later operations.
The ISN lists resulting from any Sx command may be saved on the ADABAS Work dataset for
later retrieval during the user session.
In most cases, these commands do not actually read the database; ISNs are read directly from
the Associator’s inverted lists. Options allow the ISN’s record to be placed in hold status to
prevent it from being updated by other programs until the record is released; if desired,
additional field values contained in the first ISN’s record can be read from Data Storage.
Read Commands (Lx)
The L1 through L6 commands are used to read actual records from Data Storage. Depending
on the specified command and its options, records are read individually
􀀀 in the sequence in which they are stored;
􀀀 in the order of an ISN list created by one of the database query commands; or
􀀀 in logical sequence according to a user-specified descriptor.
See page 39 for more information about sequential access methods.
A hold option allows the database records to be locked until released by a separate command
or at transaction end.
The L9 and LF commands read information directly from the Associator inverted lists or File
Definition Tables (FDTs), returning either the inverted list values for a specified descriptor or
the field definitions for a specified file in the database.
Database Modification Commands (A1, E1, N1/N2)
Database modification commands (A1, E1, and N1/N2) change, delete, or add database records
and update the related Associator lists accordingly. ISNs can be assigned to new records either
by the user or by ADABAS.
The inverted lists and the Address Converter are automatically maintained by ADABAS. When
the user supplies a new value for a descriptor, either in a new record or as part of a record update,
ADABAS performs all necessary maintenance of the inverted lists. When a new record is added
or a record is deleted, the Address Converter is appropriately updated. These operations are
completely transparent to the user.
Using ADABAS 3
37
Logical Transaction Control Commands (ET/BT)
An ADABAS logical transaction defines the logical start (BT) and end (ET) of the database
operation being performed. If the user operation or ADABAS itself terminates abnormally,
these commands provide the capability for restarting a user, beginning with the last
unsuccessfully processed transaction. ET/BT commands
􀀀 define the transaction start and end;
􀀀 restore pretransaction conditions if a situation occurs that prevents successful completion of the
transaction; and
􀀀 read program-specified user data written during the transaction sequence.
Programs that use these commands are called ET logic programs. Although not required,
Software AG recommends that you use ET logic. See page 44 for more information about
transaction logic.
Special Commands
Special commands perform many of the “housekeeping” functions required for maintaining the
ADABAS database environment. Commands in this group
􀀀 open (OP) and close (CL) a user session (but do not control a transaction);
􀀀 write data protection information and checkpoints (C1, C5); and
􀀀 set (HI) and release (RI) record hold status.
In addition, the RC command releases one or more command IDs currently assigned to a user,
or deletes one or all global format IDs.
The RE command reads user data previously stored in an ADABAS system file by CL or ET
commands.
ADABAS Concepts and Facilities 3
38
Complex Searches
In many large database systems, the time required to process complex searches is often
excessive. ADABAS efficiently solves this problem. Many ADABAS applications are currently
in use with up to 150 complex selection criteria created dynamically. Data is retrieved
immediately from files with more than 50 million records.
Multifile Searching
It is often necessary to perform a multifile search in order to resolve an inquiry. Multifile
searching can be accomplished using multiple search commands, physically coupled files, or
soft file-coupling. See page 21 for information about coupled files.
Multiple search commands may be used in which a value retrieved in one command is used as
the search value for the next command. This process is not restricted to two files.
Multi-index Searching
“Fuzzy” matching (i.e., retrieving data based on similar rather than on exact search criteria)
can be implemented using hyperdescriptors. Hyperdescriptors allow multiple virtual indexes,
meaning that several different search index entries can be made for a single data field. See page
34 for information about hyperdescriptors.
Using ADABAS 3
39
Access Methods
ADABAS supports both sequential and random access methods. Different calls use different
ADABAS access paths and components; the most efficient method depends on the kind of
information you want and the number of records you need to retrieve.
Sequential Access
Physical sequence retrieves every record in a file in the order the records are stored in Data
Storage. You can limit the fields within each record for which values are to be returned. You can
also specify a “start” ISN: the sequential pass then begins at the first record physically located
after the record identified by the specified ISN.
ADABAS bypasses the Associator and goes directly to Data Storage, reading the first data block
(or the first record following a specified ISN) and continuing in consecutive sequence until the
last block is read. Physical sequence is the fastest way to process a large volume of records.
User
Program ADABAS
Nucleus
I/O Buffer
Work Area
Inverted
List
Data
Storage
Returns field values
Read
Physical
L2/L5
Address
1 Converter
4
2
3
Figure 2-9: Read in Physical Sequence (L2/L5)
ADABAS Concepts and Facilities 3
40
ISN sequence retrieves records in ISN order. ADABAS uses database query commands (Sx) to
build and sort ISN lists, which can then be read using L1/L4 commands with the GET NEXT
option. When reading, ADABAS uses the Address Converter to find the RABNs of each ISN
in the list and then reads and returns the records from Data Storage.
User
Program ADABAS
Nucleus
I/O Buffer
Work Area
(Sx ISN List)
Inverted List
Data
Storage
Returns field values
Read by ISN
Sx, L1/L4
Address
Converter
1
6
2
5
4
3
Figure 2-10: Read in ISN Sequence (L1/L4)
Logical sequence retrieves records by descriptor value. ADABAS finds the value(s) in the
inverted list, uses the Address Converter to find the RABNs of the ISNs related to the value, and
retrieves the records from Data Storage.
User
Program ADABAS
Nucleus
I/O Buffer
Work Area
Inverted
List
Data
Storage
Returns field values
Read Logical
L3/L6
Address
1 Converter
6
2
5
4
3
Figure 2-11: Read in Logical Sequence (L3/L6)
Using ADABAS 3
41
Reading in logical sequence retrieves all the records related to a single value or a range of values
of the specified descriptor. It returns the records sorted in ascending/descending order by
descriptor value, and in ascending/descending ISN order within each value. You can specify a
starting and ending value. You can also specify the field(s) for which values are returned. Read
logical is useful when you want the returned records sorted on a particular field.
ADABAS provides a special read command (L9) to determine the range of values present for
a descriptor, and the number of records that contain each value. Such a retrieval is called a
“histogram”. The L9 command does not require any access to data records, only to the inverted
lists stored in the Associator.
User
Program ADABAS
Nucleus
I/O Buffer
Work Area
Inverted
List
Data
Storage
Returns count of ISNs for each value
READ
VALUES FOR
descriptor
Address
Converter
1
4
2
3
Figure 2-12: Read Descriptor Values (L9)
Random Access
ADABAS uses the S1/S2/S4 commands to select records that satisfy a search criterion: the
count of the records found and a list of their ISNs is returned. The S1/S4 commands return the
ISNs in ascending sequence; the S2 command allows you to specify a sort sequence for the
returned ISNs.
The search criterion may comprise
􀀀 one or more fields in a single file;
􀀀 fields contained in two or more physically coupled files; or
􀀀 search, read, and internal list matching based on the soft coupling feature.
ADABAS Concepts and Facilities 3
42
A search criterion may contain one or more fields that are not defined as descriptors. If
nondescriptors are used, ADABAS performs read operations to determine which records to
return to the user. If only descriptors are used within the search criterion, ADABAS resolves the
query by using the Associator inverted lists; no read operation is required.
Random Access Using the ADABAS Direct Access Method (ADAM)
Note:
The ADAM feature is available on mainframe platforms only.
The ADABAS Direct Access Method (ADAM) improves random access performance on a
particular descriptor field in a file. ADAM uses the field value to compute the relative block
address (RABN) for record storage. The ADAM descriptor may also be used like any other
descriptor within a selection criterion, and for logical sequential processing as well. This option
may be selected for any given file when the file is loaded into the database.
Customer ID=17802
Customer–ID=
17802
Randomizer
ADAM
Data Block 1
Data Block 2
Data Block 3
Customer File
Data Storage
RABN
Figure 2-13: ADABAS Direct Access Method (ADAM)
Using ADABAS 3
43
Using Triggers and Stored Procedures
The ADABAS triggers and stored procedures facility is an integral part of ADABAS; however,
NATURAL (see page 102) and ADABAS ONLINE SYSTEM (see page 71) are required to use
the facility.
A procedure is a NATURAL subprogram that is written and tested using standard NATURAL
facilities.
􀀀 A trigger is a procedure that is executed automatically by ADABAS when a specified set of
criteria is met. The set of criteria is determined for each command sent to ADABAS and is based
on the target file number and optionally the command type and/or field. The command type
refers to the commands FIND, READ, STORE, UPDATE, and DELETE. The field must be in
the corresponding Format Buffer of the command.
􀀀 A stored procedure is executed by ADABAS, but is invoked directly by a special user call from
any of a number of applications that use it. Storing programs that are used by multiple clients
in an ADABAS file on the server reduces the amount of data traffic to and from the server.
The same types of parameters are passed to the subprogram whether it is a trigger or a stored
procedure.
The ADABAS facility for triggers and stored procedures allows you to implement and maintain
both types of procedures. It resides within ADABAS and provides an extension to an
application. It can be used to
􀀀 implement various security and auditing features for an application; and
􀀀 provide a consistent, central environment where data can be verified or manipulated, either
manually by the application or automatically by ADABAS when triggers are defined.
ADABAS Concepts and Facilities 3
44
Maintaining Database Integrity
ADABAS provides facilities to ensure the logical consistency of data in a competitive updating
environment and when a user or ADABAS session is interrupted.
Facilities are available for both online and traditional batch update. For online,
transaction-oriented processing, ADABAS ensures that the database is free of incomplete
transactions. For batch mode updating, ADABAS ensures restart in the event of failure by
providing checkpointing and backout/regeneration of updates.
Transaction Logic
ADABAS data protection, recovery, and user restart are based on the concept of a “logical
transaction”: the smallest unit of work (as defined by the user) that must be performed in its
entirety to ensure that the information contained in the database is logically consistent.
A logical transaction may comprise one or more ADABAS commands that together perform the
database read/update required to complete a logical unit of work. A logical transaction begins
with the first command that places a record in hold status and ends when an ET (end transaction),
BT (back out transaction), CL (close), or OP (open) command is issued for the same user.
The OP (open) or RE (read ET data) commands can be used to retrieve user restart data stored
by the ET or CL command. This data is also written to the ADABAS data protection log with
each checkpoint written by the transaction and can be read using the ADASEL utility.
The ET command must be issued at the end of each logical transaction. Successful execution
of an ET command ensures that all the updates performed during the transaction are physically
applied to the database, regardless of subsequent user or ADABAS session interruption.
Updates performed during transactions for which ET commands are not successfully executed
are backed out, either manually by issuing the BT command or automatically by the
Autobackout routine (see page 48).
Competitive Updating
Competitive updating is in effect when two or more users (in multiuser mode) are updating the
same ADABAS file(s). The ADABAS facilities used to ensure data integrity in a competitive
updating environment include record hold/release, avoidance of resource deadlock, and
exclusive control updating.
Using ADABAS 3
45
Record Hold and Release
The ADABAS Record Hold facility ensures that a record will not be updated by more than one
user at a time. A user can put the record in “hold” status (that is, the ISN of the record is put in
the Hold Queue) using the commands S4 (find with hold), L4/L5/L6 (read with hold), A1/E1
(update/delete) with the hold option specified, N1/N2 (add record with hold), or HI (hold
record).
If a record requested for hold status is already being held by another user or utility, the user
issuing the record hold command is put in “wait” status until the record becomes available, at
which time ADABAS reactivates the command. You may request that a response code be
returned if you do not want to be put in “wait” status.
Records in “hold” status can be accessed (found and read) by users who do not seek to hold the
record.
Records in “hold” status are released by issuing the ET or CL commands. Options are available
with ET and BT commands to release records selectively. The CL command releases all records
in “hold” status for the issuing user.
Avoiding Resource Deadlock
Resource deadlock occurs when two users are each waiting for a record held by the other user.
ADABAS protects against such a user deadlock situation by detecting the potential deadlock
and returning a response code to the second user after putting the first user in “wait” status.
Exclusive Control Updating
Users who use logical transaction commands (ET/BT) are called ET logic users.
Alternatively, a user can request exclusive control of one or more ADABAS files for the duration
of the user session. If the file or files for which exclusive control is requested are not already
opened for update by another user or utility, exclusive control is granted and the user becomes
an exclusive update (EXU) user. ADABAS treats EXU users as non-ET logic users.
ADABAS does not place an ISN in “hold” status for EXU users. ADABAS disables hold logic
processing for files being updated under exclusive file control.
Instead of using ET commands, EXU users can request checkpoints to act as reference points;
for example, updates applied after a checkpoint can be removed.
ADABAS Concepts and Facilities 3
46
Timeout Controls
ADABAS times out
􀀀 transactions that exceed a specified limit; and
􀀀 users who are inactive for a specified amount of time.
Transaction Time Limit
ADABAS provides a transaction duration time limit for ET logic users. The time limit is set with
the ADARUN TT parameter; an override for a specific user can be set using the OP command.
If a transaction exceeds the prescribed limit, ADABAS generates a BT (back out transaction)
command to remove all the updates performed during the transaction and release all held
records. The user can then either repeat the backed out transaction from the beginning or begin
another transaction.
Non-Activity Time Limit
All users are subject to a non-activity time limit; different limits can be set for different user
types and for specific users within each user type.
If a user exceeds the prescribed limit and the user is
􀀀 an ET logic user, ADABAS backs out the current transaction, releases all held records and
command IDs, and deletes the user’s file list.
􀀀 an EXU user, ADABAS deletes the user’s file list and releases all command IDs. The user loses
his EXU user status and becomes an access-only user.
􀀀 an access-only user, ADABAS deletes the user’s file list.
Using ADABAS 3
47
Backout, Recovery, and Restart
Backout, recovery, and restart may be required when a user or ADABAS session is interrupted
due to a timeout (see page 46); a program error when ADABAS determines that a transaction
cannot be completed successfully; an ADABAS, hardware, or operating system failure; or a
power failure.
A “user session” is a sequence of ADABAS calls optionally starting with an open (OP)
command and ending with a close (CL) command. A “user” is either a batch mode program or
a person using a terminal. The uniqueness of each user is assured by the user ID, a machine, an
address space, and a terminal ID.
An “ADABAS session” starts when ADABAS is activated and continues until ADABAS is
terminated. During this time, the ADABAS nucleus creates a sequence of protection entries in
exact historical sequence reflecting all modifications made in the database. The sequence of
protection entries is written to the Work dataset (part 1) and to a protection log in blocks. Each
block contains the nucleus session number, a unique block number, and a time stamp.
User Program Error
A user program that is in the middle of a transaction can detect that the transaction cannot be
completed successfully. In this case, a BT (back out transaction) command is used to remove
or “back out” the incomplete transaction.
If a user program error causes logical damage to the database, it may be necessary to recover
the affected files using the ADASAV and ADARES utilities.
ADABAS, Hardware, or Operating System Failure
After any failure that causes the ADABAS nucleus to terminate abnormally, an automatic
procedure is executed when ADABAS is reactivated to bring the database to a physically and
logically valid status. All partially executed update commands are reset; all incomplete
transactions are backed out.
The automatic procedure comprises three steps: repair the database, Autorestart, and
Autobackout.
􀀀 Database repair modifies the database to the status it would have had if a buffer flush had just
been completed at the time of failure. That is, all blocks in the database are at a status that
enables the nucleus to perform normally.
ADABAS Concepts and Facilities 3
48
􀀀 Autorestart backs out updates of single update commands that were partially executed when the
system failed. It resolves internal inconsistencies in the database and ensures physical integrity.
􀀀 Autobackout, which is performed only for ET logic users, backs out updates of user transactions
that were partially executed when the system failed. ADABAS performs an internal BT (back
out transaction) followed by Autorestart, and then informs the user that the last transaction has
been backed out.
The Autobackout routine is executed at the end of an ET session that was terminated with HALT.
It is also executed automatically at the beginning of the next ADABAS session to remove any
updates performed within transactions that did not complete successfully.
After Autobackout execution, the database contains updates only from logically complete
transactions.
Note:
ET users can manually back out an incomplete transaction at any time by issuing the BT (back
out transaction) command. See page 44.
If an ADABAS, hardware, or operating system failure results in physical damage to the
database, it may be necessary to recreate the database using the ADASAV and ADARES
utilities.
Power Failure
Depending on the hardware, a power failure during an I/O operation may damage the ADABAS
blocks that were being processed. This damage cannot be detected during Autorestart and
therefore can result in problems later such as unexpected response codes or lost database
updates.
If the ADARUN IGNDIB=YES parameter is set, the Autorestart routine checks whether a buffer
flush was active when the session interruption occurred. If a buffer flush was in process, the
Autorestart shuts down and ADABAS alerts the user to the potential problem and includes a list
of the files being updated when the buffer flush was in process. The DBA must then determine
whether a power failure occurred.
If the cause of a session interruption
􀀀 is a power failure, Software AG strongly recommends recovering the affected files using the
ADASAV and ADARES utilities.
􀀀 is definitely not a power failure and the integrity of the information on the output hardware can
be guaranteed, the database can be reactivated immediately. Database recovery is not necessary.

Design of Adabas

2006-06-20T05:47:00.000-07:00

2
13
ADABAS DESIGN
Database systems often involve complex data structures and data handling procedures that can
be designed and used only by persons with extensive knowledge and experience. ADABAS has
a remarkably simple structure by comparison, yet it provides significant advantages for
operational efficiency, ease of design, definition, and database evolution.
ADABAS Entities
In ADABAS, a “field” is the smallest logical unit of information (e.g., current salary) that may
be defined and referenced by the user. A “record” is a collection of related fields that make up
a complete unit of information (e.g., all the payroll data for a single employee). A “file” is a
group of related records that have the same format (with some exceptions; see page 23). A
“database” is a group of related files.
ADABAS Limits
The table below shows the maximum number that mainframe ADABAS supports for each
entity:
Entity Maximum
Databases 65,535
Blocks per database 2,147,483,646 using 4-byte RABNs
Files per database the lower of 5,000 or the Associator block size minus one
Records per file 4,294,967,294 using 4-byte ISNs
Fields per record 926
Uncompressed record length depends on the operating system
Compressed record length Data Storage block size
ADABAS Concepts and Facilities 2
14
ADABAS Space Management
The disk storage space allocated to a single ADABAS database is segmented into “logical”
ADABAS files. A certain part of the overall space within the database is allocated to each logical
file. When the space is filled with records from the file, ADABAS automatically allocates more
space to the file from the common free space pool. This dynamic space allocation, together with
the dynamic recovery of released space, allows ADABAS databases to run without intervention
for long periods of time.
The distribution of database space across disk drives can be controlled by “physically”
segmenting it into multiple independent datasets. When all physical database space is filled,
more datasets can be allocated dynamically, or the size of existing datasets can be increased so
that new physical files can be loaded without reorganizing the entire database.
Database Components
To support the separation of data and access structures, the ADABAS nucleus uses three
database components:
􀀀 Data Storage for compressed data
􀀀 Associator for data management and retrieval
􀀀 Work, a scratch area for complex search criteria, etc.
Data Storage
Data Storage is divided into “blocks”, each identified by a 3- or 4-byte relative ADABAS block
number or “RABN” that identifies the block’s physical location relative to the beginning of the
component. Data Storage blocks contain one or more physical records and a padding area to
absorb the expansion of records in the block.
A logical identifier stored in the first four bytes of each physical record is the only control
information stored in the data block. This internal sequence number or “ISN” uniquely identifies
each record and never changes. When a record is added, it is assigned an ISN equal to the highest
existing ISN plus one. When a record is deleted, its ISN is reused only if you instruct ADABAS
to do so. Reusing ISNs reduces system overhead during some searches and is recommended for
files with records that are frequently added and deleted.
ADABAS Design 2
15
For each file, between 0–99 percent (default 10%) of each block can be allocated as padding
based on the amount and type of updating expected. This reserved space permits records to
expand without migrating to another block and thus helps to minimize system overhead.
0071 0595 0221
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
0222
0300
0991 2021
0401 0532
RABN
1
2
3
Records (identified by ISNs) Padding Area
Figure 2–1: ADABAS Data Storage Blocks
Free Space and Space Reusage
If records become too large for their blocks, they migrate to new locations. When a record
migrates or is deleted, free space is opened in the data block between the last record and the
padding area. Figure 2–2 shows free space created when the record with ISN 0401 becomes too
large for the block and migrates to another block:
0300 0401 0533
ÉÉÉÉ
ÉÉÉÉ
Padding Area
0300 0533
ÉÉÉÉÉÉ
ÉÉÉÉÉÉ
ÉÉÉÉÉÉ
Free Space Padding Area ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
Figure 2–2: Free Data Storage Space Created by Record Migration
You can instruct ADABAS to reuse free space. Reusing space saves computer time, since
ADABAS then reads fewer physical blocks during searches. It is recommended for all files.
ADABAS Concepts and Facilities 2
16
Compression
Data compression significantly reduces the amount of storage required. It also permits the
transmission of more information per physical transfer, resulting in greater I/O efficiency.
ADABAS retains data records in compressed form. It defines and executes compression at the
field level. Three compression options are supported: default compression, null suppression,
and fixed format. The last two options are added as field options and are discussed on page 29.
“Default compression” deletes trailing blanks in alphanumeric fields and leading zeros in binary
fields. An inclusive length byte (ILB) at the beginning of the field indicates the total number
of stored bytes, including the ILB. Thus, if “Susan” is entered in a “first-name” field defined
with a 20-character length and default compression, its stored size will be six bytes: five bytes
for the letters of the name, plus one byte for the ILB. In addition, empty fields in a record are
not stored; an empty field is replaced by a one-byte empty field counter (EFC). ADABAS can
store up to 63 contiguous empty fields in a single hexadecimal byte.
Many ADABAS files require only 50% to 60% of the space used for the raw data. Even with
the addition of approximately 25% for the access structures stored in the Associator, ADABAS
storage requirements are still less than those required for traditional file storage or for DBMSs
that do not use data compression.
JONES 222 MA IN ST 00008000
J 2 ONES 22 MAIN ST 0–0
15 22 8
6 12 4
bytes bytes
bytes bytes bytes
bytes
Data Before Compression (45 bytes)
ADABASCompressed Data (22 bytes)
l l l
C –
0 0–8
Figure 2–3: An Example of ADABAS Default Compression
ADABAS Design 2
17
Associator
The Associator is an organizational unit used for storing the structures required to access data
in Data Storage. It contains
􀀀 a control block for the database as a whole and control blocks for each file;
􀀀 all tables needed to control and maintain the database including a Field Definition Table or
“FDT” (see page 25) for each file and coupling lists for physically coupled files (see page 21);
􀀀 an inverted list for each descriptor in each file of the database and an Address Converter for each
file.
Inverted Lists
An inverted list, which is used to resolve ADABAS search commands and read records in logical
sequence, is built and maintained for each field in an ADABAS file that is designated as a key
field or “descriptor” (see page 28). It is called an “inverted” list because it is organized by
descriptor value rather than by ISN. The list comprises the Normal Index (NI) and as many as
14 Upper Indexes (UI).
The Normal Index (NI) of the inverted list for a particular descriptor has an entry for each value.
The entry contains the value itself, the number of records in which the value occurs, and the ISNs
of those records.
To increase search efficiency, Upper Index (UI) levels are automatically created by ADABAS
as required, each level to manage the next lower level index. The first level UI, like the NI it
manages, contains entries for only one descriptor in each index block. All other UI levels contain
entries for all descriptors in each index block. UIs require a minimal amount of space: two
blocks is the minimum.
Note:
The ADABAS Direct Access Method (ADAM) facility permits the retrieval of records directly
from Data Storage without accessing the inverted lists. The Data Storage block number in
which a record is located is calculated using a randomizing algorithm based on the ADAM key
of the record. The use of ADAM is completely transparent to application programs and query
and report writer facilities. See page 42 for more information.
ADABAS Concepts and Facilities 2
18
Figure 2–4 shows a typical Normal Index for the descriptor “city” in a customer file.
Value Count ISNs
London 27 3 . . .
New York
Zurich 31 2 6 23 76 . . .
61 96 . . .
. . .
Figure 2–4: A Normal Index
The example indicates that there are 31 records with the “city” Zurich (the ISNs of these records
are 2,6,23,76...).
Address Converter
The Address Converter determines the physical location of a record. It is an index that maps the
logical identifier of a record (that is, the ISN) to the relative ADABAS block number (RABN)
of the Data Storage block where the record is stored.
The Address Converter contains a list of RABNs in ISN order. Only the RABNs are actually
stored in the Address Converter; the ISNs are identified by their relative position.
ADABAS Design 2
19
Figure 2–5 shows the relationship between an inverted list, the Address Converter, and Data
Storage. For example, to determine the physical location of the record whose ISN is 6, ADABAS
uses the ISN as an index into the Address Converter. The sixth entry in the Address Converter
is 2. Therefore, ISN 6 is located in physical block 2 in Data Storage for this file.
123
45
678
Inverted List for CITY
London 27 3 ...
New York
Zurich 31 2 6 23 76 ...
61 96 ...
. . .
1
2
3
6
96
14
12758 ABC–COMP London
12600 JEL–COMP Zurich
14811 XYZ–COMP London
11643 R–COMP
14542 S–COMP New York
10002 B–COMP Munich
...
...
Block 1
Block 2
Block 3
Converter
Address
Data Storage
111
2
12
2
12
2...
Zurich
Associator
Figure 2–5: ADABAS Access Technique
When a record moves or is deleted, ADABAS updates the Address Converter automatically and
transparently.
Since the ISN for a record never changes, and its physical block address is stored only in the
Address Converter entry, the record itself may be moved in Data Storage with only one update
to the Address Converter required and with no extension to the access path of the record.
Even if a record has many descriptors defined, the inverted list for each descriptor need not be
modified because it contains ISNs.
This process explains how ADABAS is able to perform simple and complex searches quickly
and efficiently without storing pointer information in Data Storage.
ADABAS Concepts and Facilities 2
20
Work
The Work area stores information in three parts:
􀀀 Part 1 stores data protection information required by the routines for Autorestart and
Autobackout. See page 47 for more information.
􀀀 Part 2 stores intermediate results (ISN lists) of search commands.
􀀀 Part 3 stores final results (ISN lists) of search commands.
Other Components
Sort and Temp Areas
Certain ADABAS utilities (ADAINV, ADALOD) require two additional datasets, Sort and
Temp, for sorting and intermediate storage of data. Certain functions of the ADAORD utility
require the Temp dataset for intermediate storage.
The sizes of Temp and Sort vary according to the utility function to be executed. These datasets
can be allocated during the job and then released, or permanent datasets can be allocated and
reused.
Logs
ADABAS uses the following optional logs:
􀀀 The “command log” (CLOG) records information from the control block of each ADABAS
command that is issued. The CLOG provides an audit trail and can be used for debugging and
for monitoring the use of resources. Single or dual datasets can be used (dual datasets are
recommended).
􀀀 The “protection log” (PLOG) records before- and after-images of records and other elements
when changes are made to the database. It is used to recover the database (up to the last
completed transaction or “ET”) after restart. Single or dual datasets can be used (dual datasets
are recommended).
􀀀 The “recovery log” (RLOG) records additional information that the ADABAS Recovery Aid
uses to construct a recovery job stream. Dual datasets are required for recovery logging. See the
ADARAI utility discussion on page 53 for more information.
ADABAS Design 2
21
Database Files
Each database contains system files and data files. A data file is generally created for each record
structure required; that is, for each set of related fields identified.
Files are loaded into the database using the ADALOD utility. A file number must be unique in
the database and not greater than the maximum file number defined for the database in the
MAXFILES parameter. For a Checkpoint, Security, system file, or physically coupled file, the
number cannot be greater than 255; other files including a trigger file can have two-byte file
numbers. File numbers are assigned by the user in any sequence.
System Files
The ADALOD utility’s file type parameter identifies the file as one of the following ADABAS
system files:
CHECKPOINT ADABAS Checkpoint file
SECURITY ADABAS Security file
SYSFILE ADABAS system file (a file that cannot be deleted)
TRIGGER ADABAS trigger file
Coupled Files
File coupling allows you to select, using a single search command, records from one file that
are related (coupled) to records containing specified values in a second file.
Physical Coupling
Any two files with file numbers 255 or lower may be physically coupled if a common
“descriptor” (see page 28) with identical format and length definitions is present in both files.
A single file may be coupled with up to 18 other files, but only one coupling relationship may
exist between any two files at any one time. A file may not be coupled to itself.
When files are coupled, coupling lists are created in the Associator for each file being coupled.
File coupling is bidirectional rather than hierarchical in that two coupling lists are created for
each coupling relationship with each list containing the ISNs that are coupled to the other file.
ADABAS Concepts and Facilities 2
22
Once the physical coupling lists have been created, any key field in either file may be used
within a search criteria.
Physical coupling may add a considerable amount of overhead if the files involved are
frequently updated. The coupling lists must be updated if a record in either of the files is added
or deleted, or if the descriptor used as the basis for the coupling is updated in either file.
Physical coupling may be useful for information retrieval systems in which
􀀀 files seldom change;
􀀀 the additional overhead of the coupling lists is insignificant compared with the increased ease
of formulating queries; or
􀀀 files are small and primarily query-oriented.
Logical or “Soft” Coupling
Multiple files may also be queried by specifying the field to be used for interfile linkage in the
search criteria. ADABAS then performs all necessary search, read, and internal list matching
operations.
This technique is called logical or “soft” coupling because it does not require the files to be
physically coupled. Although logical coupling requires read commands, it is normally more
efficient because it avoids the increased overhead of coupling lists.
Structuring Files to Enhance Performance
An ADABAS database with one file for each record type supports any application functions
required of it and is the easiest to manipulate for interactive queries, but it may not yield the best
performance:
􀀀 As the number of ADABAS files increases, the number of ADABAS calls increases. Each
ADABAS call requires interpretation, validation and, in multiuser mode, supervisor call (SVC)
and queuing overhead.
􀀀 In addition to the input/output (I/O) operations necessary for accessing at least one index,
Address Converter, and Data Storage block from each file, the “one file per record type”
structure requires buffer pool space. If sufficient buffer space is not available, blocks are
overwritten that may be needed for a later request.
ADABAS Design 2
23
The number of ADABAS files used by critical programs can be reduced by
􀀀 using multiple-value fields and periodic groups (see page 26);
􀀀 linking physical files into a single logical (expanded) file;
􀀀 including more than one type of record in an ADABAS file;
􀀀 including records for more than one category of user in an ADABAS (multiclient) file; and
􀀀 controlling data duplication and the resulting high resource usage.
Expanded Files
If you have a large number of records of a single type, you may need to spread the records over
multiple physical files.
To reduce the number of files accessed, ADABAS allows you to link multiple physical files
containing records of the same format together as a single logical file. This file structure is called
an “expanded file” and the physical files comprising it are the “component files”. An expanded
file can comprise up to 128 component files, each with a unique range of logical ISNs. An
expanded file cannot exceed 4,294,967,294 records.
Note:
Since ADABAS version 6 supports larger file sizes and a greater number of ADABAS physical
files and databases, the need for expanded files has, in most cases, been removed.
Although an application program addresses the logical file (the address of the file is the number
of the expanded file’s base component or “anchor” file), ADABAS selects the correct
component file based on the data in a field defined as the “criterion” field. The data in this field
has characteristics unique to records in only one component file. When an application updates
the expanded file, ADABAS looks at the data in the criterion field in the record to be written
to determine which component file to update. When reading expanded file data, ADABAS uses
the logical ISN as the key to finding the correct component file.
Multiple Record Types in One File
Multiple record types can be defined within a single physical record; each record type is a logical
record composed of a subset of the fields defined for the file. Fields that do not belong to a given
type are null-suppressed.
ADABAS Concepts and Facilities 2
24
Record types can be identified to ADABAS by
􀀀 defining a record type field with values to differentiate one type from another; or
􀀀 using values of an existing field to differentiate type; for example, to differentiate two types,
a value of zero for a field common to both types might identify one type and any non-zero value
for the same field might identify the other type.
Multiclient Files
Records for multiple users or groups of users can be stored in a single ADABAS physical file
defined as “multiclient”. The multiclient feature divides the physical file into multiple logical
files by attaching an internal owner ID to each record.
The owner ID is assigned to a user ID. A user ID can have only one owner ID, but an owner ID
can belong to more than one user. Each user can access only the subset of records that is
associated with the user’s owner ID.
Note:
For any installed external security package such as RACF or CA-TOP SECRET, a user is still
identified by either NATURAL ETID or LOGON ID.
All database requests to multiclient files are handled by the ADABAS nucleus.
Controlled Data Redundancy
“Physical” redundancy increases storage requirements but may also enhance performance and
decrease complexity. For example, if a database stores customer and order information in a
Customer-Orders file and product descriptions in an Inventory file, and a program that generates
invoices requires product descriptions in addition to customer-order data, it might enhance
performance to store a duplicate copy of the product descriptions in the Customer-Orders file.
“Logical” redundancy also increases storage demands while decreasing complexity. It involves
storing in one file the results of a process on data in another file; thus, the duplicate data is
implied by the content of another file, rather than being physically stored in two places.
Physical and logical redundancy cause update programs to run more slowly. The duplicate
updates required when changes in one file affect records in another file may degrade
performance severely. Redundancy should be used only for static data or data that is updated
rarely. You can control data redundancy by using multiple-value fields, periodic groups, and
multiple record types within a file.
ADABAS Design 2
25
Records and Field Definitions
In ADABAS, the record structure and the content of each field in a physical file are described
in a Field Definition Table or “FDT”, which is stored in the Associator. There is one FDT for
each database file. The FDT is used by ADABAS during the execution of ADABAS commands
to determine the logical structure and characteristics of any given field (or group) in the file.
The FDT lists the fields of the file in physical record order; provides a “quick index” to the file’s
records; and defines the file’s fields, sub/superfields, and sub-/super-/hyper- and phonetic
descriptors. A minimum of one and a maximum of 926 field definitions may be specified.
Information about each field includes the level, name, length, format, options, and special field
and descriptor attributes.
FIELD DESCRIPTION TABLE
I I I I I
LEVEL I NAME I LENGTH I FORMAT I OPTIONS I PARENT OF
I I I I I
––––––I––––––I––––––––I––––––––I––––––––––––––I––––––––––––––––––––––––––––I
I I I I I I
1 I AA I 8 I A I DE,UQ I I
1 I AB I I I I I
2 I AC I 20 I A I NU I I
2 I AE I 20 I A I DE I SUPERDE,PHONDE I
2 I AD I 20 I A I NU I I
1 I AF I 1 I A I FI I I
1 I AG I 1 I A I FI I I
1 I AH I 6 I U I DE I I
1 I A2 I I I I I
1 I AO I 6 I A I DE I SUBDE,SUPERDE I
1 I AQ I I I PE I I
2 I AR I 3 I A I NU I SUPERDE I
2 I AS I 5 I P I NU I SUPERDE I
1 I A3 I I I I I
2 I AU I 2 I U I I SUPERDE I
2 I AV I 2 I U I NU I SUPERDE I
Figure 2–6: Field Definition Table
ADABAS Concepts and Facilities 2
26
Record Structure
The order of the fields listed in the FDT determines the structure of the record and the efficiency
of retrieval. The following factors should be considered when ordering fields:
􀀀 Fields that will be accessed frequently should be ordered first in the FDT. This technique reduces
CPU time because ADABAS does not have to read the whole record when retrieving a field.
􀀀 Fields that will frequently be accessed together should be assigned to a “group” field.
􀀀 Fields that will always be accessed together should be defined as a single field. This technique
may inhibit compression and query language use; however, it decreases processing time by
providing more efficient internal processing and shorter Format Buffers.
􀀀 If appropriate, fields that will frequently be empty should be ordered together in the FDT and
set to use default compression or null suppression.
􀀀 Numeric fields should be loaded in the format in which they will be used most often.
Field Levels
When two or more consecutive fields in the FDT are frequently accessed together, you can
reference them together by defining a group field. Other than its level and ADABAS short name,
a group field has no attributes defined. It immediately precedes its member fields in the FDT.
A higher field “level” number is used to assign the member fields to the group field. ADABAS
supports up to seven field levels. User programs can access each member field individually, or
all member fields together by referencing the group field.
For example, in Figure 2–6 on page 25, field AB is defined as a group field and assigned to level
1. Fields AC, AE, and AD are assigned to level 2, indicating that they belong to group field AB.
The next field, AF, is assigned to level 1, indicating that it is not part of the AB group. User
programs can access AC, AE, and AD individually, or together by referencing the group field
AB.
A group field can be assigned as a “periodic” group field if it is comprised of fields that can have
more than one value (for example, group field AQ in Figure 2–6); see page 30.
ADABAS Design 2
27
Field Names
A field is identified to ADABAS by a two-character ADABAS “short” name that must begin
with an alphabetic character and can be followed by a numeral or letter (the combinations
E0–E9 are reserved and special characters are not allowed) and must be unique within a file.
ADABAS assigns short names to fields automatically, although you can choose to assign them
yourself. ADABAS uses the short names internally and actually accesses fields by their short
names.
Field Length and Data Format
Field values are fixed or variable in length and can be in alphanumeric, binary, fixed-point,
floating-point, or packed/unpacked decimal formats.
The length (expressed in bytes) and format (expressed as a one-character code) of a field define
the standards (defaults) to be used by ADABAS during command processing. They are used
when the field is read/updated unless the user specifies an override.
If standard length is zero for a field, the field is assumed to be a variable-length field. Standard
format must be specified for a field. The format specified determines the type of default
compression to be performed on the field.
The maximum field lengths that may be specified depend on the “format” value:
Format Format Description Maximum Length
A Alphanumeric (left-justified) : see also the long
alphanumeric (LA) option on page 29
253 bytes
B Binary (right-justified, unsigned/positive) 126 bytes
F Fixed Point (right-justified, signed, positive value in
normal form; negative value in two’s complement form)
4 bytes (always
exactly 2 or 4 bytes)
G Floating Point (normalized form, signed) 8 bytes (always
exactly 4 or 8 bytes)
P Packed Decimal (right-justified, signed) 15 bytes
U Unpacked Decimal (right-justified, signed) 29 bytes
ADABAS Concepts and Facilities 2
28
Field Options
Options are specified using two-character codes, which may be specified in any order, separated
by a comma.
Code Option
DE Field is to be a descriptor (key).
UQ Field is to be a unique descriptor; that is, for each record in the file, the descriptor
must have a different value.
FI Field is to have a fixed storage length; values are stored without an internal length
byte, are not compressed, and cannot be longer than the defined field length.
LA An alphanumeric, variable-length field may contain a value up to 16,381 bytes
long.
NU Null values occurring in the field are to be suppressed.
MU Field may contain up to 191 values in a single record.
PE Group field with member fields that have multiple (up to 191) occurrences in a
given record.
NC Field may contain a null value that satisfies the SQL interpretation of a field
having no value; that is, the field’s value is not defined (not counted).
NN Field defined with NC option must always have a value defined; it cannot contain
an SQL null (not null).
Descriptor Options DE and UQ
A “descriptor” is a search key. The DE option indicates that the field is to be a descriptor. The
UQ option can only be specified if DE is also specified; it indicates that the DE field is to have
a different (i.e., unique) value for each record in the file. Entries are made in the Associator’s
inverted list for DE fields, adding disk space and processing overhead requirements.
Any field can be used within a selection criterion. When a field that is used extensively as a
search criterion is defined as a descriptor (key), the selection process is considerably faster since
ADABAS is able to access the descriptor’s values directly from the inverted list without reading
any records from Data Storage.
A descriptor field can be used as a sort key in a search command, as a way of controlling a logical
sequential read process (ascending or descending values), or as the basis for file coupling.
ADABAS Design 2
29
Any field and any number of fields in a file can be defined as descriptors. When a multiple-value
field or a field in a periodic group is defined as a descriptor, multiple key values are generated
for the record. Key searches may be limited to particular occurrences of a periodic group.
Because the inverted list requires disk space and update overhead, the descriptor option should
be used judiciously, particularly if the file is large and the field that is being considered as a
descriptor is updated frequently. For instance, the inverted list for a periodic group used as a
descriptor may be very large because each occurrence is stored.
A descriptor may be defined at the time a file is created, or later by using an ADABAS utility.
Because the definition of a descriptor is independent of and has no effect on the record structure,
descriptors may be created or deleted at any time without the need for database restructuring
or reorganization.
A portion of a field may be defined as a “subdescriptor”; combinations of fields or portions
thereof may be defined as a “superdescriptor”; a user-supplied algorithm may be the basis of
a “hyperdescriptor”; and a “sounds-like” encoding algorithm may be the basis of a “phonetic
descriptor”, which may be customized for specific language requirements. See page 31 for more
information.
Data Compression Options FI and NU
Default data compression is described on page 16. At the field level, additional compession can
be specified (null suppression option) or all compression can be disabled (fixed storage option).
“Null suppression” (NU) differs from default compression in that searches on descriptor fields
defined with null suppression do not return records in which the descriptor field is empty.
Fields defined as “fixed format” (FI) do not include a length byte and are not compressed. This
option actually saves storage space for one-byte fields or fields that are nearly always full (e.g.,
a field containing the social security number).
Long Alpha Option LA
The long alphanumeric (LA) option can only be specified for variable-length alphanumeric
fields; i.e., “A”-format fields having a length of zero. With the LA option, such an alphanumeric
field can contain a value up to 16,381 bytes long.
An alpha field with the LA option is compressed in the same way as an alpha field without the
option. The maximum length that a field with LA option can actually have is restricted by the
block size where the compressed record is stored.
ADABAS Concepts and Facilities 2
30
MU and PE Options and Field Types
ADABAS supports two basic field types: elementary fields and multiple-value fields. An
“elementary” field has only one value per record. A “multiple-value” (MU) field can have up
to 191 values, or occurrences, in a single record. Each multiple-value field has a “binary
occurrence counter” (BOC) that stores the number of occurrences.
A “periodic” (PE) group field defines consecutive fields in the FDT that repeat together in a
record. Like the members of a non-periodic group field, PE members immediately follow the
PE group field, have a higher level number than the PE field, and can be accessed both
individually and as a group. Each PE has a BOC that stores the number of occurrences.
A periodic group may be repeated up to 191 times per record and may contain one or more
multiple-value fields. Occurrences or values that are not used require no storage space.
ADABAS thus supports four field types:
Single Value per Record Multiple Values per Record
Single Field Elementary MU
Multiple Fields Group PE
Figure 2–7 illustrates the four field types in a single record structure.
Laura
FIRST
NAME
Cagnetti 3 1 118 Glade Erie 16509
LAST
NAME STREET CITY ZIP
ELEMENTARY
FIELD
GROUP FIELD
(NAME)
PERIODIC GROUP
(ADDRESS)
MULTIPLE VALUE
FIELD
CUSTOMER
NUMBER
19811
PE
BOC
MU
BOC
2
PA
STATE
271 Larue Cincinnati OH 45211
P.O. Box 88
2 733 Hall Easton PA 19014
P.O. Box 7
Figure 2–7: The ADABAS Field Types
ADABAS Design 2
31
A PE cannot be nested within another PE. Nesting an MU within a PE, as shown in Figure 2–7,
is permitted but complicates programming by introducing a two-dimensional array. It also has
implications for data access: when ADABAS accesses the periodic group, it returns only the first
occurrence of the MU for each occurrence of the PE returned.
The unique characteristic of the periodic group and the reason for choosing the periodic group
structure is its ability to maintain the order of occurrences. If a periodic group originally contains
three occurrences and the first or second occurrence is later deleted, those occurrences are set
to nulls; the third occurrence remains in the third position. This contrasts with the way leading
null entries are handled in multiple-value fields. The individual values in a multiple-value field
do not retain positional integrity if one of the values is removed.
SQL Compatibility Options NC and NN
Because Software AG’s mainframe ADABAS SQL Server (ESQ) and other Structured Query
Language (SQL) database query languages require SQL-compatible null representation, special
data definition options are included in ADABAS.
A field designated with the NC (not counted) option may contain a null value that satisfies the
SQL interpretation of a field having no value. An NC field containing a null means that no field
value has been entered; that is, the field’s value is not defined.
This undefined state differs from a null value assigned to a non-NC field for which no value has
been specified: a non-NC field’s null means the value in the field is either zero or blank,
depending on the field’s format.
The NN (not null) option can be specified only for NC-defined fields. It indicates that an NC
field must always have a value defined; it cannot contain an SQL null. This ensures that the field
cannot be left undefined when a record is either created or updated. The field value may be zero
or blank, however.
Special Field and Descriptor Attributes
Parent Of
The FDT indicates whether a field is a “parent” field for a sub/superfield, sub/superdescriptor,
hyperdescriptor, or phonetic descriptor as described in the following section.
ADABAS Concepts and Facilities 2
32
Special Descriptors
Information about any special fields and descriptors (subdescriptors, subfields,
superdescriptors, superfields, phonetic descriptors, and hyperdescriptors) in the file is
maintained in the Special Descriptor Table or “SDT” part of the FDT.
SPECIAL DESCRIPTOR TABLE
I I I I I I
TYPE I NAME I LENGTH I FORMAT I OPTIONS I STRUCTURE I
I I I I I I
–––––––I––––––I––––––––I––––––––I––––––––––––––––––––––I––––––––––––––––I
I I I I I I
SUPER I H1 I 4 I B I DE,NU I AU ( 1 – 2) I
I I I I I AV ( 1 – 2) I
SUB I S1 I 4 I A I DE I AO ( 1 – 4) I
SUPER I S2 I 26 I A I DE I AO ( 1 – 6) I
I I I I I AE ( 1 – 20) I
SUPER I S3 I 12 I A I DE,NU,PE I AR ( 1 – 3) I
I I I I I AS ( 1 – 9) I
I I I I I I
PHON I PH I I I I PH = PHON(AE) I
I I I I I I
I I I I I I
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Figure 2–8: Special Descriptor Table
Along with the name, length, format, and specified options of each special field and descriptor,
this table provides the following information:
Column Explanation
TYPE SUB Subfield/subdescriptor
SUPER Superfield/superdescriptor
PHON Phonetic descriptor
HYPER Hyperdescriptor
STRUCTURE The component fields and field bytes of the sub-, super-, or hyperdescriptor.
Phonetic fields show the equivalent alphanumeric elementary fields.
ADABAS Design 2
33
Subfield / Superfield
A portion of a field (“subfield”) or any combination of fields (“superfield”) may be defined as
an elementary field (see page 30). Subfields and superfields may be used for read operations
only. They may only be changed by updating the original fields.
Subdescriptor
A “subdescriptor” is part of a single field used as a descriptor. The field from which the
subdescriptor is derived may or may not be an elementary descriptor (see page 28). If a search
criteria involves a range of values contained in the first “n” bytes of an alphanumeric field or
the last “n” bytes of a numeric field, a subdescriptor may be defined using only the relevant bytes
of the field. A subdescriptor allows you to increase the efficiency of a search by specifying a
single value rather than a range of values.
For example, if the first two bytes of a five-byte field refer to a geographical region and you want
to retrieve all records for region 11 without using a subdescriptor, you would have to search for
all records in the range 11000–11999. If you define a subdescriptor comprising the first two
bytes of the field, you could search for all records with 11 in the subdescriptor.
Superdescriptor
A “superdescriptor” combines all or parts of 2–20 fields. The fields from which the
superdescriptor is derived may or may not be elementary descriptors. When search criteria
involve values for a combination of fields, using a superdescriptor is more efficient than using
a combination of several elementary descriptors.
For example, to search for customers by last name within regions, you could create a
superdescriptor by combining the first two bytes (i.e., the geographical region indicator) of the
five-byte customer number field and the entire customer last name field.
Phonetic Descriptor
A “phonetic” descriptor may be defined and used to search for all records that contain similar
phonetic values. The phonetic value of a descriptor is determined by an internal algorithm based
on the first 20 bytes of the field value with only alphabetic values being considered (numeric
values, special characters and blanks are ignored).
ADABAS Concepts and Facilities 2
34
Hyperdescriptor
The hyperdescriptor option can be used to generate descriptor values based on a user-supplied
algorithm. Up to 31 different hyperdescriptors can be defined for a single physical ADABAS
database. Each hyperdescriptor must be named by an appropriate HEXnn ADARUN statement
parameter in the job where it is used.
With hyperdescriptors, “fuzzy” matching is possible; i.e., retrieving data based on similar
rather than on exact search criteria. Hyperdescriptors allow multiple virtual indexes, meaning
that several different search index entries can be made for a single data field.
Hyperdescriptors can be used to implement “n”-component superdescriptors, derived keys, or
other key constructs. Using hyperdescriptors, it is possible to develop applications that are
simpler and more flexible than applications based on a strictly normalized relational structure.
One application area for hyperdescriptors is name processing. For example, the name
SCHROEDER could be stored not only with the index SCHROEDER itself, but also with the
“virtual” indexes SCHRODER, SCHRADER, SCHRÖDER or any other variation of the name.
Thus, although only the name SCHROEDER is physically stored in the data area of the database,
multiple search indexes exist to the data. If, subsequently, a search is made for the name
SCHRODER, the record SCHROEDER will be found.
A more sophisticated application area for hyperdescriptors is fingerprint matching, in which
typical characteristics of fingerprints can form the basis of a fuzzy matching algorithm; i.e., the
original fingerprint is stored in the database, but any number of search indexes can be made to
the fingerprint, based on an algorithm that allows small-scale deviations from the original.

Introduction of Adabas

2006-06-20T05:45:00.000-07:00

1
3
ADABAS IS . . .
ADABAS, the ADAptable DataBASe, is a high-performance, multithreaded, database
management system for mainframe platforms where database performance is a critical factor.
It is interoperable, scalable, and portable across multiple, heterogeneous platforms including
mainframe, midrange, and PC.
Operational Highlights
High Availability
ADABAS is designed for operation 7 days a week and 24 hours a day. Space is managed
dynamically (see page 14), files can be loaded and unloaded, backed up and restored, and system
performance can be analyzed without interrupting the active database.
Storage Space Optimization
ADABAS stores data in compressed form to reduce space requirements. Since modern
databases can be measured in gigabytes (1000 megabytes) or even terabytes (1000 gigabytes),
the savings in disk space can be considerable. Reduced space requirements also mean that the
input/output (I/O) system is more efficient.
Performance
Performance is the key factor of ADABAS, which includes a number of features to enhance it.
For instance, a number of set-up parameters are available for fine-tuning the database operating
environment, and many of these can be modified while the database is active.
Fault Tolerance
ADABAS recovers automatically after an abnormal database or system termination. Each time
an ADABAS database is started, an automatic check is initiated to determine whether the
database previously terminated “cleanly” or an active transaction was interrupted. If a
transaction was interrupted, ADABAS automatically resets all changes of the uncompleted
transaction so that the database is consistent.
ADABAS Concepts and Facilities 1
4
Operating Environment
ADABAS 6.2 for mainframes supports the following operating environments:
􀀀 SNI’s BS2000
􀀀 IBM’s OS/390, MVS/ESA, VSE/ESA, and VM/ESA
􀀀 Fujitsu’s OS IV/F4 MSP
􀀀 Software Pursuits’ MVT/VSE
Mainframe ADABAS can be used in distributed environments with ADABAS on
􀀀 Digital’s VAX and Alpha AXP under OpenVMS
􀀀 IBM’s AS/400 under OS/400
􀀀 Wang under VS
􀀀 IBM’s PC and compatibles under OS/2 or Windows/NT
􀀀 a variety of supported UNIX platforms
As the telecommunication interface, mainframe ADABAS supports TP monitors such as
Software AG’s COM-PLETE; or the popular TSO, CICS, IMS/DC, AITM/DC, TIAM, UTM,
or SHADOW.
Software AG’s multisystem processing tool ENTIRE NET–WORK provides the benefits of
distributed processing and (with ADABAS STAR) database distribution by allowing you to
communicate across a network with ADABAS and other service tasks.
Support for network access methods is implemented in the form of line drivers. Mainframe
ENTIRE NET–WORK provides drivers for VTAM, IUCV, DCAM, CTCA (channel-to-channel
adapter), TCP/IP, and XCF.
ADABAS Is . . . 1
5
Supported Data Models
ADABAS is a “relational-like” database. It is similar to relational databases in that it stores
information in tables in which rows represent individual data records and columns represent
fields. As in relational databases, separate ADABAS files can be linked logically by a common
field.
ADABAS differs from true relational databases in that it
􀀀 stores many data relationships physically, resulting in fewer demands on CPU resources than
true relational databases, which create all relationships logically at runtime.
􀀀 supports repeating groups of fields.
ADABAS separates data relationships, management, and retrieval from the actual physical data
and stores the physical data independently. It provides flexible access techniques and performs
both simple and complex searches quickly and efficiently. The independence of the data from
the program minimizes the need to reprogram when the database structure changes.
Logical data relationships can be created as needed. ADABAS can accommodate any
representational and access requirements dictated by the user environment. Each individual
corporate user can decide how to view data in the system, and can alter data relationships
dynamically—without altering the database or existing programs.
In contrast to systems that require a single model for all data, ADABAS allows you to choose
any structure your application requires. You can access the same data using your choice of
data-model perspective:
􀀀 relational including nested relational (tables within tables)
􀀀 entity relationship, with proven ability to support structural objects
􀀀 hierarchical; network
􀀀 geographical
􀀀 text
Support for an object-oriented data model is currently being developed.
These data models can be combined within a single business solution; multiple solutions can
view ADABAS data using different data models.
ADABAS Concepts and Facilities 1
6
As new requirements develop, ADABAS evolves in both scope and complexity without
redesign of the database or reprogramming of application systems. For example, field and
access keys may be added to an ADABAS file at any time without reloading or reorganizing
the file.
Operating Structure
Figure 1-1 shows the operating structure of the ADABAS system.
User
Program
ADABAS
Nucleus
I/O Buffer
Work Area
Associator
Data
Storage
CPU Memory Disk File
ADABAS
Threads
ADABAS
Utility
TP Monitor
Figure 1-1: The ADABAS System
Nucleus, I/O Buffer, and Threads
The ADABAS nucleus and input/output (I/O) buffer are loaded into main memory at startup.
The “nucleus” is a set of programs that drive ADABAS, coordinate all work, and translate user
program statements into ADABAS commands. All programs access ADABAS files through the
nucleus. All database activities such as data access and update are managed by the ADABAS
nucleus. In most cases, a single nucleus is used to manage a single physical database.
ADABAS Is . . . 1
7
Note:
For information about running multiple nuclei against a single physical database under a single
operating system image (ADASMP), see page 82; or under multiple MVS/ESA images
(ADAPLEX+), see page 84.
The ADABAS “I/O” buffer area, which can be resized for each ADABAS session, contains the
most frequently used data and data relationships; it helps to minimize physical input/output
(I/O) activity and thus saves computer time. It contains blocks read from the database and blocks
to be written to the database:
􀀀 For blocks read from the database, a “buffer algorithm” ensures that the most frequently
accessed blocks stay in memory. When a block from the database is needed, the buffer content
is checked to determine if the block is already in memory, thus avoiding unnecessary reads.
􀀀 Multiple updates are accumulated in a block before being written (“flushed”) to external
storage.
ADABAS provides multithreaded processing to maximize throughput. If I/O activity suspends
command processing in an active thread, ADABAS automatically switches to another thread.
The user may set the number of 8-kilobyte threads to be used for an ADABAS session up to a
maximum of 250.
ADABAS
ADABAS
Buffer
Thread1
Thread2
Thread3
..
Threadn
Associator
Data
Storage
Figure 1-2: ADABAS Multithread Processing
ADABAS Concepts and Facilities 1
8
Data Storage, Associator, and Work
The Data Storage, Associator, and Work components are physical disk areas. Data Storage
contains raw data, generally in compressed form. The Associator contains information about
data relationships. The Work area contains the data protection area and temporary storage for
intermediate results in complex search operations. See the chapter ADABAS Design starting
on page 13 for more information about these database components.
Utilities, User Programs, and TP Monitors
Utilities
Database services such as loading or deleting files are handled by an integrated set of online and
batch-mode “utility” programs. Most utilities can be run in parallel with normal database
activity to preclude interruption of daily production.
ADABAS utilities provide initial design and load operations, backup/restore/recovery routines,
database modification routines, and audit/control/tuning procedures. See the Utilities chapter
starting on page 49 for a brief explanation of each utility.
User Programs
The nucleus is called using a batch or online “user program” written in
􀀀 NATURAL, Software AG’s fourth-generation application development environment, or some
other fourth-generation language; or
􀀀 Assembler, or a third-generation programming language such as FORTRAN, COBOL, or PL/I
(the REXX/VSE interpreter language is also supported) that uses the powerful and flexible
ADABAS direct call interface. Each ADABAS call is accompanied by a parameter list
identifying buffers defined in the user program that are used to transfer information to and from
ADABAS.
Note:
See page 100 for information about ADABAS Native SQL, a precompiler for Ada, COBOL,
FORTRAN, and PL/I programs; and page 101 for information about ADABAS SQL Server, an
SQL interface to ADABAS.
Data from VSAM, DL/I, IMS/DB, SESAM, or TOTAL database structures can be transferred
to and stored in ADABAS using ADABAS “bridge” products. The original, unmodified
programs continue operating with their original data access commands while the bridge
products intercept the data access commands and translate them to ADABAS direct calls. See
page 88 for more information about ADABAS bridges.
ADABAS Is . . . 1
9
Special User Programs: Triggers and Stored Procedures
The ADABAS triggers and stored procedures facility, an integral part of ADABAS, can be used
with NATURAL (see page 102) and ADABAS ONLINE SYSTEM (see page 71) to write and
manage triggers and stored procedures in the ADABAS server environment. “Triggers” are
systematically used programs that are started automatically based on an event; they can be used
to ensure referential integrity, for instance. “Stored procedures” are programs used by a number
of different clients that are executed by ADABAS as a result of a special user call. Storing these
programs in an ADABAS file on the server reduces the amount of data traffic to and from the
server. See page 43 for more information about ADABAS triggers and stored procedures.
TP Monitors, Adalinks, and the ADABAS API
Since most systems do not allow a standard call to ADABAS, Software AG provides an
application program interface (API) to translate calls issued by an application program into a
form that can be handled by ADABAS. The ADABAS API is available across all supported
mainframe platforms for both batch and online operations.
Online operations are controlled by teleprocessing (TP) monitors, which serve as
telecommunication interfaces to ADABAS. Supported TP monitors are listed on page 4.
Software AG provides versions of the ADABAS API that are specific to particular TP monitors.
“Adalink” is a generic term that refers to the portion of the API that is specific to a particular
TP monitor.
Batch applications are supported in both single-user and multiuser mode (see page 11 for a
discussion of these modes). The ADABAS batch API uses a standard calling convention that
is supported by all major programming languages through their CALL mechanisms. Most
mainframe operating systems allow batch application modules to be linked either with the batch
API or with ADAUSER.
Software AG strongly recommends linking batch application programs with the ADABAS
version-independent module ADAUSER. The ADAUSER module can optionally be linked
with the ADABAS API. ADAUSER provides upward compatibility with ADABAS releases
and a degree of isolation from future changes to the API or to mechanisms that handle
interregion communication between the user and the nucleus (see page 12).
A client running under OpenEdition MVS can access ADABAS version 6.2. An OpenEdition
application containing calls to ADABAS can be linked with either the batch API or ADAUSER.
ADABAS Concepts and Facilities 1
10
Executing ADABAS
Session Types
Three types of sessions can be identified for ADABAS:
􀀀 The “ADABAS session” starts when the nucleus is invoked and ends when the nucleus is
terminated. An ADABAS nucleus is invoked using job control specific to a particular operating
system that contains ADABAS start-up or “ADARUN” parameters.
􀀀 A “user” is either a batch mode program or a person using a terminal. A “user session” can occur
only during an ADABAS session; that is, when the ADABAS nucleus is active. A user session
is a sequence of ADABAS calls optionally starting with an open user session (OP) command
and ending with a close user session (CL) command.
􀀀 A “utility session” is executed in batch, or online using the ADABAS ONLINE SYSTEM. Some
utilities require that the ADABAS nucleus be active; others do not. ADARUN start-up
parameters are also used for executing utilities.
Storage Areas
The ADABAS nucleus and each user program or ADABAS utility is executed in a separate
storage area defined by the operating system. The name of the storage area depends on the
operating system:
BS2000 task
MVS address space, data space, Hiperspace
VM virtual machine
VSE partition, address space, data space
For consistency and simplification, ADABAS manuals refers to all non-VM areas (task, address
space, partition, etc.) as “regions”. VM areas are called “virtual machines”.
ADABAS Is . . . 1
11
Modes of Operation
ADABAS supports two modes of operation: single-user and multiuser.
Single-user mode is in effect when a user program (or ADABAS utility) is executed in the same
partition/region as the ADABAS nucleus.
ADABAS
ADABAS
Buffer
Thread1
User Program
(or ADABAS utility)
Region /
Partition
Associator
Data
Storage
Figure 1-3: Single-User Mode
Multiuser mode is in effect when the ADABAS nucleus is located in a separate partition/region.
It is the most efficient and therefore the recommended mode of operation.
ADABAS
ADABAS
Buffer
Thread1
Thread2
..
Threadn
User Program 1
User Program 2
ADABAS Utility
User Program 3
Associator
Data
Storage
Figure 1-4: Multiuser Mode
ADABAS Concepts and Facilities 1
12
When using ADABAS in multiuser mode, interregion communication is handled by ADABAS
in a manner that takes optimum advantage of the communications facilities offered by the
various operating systems.
For single-user mode, the appropriate ADABAS nucleus JCL must be included with the job
control for the utility or user program.
ADARUN Start-up Parameters
The ADARUN control statement defines and starts the ADABAS operating environment. The
ADARUN control statement also starts ADABAS utilities. ADARUN
􀀀 loads the ADAIOR module, which performs all database I/O and other
operating-system-dependent functions;
􀀀 interprets the ADARUN parameter statements; then loads and modifies the appropriate
ADABAS nucleus or utility modules according to the ADARUN parameter settings; and
􀀀 transfers control to ADABAS.
The ADARUN statement, normally a series of entries each specifying one or more ADARUN
parameter settings, is specified in the DDCARD (MVS/ESA, VM/ESA, or BS2000) or VSE
CARD dataset.
Session Control
ADABAS provides several ways to monitor and control ADABAS, user, and utility sessions:
􀀀 ADABAS “operator commands” can be entered from the operator console during an ADABAS
session or during utility operation.
􀀀 The ADADBS OPERCOM utility function can issue operator commands to the ADABAS
nucleus. ADABAS then issues a message to the operator confirming the command execution.
􀀀 For those using ADABAS ONLINE SYSTEM, functions corresponding to operator commands
can be executed while an ADABAS session is active using menu options or direct commands.
Operator commands can be used to terminate an ADABAS or user session; display nucleus or
utility information; log commands; and change ADABAS operating parameters or conditions.
ADABAS “direct call commands” can also be used to open and close a user session. See page
35 for more information about direct call commands.
a