UniData is a 'nested-relational database system'. It supports many of the capabilities of almost any available database system, and in addition, provides the ability and environment to perform many tasks not supported in other dtabase applications.

The UniData Database System runs on 'top' of unix, and it is within the UniData environment that your PRIMAC application runs. In addition to 'programmed environments' like PRIMAC, UniData supports 'SQL', 'Uniquery', and PROCedure structures and capabilities. Like other database systems, each UniData 'directory' contains a Master-Dictionary which defines commands, files, directories, procedures, and locally catalogued programs. This Master-Dictionary is known as the 'VOC'; short for vocabulary. In addition to the standard UniData capabilities, you can add to the VOC your own commands and procedures to perform specialized tasks to meet your own individual needs and environment.

Programming in UniData is done with the UniBasic language. This language is unique to databases which follow the 'nested database structure', and contains many commands and capabilities to allow it to access and process records which are essentially variable, multi-dimensional arrays of data.

Most typical systems have a file structure which conforms to a 'standard' format as below. In this 'typical' file-structure, files are divided into records, and records are divided into fields. By definition, this type of structure implies 'fixed' length records, and fixed length data fields, and possibly even fixed length files. Access to the data can be done sequentially, randomly, or via an index which is either maintained by the system or the application.

UniData data-files do not conform to this structure. A UniData data-file can best be thought of as a collection of multi-dimensional arrays, as in the following:

With this type of data structure, records are divided into what are known as attributes. Each record may have as may or as few attributes as are necessary, and each attribute is variable in length. This method allows for much more efficient storage of data, as only the actual data required is stored, and there are no 'space filled' areas stored on disk to maintain consistency between fields.

UniData also stores certain types of data in what is known as 'internal-format'. These data-types include dates, times and numeric values. Dates are stored as a sequential number, times are stored as 'seconds past midnight, and numbers are stored without leading zero's, commas, decimal points, or dollar signs. To provide flexibility in formatting and displaying these types of data elements, UniData provides what are known as 'conversion codes'. These codes are applied to the internal data prior to presentation in order to format the data in a variety of 'human-readable' forms.

Examples of these 'conversion codes' include:

Data	Conversion	Output
1000	D2/	05/18/95
1000	D2-	05-18-95
1000	MD2	100.00
1000	MD2$	$100.00
1000	MD0,	10,000
1000	MTS	02:46:40

As you see from this example, it is imperative when accessing and formatting data from the system, that the user understand what data is stored in the particular field. We see here that the same physical data can be presented in a variety of different ways.

Another area in which this database system is unique is the method used for creating data files and storing data. UniData uses what is known as a 'hashing-algorithm'. There are two 'hash-types' available for files in UniData. The first is 'static-hashing', and the second is 'dynamic-hashing'. The structure for each of these file types is very different in the following ways.

Static-hashed files appear at the Unix level as a 'file' entry. The file is created with a base-modulo, or initial allocation, which is any prime-number of 1024K blocks. Data is distributed in the file using a hashing algorithm which distributes the data within the file based on available space. When the primary file space has been exhausted, UniData will create primary and secondary overflow areas in which to store additional records as they are added.

Dynamic-hashed files appear at the Unix level as a 'directory' entry. A dynamic hashed file is created with an initial size or 'modulo' which cannot be a prime number. Data is stored in the directory within files with a naming convention of datnnn and overnnn (where nnn is a swquential number). Ideally, data will be distributed evenly between the 'dat' and 'over' portions of the files.

The primary difference between 'static' and 'dynamic' hashed files from the user perspective is the maintenance and overhead requirements. A file which grows continuously fits nicely into the 'dynamic' structure, while files which tend to grow slowly, or not at all, fit well into the 'static' format. Static files tend to require more maintenance, while 'dynamic' files require less maintenance and provide faster access times; however, dynamic files require more physical disk space to hold the same amount of data.

Back to Table of Contents

UniData provides several 'utilities' for analyzing and maintaining the database. These utilities are the "ISTAT", "FILE-STAT", "CHECKOVER", and "RESIZE" commands.

ISTAT	Provides detail Information on the status of an individual file.
FILE-STAT	Provides a file status in a summary format.
CHECKOVER	Will analyze all files in the current directory and indicate any files which need maintenance.
RESIZE	Will rebuild a data file and redistribute data based on a new modulo.

Utilities to analyze files may be run at any time. However you must NEVER resize a file while users are in the system. Updates to a data file durint the RESIZE process will seriously corrupt the data files and it is very possible to loose data and destroy the integrity of the database. Don't forget to shut down any phantom processes (Communications interfaces and Shop Floor Reporting modules) prior to resizing files on your system.

UniData Directories are created using the 'newacct' command from Unix. This command creates the base UniData directory, it's associated VOC file, and the subdirectories which UniData requires for specialized functions.

Back to Table of Contents

Directories included in the data area are:

APS
ARS
FAS
GLS
ICS
JCS
JES
OPS
POS
PRS
PSS
SAS

Vital files found in CBA-REV10A:

BP	Basic program file
CPYLIB	File containing all data file definitions
SCREENS	File containing all screen formats
PROCS	File containing all procedures for report calls

Identifying files within each module:

LIST JCS.CPYLIB LPTR

Every entry in the file JCS.cpylib is a record defining the layout and contents of every "data" file that is resident in the JCS account or directory. (Omitting any record entries beginning with COM. ...)

To quickly list the record definition for the JOB file:

AE JCS.CPYLIB JOB

at the ":" prompt; enter SP
at the ":" prompt; enter EX

Dictionaries exist in DICT file for definition in the cpylib record
(replace the "." with an "_")

Back to Table of Contents

UniData files are sequential files that store data; sequential files store data one character after another with no predefined format. All UNIX files are sequential files. UniData hashed files are UNIX sequential files; however, UniData uses a special format for storing database records, which is called hashing.

Hashing is defined as a storage mechnism with which data items are stored at locations that are determined by a mathematical function of the data. Hashing makes it possible to store and retrieve data items quickly, since the system does not have to search everywhere for data. Instead, the system uses the storage algorithm to find the data.

When a file is created in UniData, two files are actually created at the same time. The data portion of the file and a file for the directories. For example if a file were named CUSTOMER, then the dictionary file would be created and named D_CUSTOMER.

Back to Table of Contents