CLASSIX.INI

Initialisation file CLASSIX.INI

• Description
• Syntax of the initialisation file
• Syntax of the 'Metainfo' section
• Syntax of the 'Dictionary' section
• Section 'Metainfo
• Dictionary' section

Description

The information required when starting the ClassiX® system is provided in an initialisation file. The starter program cx_osr.EXE can be given any path with flag -I. If an explicit path is missing, the initialisation file is searched for according to the specifications by the environment variables CX_SYSTEM and CX_ROOTDIR:

1. in all directories specified with CX_SYSTEM
2. in the directory CX_ROOTDIR\System

Using #include statements, the initialisation file can be composed of several files (and the search for the included files is also controlled by CX_SYSTEM or CX_ROOTDIR ).

The text consisting of one or more files, which provides all essential parameters for initialisation when the system is started, is referred to briefly as CLASSIX.INI in this documentation.

Much of the information possible in CLASSIX.INI can also be stored in the database. CLASSIX.INI must then refer to the (physical) database that contains the system information. This system database may also be one of the physical databases in which the objects are stored. The information from the database can be supplemented by further details in CLASSIX.INI. Overdefinitions are not possible; furthermore, the distribution of the information between the system database and the CLASSIX.INI file is arbitrary. It is also possible to refer to a database which does not contain any system information at all. But the database must exist.
Without this restriction, the ClassiX® system would start tacitly with the parameter set limited to the information from CLASSIX.INI in case of an incorrect path to the system database.

Note: If all databases are to be newly created, all system information must be described in CLASSIX.INI and there must be no reference to a system database, or the parameter /G must be used (see SystemDB).

CLASSIX.INI is divided into two sections. The beginning of a section is marked with the keywords MetaInfo or Dictionary. The following table lists which entries are possible in CLASSIX.INI An asterisk in column DB indicates that the corresponding information can also be stored in the database.

Related topics

• Syntax of the entries in CLASSIX.INI
• Explanations to the Dictionary section
• Explanation of the MetaInfo section
• Save meta data in the database
• Start of the ClassiX® system

Syntax of the initialisation file

The syntax of the file CLASSIX.INI is described completely in Backus-Naur-Notation. Terminal symbols are marked red:

InitializationData ::= [DictionarySection] MetaInfoSection

The syntax of the 'MetaInfo' section

MetaInfoSection ::= MetaInfo MetaInfoEntries

MetaInfoEntries ::= MetaInfoEntry | MetaInfoEntries MetaInfoEntry

MetaInfoEntry ::= DLLs | SchemaDB | IndexCopy | CheckIllegalPointers | DatabaseList | AutoLayer | SystemDB | ClassEntry | FileEntry | StorageEntry | SegmentEntry | Help | WinEditor

IndexCopy ::= IndexCopy(FLAT) | IndexCopy(DEEP)

SchemaDB ::= Schema(schemaDBLocation)

DLLs ::= DLLs(DLLList)

DLLList ::= dllName | DLLList , dllName

dllName ::= identifier

DatabaseList ::= Database | DatabaseList Database

Database ::= Database(integerNumber, identifier)

AutoLayer ::= AutoLayer(integerNumber, physicalDatabaseList)

physicalDatabaseList ::= physicalDatabase | physicalDatabaseList, physicalDatabase

SystemDB ::= SystemDB(identifier)

Help ::= Help(fileName)

WinEditor ::= WinEditor(editorIdentifier)

ClassEntry ::= Class(className, classID [, [fileName] [, [baseClassName]]] [[,] [entryPointIndex]]]][,] [Cluster(integerNumber)[,]]Docu(integerNumber))

className, baseClassName ::= identifier

classID ::= integerNumber

entryPointIndex ::= integerNumber | access expression

FileEntry ::= File(fileName, storageNames)

fileName ::= name

storageNames ::= identifer | identifier storageNames | ...

StorageEntry ::= Storage(storageName, physicalDataBase, [Segment], rootEPList, CSeg(collSegList), Garbage(rootEntryPoint, segmentName))

physicalDataBase ::= DB(integerNumber)

storageName ::= name

Segment ::= Seg(segmentList) | segmentID

segmentList ::= segmentID | segmentList, segmentID

segmentID ::= segmentName

SegmentEntry ::= Segment(segmentName, physicalDataBase, segmentParameter)

segmentParameter ::= EXTERNAL | AUTO | DEFAULT

rootEPList ::= rootEntryPoint | rootEPList, rootEntryPoint

rootEntryPoint ::= EP(rootEntryPointName[(collectionType)])

rootEntryPointName ::= name

collectionType ::= BAG | SET | LIST | ARRAY

collSegList ::= segmentName | collSegList, segmentName

segmentName ::= name

name ::= identifier | string

The syntax of the 'Dictionary' section

DictionarySection ::= [Dictionary] [Size] DictionaryEntryList

Size ::= Size(integerNumber)

DictionaryEntryList ::= DictionaryEntry | DictionaryEntryList DictionaryEntry

