NDB Concepts › What Is an NDB? › Differences Between NDBs and UDBs

Previous Topic: Uses of NDBs

Next Topic: NDB Types

Differences Between NDBs and UDBs

Both NDBs and UDBs are always VSAM data sets. An NDB is always a VSAM KSDS, whereas a UDB can be either a KSDS or an ESDS (a non-keyed VSAM data set).

The UDBCTL command is used to open a VSAM data set for access by the Virtual File Services (VFS). Thus, although an NDB should not be used as a UDB, the UDBCTL command is still used to open and close it.

Important! Do not access an NDB using the &FILE verbs, as if it were a UDB. If any access is done in this way, the NDB can be corrupted.

The following table summarizes the differences between UDBs and NDBS:

UDB

NDB

Can be a VSAM KSDS or ESDS.

Always a VSAM KSDS.

If KSDS, key length can be from 1 to 255.

Key length must be from 16 to 255.

VSAM maximum data length can be any valid value.

VSAM maximum data length has a minimum value restriction

Data is built or accessed by relative position in a record.

Data is accessed by field name.

Record length is limited by either the VSAM record length or the maximum NCL statement length after substitution.

Record length is independent of the VSAM record length or NCL statement length. The length is logically limited by the restriction of the 32 KB named fields.

Only one, unique, sequence key is provided, unless VSAM alternate indexes are used.

There is no requirement for any key. There can be any number of keys, and they need not be unique. There can, optionally, be a unique sequence key.

Multiple record structures to support multiple keying, and so on. Have no update integrity. A system failure can logically or physically corrupt the database.

Internal update journaling guarantees integrity of the multiple VSAM record structures used to support the NDB features.

Concurrent access can result in VSAM string waits or lockouts.

Concurrent access has no restrictions.

Complex searching is slow, as the logic must be implemented in NCL.

Complex searching runs at assembler speed. Keys are used whenever possible.

Multiple positioning (for sequential retrieval) by one NCL procedure is not possible.

An NCL procedure can have any number of simultaneous positions in an NDB.

UDBs are accessed using the &FILEOPEN verb. The first &FILE OPEN for a given UDB performs a logical open for the NCL process. Because the &FILE GET and similar verbs have no way of specifying the UDB they refer to, the last executed &FILE OPEN statement sets the UDB for these statements. Thus, &FILE OPEN has a double meaning.

NDBs are accessed using the &NDBOPEN verb. Each NDB accessed must be opened by an &NDBOPEN statement. The other &NDBxxx verbs allow specification of the database name and there is no need for repeated &FILE OPEN-like use of the &NDBOPEN verb.

Data in a UDB has no associated type. No validity checking is performed on the stored data.

Data in an NDB has a type. Invalid data (for example, nonnumeric for a numeric field) cannot be stored.

When an NDB is active, VFS prevents any access to it as a UDB. For example, if an &FILEID statement refers to an active NDB, it causes the NCL procedure to terminate with an error message.

Similarly, if an NDB is being accessed as a UDB, it cannot be accessed by NDB commands or &NDB statements.