DictionaryEntry ::= SpecifierDescriptor | SlotDescriptor | DataMemberDescriptor | IndexDescriptor | RetrieveDescriptor

SpecifierDescriptor ::= Specifier(specifierName, integerNumber)

specifierName ::= name

SlotDescriptor ::= Slot(slotName, [semanticDescription,] integerNumber, typeName [, transformationTable | className])

slotName ::= name

DataMemberDescriptor ::= Member(fieldName, [semanticDescription,] typeName [, transformationTable])

fieldName ::= access expression

IndexDescriptor ::= Index(slotID, integerNumber)

slotID ::= identifier[.identifier]

RetrieveDescriptor ::= Retrieve(access expression list, integerNumber) [returns(typeName)]

access expression list ::= access expression | access expression list, access expression

semanticDescription ::= multipleStringConstant

multipleStringConstant ::= T(listOfStrings)

listOfStrings ::= string | listOfStrings, string

typeName ::= INTEGER | SHORT | CHAR | ENUMSHORT | ENUMCHAR | POINTER | COLL | REL_11 | REL_1M | REL_M1 | REL_MN | STRING | CXB_STRING | CXB_MULTIPLE_STRING | className

transformationTable ::= "fileName[~sectionName]" | "identifier()"

sectionName ::= identifier

Finally, some of the elementary meta-variables used so far:

identifier ::= letter | identifier alnum_char

letter ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | _

digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

alnum_char ::= letter | digit

integerNumber ::= digit | integerNumber digit

There is no formal definition for 'string' and 'fileName', whose shape can be assumed to be known.

Section 'MetaInfo

This section of the initialisation file tells the object manager which classes there are, how the database is logically divided and where within the database the objects of a class should be stored(further explanations):

The description where and how objects of a class are to be stored is summarised as a file. Different classes can use the same file information. A file refers to storages. The object manager keeps an index i and only the i-th storage is visible for all files, whereby the database is logically divided into independent areas - layers. When working in layer i, there is no access to the data in layer k. Layers divide the set of all stored objects into disjunctive subsets, i.e. an object can only belong to one layer.

Storages define parameters that are directly related to the selected storage form. In the following storages for the database ObjectStore are described. ClassiX® can work with any number of physical databases - therefore this specification belongs to the storage. To understand the other parameters, a look at the internal structure of the ObjectStore database helps:

The database is divided into segments. Consequently, it must be determined in which segment the objects are stored. To retrieve data in an ObjectStore database, it must be directly or indirectly connected to a root entry point. Collections connected to a root entry point are defined in the storage. These collections combine the objects of a class. The set of all objects of a class can be distributed to different collections. The resulting subsets are called domains in ClassiX®. An object may belong to several domains, i.e. the subsets are not necessarily disjunctive.

An object may also be an element of the collection(s) of its base class(es). Just like objects, collections are located in a specific segment of the database. Since objects are often searched for within a collection, it is to be expected that the distribution of objects and collections to the segments will have an impact on the performance of an application.

The object manager deletes an object only logically. For this reason, the storage includes information on where logically deleted objects are kept (segment, collection).

As mentioned above, objects can be distributed to different physical databases. ObjectStore allows relations between objects in different databases. This feature must be activated explicitly by specifying EXTERNAL for the segment concerned.

The type can be determined for each collection. Without explicit specification, a set is created.

After the keyword Schema, the location of the ObjectStore schema database is specified.

Especially when new classes are developed, illegal pointers can be written into the database due to program errors. ObjectStore can detect this - but at the expense of performance. With the keyword CheckIllegalPointer this mode is activated.

The information about the classes, files and storages are usually stored in a separate file (classix.odb) which is then inserted into the file classix.ini by an include statement. In the following the above described structure of the information about the storage location of objects is described with an example.

Class(CX_SPAN_DATE, 31022, date, CX_DATE, 0, Docu(142))
File(date, empty, date)
Storage(date, DB(1), "dateS", EP("dateL0"), CSeg("cs.basic"), Garbage("geps1", "gcs1"))

In the first line, the unique number 31022 is defined for the class CX_SPAN_DATE and assigned to the file date. It is also specified here that the class is derived from CX_DATE and an assignment to the documentation is made.
In the second line the file date is defined and the storage for each layer is specified. In this case, empty is specified for layer 0, as the storage is to take place in layer 1.
In the last line the storage specified for layer 1 is finally defined, first the name, then the database. Next, the name of the segment in which the objects are stored is specified. With the specification EP the name of the root entry point is defined, through which the collection with all objects of this class is reached. The specification CSeg defines the name of the segment in which this collection is stored. Finally, the segment in which deleted objects from this storage are archived is specified.

Dictionary' section

This section describes slots. A slot is identified by its name and an integer number. The data type must also be known.

Also 'ordinary' data members can be described here. This is of interest for data fields of the types ENUMSHORT and ENUMCHAR, because they refer to a transformation table . InstantView® uses this table automatically if the value of such a data field has to be converted into a character string or vice versa. The window object Enumeration shows the identifiers from the table in a combo box.