Set-up after Installation

Once you have installed Reality, you must carry out some or all of the following, depending on your installation:

1. On new Reality installations, or if the LIVE version of Reality has been changed during the installation process, logoff and logon again to ensure that the environment variables REALROOT and PATH are set correctly.

2. Install the latest Reality and UNIX-Connect updates. (See Installing Updates.)

3. Install the Software Keys.

4. If you have not already done so, start the central daemon by running realstart.

5. Create one or more databases.

6. Configure your databases.

7. Configure any Resilience features that you intend using.

8. If you have not already done so, make the new version live.

Installing the software keys

You will normally install the system serial number and software keys during the installation process.

If the key file was not available at that time, the keys can be installed by running:

{$REALROOT/bin/}installkeys keyFile

(Entering the full path should be unnecessary, because a successful installation adds $REALROOT/bin/ to the executable path.)

Running realstart

Before you can start using Reality you must start the Reality central daemon. If you did not run realstart when building the Reality executable, you can do this as follows:

1. Change user to root and run the realstart script:

   su
   Password:password
   #$REALROOT/bin/realstart
   ...
   ...(A commentary will be given as various tasks are completed by realstart)
   ...
   DAEMON nn WRITING TO realman/realman/15.1/files/daemon.log
   #exit

The new Reality is now installed (and LIVE if you accepted that option).

Creating a database

Before you can start using Reality you must create at least one database. Different types of database are available (see Types of Database) - this section shows you how to create a partition database using files on a single disk partition so that you can start using Reality. You can create this type of database at any convenient location in the UNIX file system.

To create a Reality database, log on to UNIX, change to the directory that will hold the database and then run the mkdbase command. For a database on a single file system, include the –S option to specify the size of the database:

mkdbase -S size –N databaseName

Where size is the size of the database in Mbytes (M suffix) or Gigabytes (G suffix). For example:

mkdbase -S 100M –N pdbase

creates a 100 Mbyte database called pdbase.

When a database is created, it is locked to all users except the database owner. It can be unlocked with the unlockdbase host command or the TCL command ENABLE-LOGONS.

The Database Owner

When you create a new database, a Reality user-id with SYSMAN privileges is created for the database owner (the Windows user who created it). The owner of the database can log on even when the database is locked, without specifying a user-id. If you need to administer the database, you should log on as the database owner.

To log on as the database owner, use the reality command, specifying the database required. For example, to log on to the database dbase0, enter:

reality dbase0

Configuring a database

Reality can be configured to suit particular user requirements by using the following configuration parameters. The parameters required should be defined in the config file /usr/realman/15.1/files/config if they are applicable to all new databases. Otherwise change the config file for the database concerned (DatabasePath/configs/config). Missing parameters are given their default value.

Parameter	Default Value	Purpose
MaxPortNum	400	MaxPortNum defines the maximum real port number which may connect to this database. A real port is one that is referenced in the devices file. Such ports are always allocated the same device ID. Reality will map such port identifiers, in a fixed way, to real port numbers.
NumPseudoPorts	400	NumPseudoPorts defines the number of pseudo ports that may connect to this database. A pseudo port is one which made its connection to the host dynamically, for instance by using the rlogin or telnet protocol or via some form of network server. Pseudo ports are also always used for TIPHs. Pseudo ports are allocated device IDs dynamically. Reality will map such port identifiers to the next available pseudo port.
NumConnections	128	NumConnections is the maximum number of connections that may be active on the database at any one time. This includes TIPHs, despoolers, etc.
DateFormat	International	DateFormat defines the format in which the days' date will be represented in certain English expressions and DataBasic OCONV statements. ·"Standard" for mm/dd/yy ·"International" for dd/mm/yy
NumItemLocks	NumConnections*3	NumItemLocks defines the maximum number of item locks that can be held on the database at any one time.
NumDataSects	400	NumDataSects defines the maximum number of data sections that may be OPEN at any one time.
NumIndexSects	50	NumIndexSects defines the maximum number of index sections that may be OPEN at any one time.
ShareSize	8000	ShareSize defines the size of memory available for shared DataBasic programs. The default is 8000Kb. Details of assessing the ShareSize and ShareModulo requirements are given in the User’s Reference: Administration.
ShareModulo	101	ShareModulo defines the modulo of the shared item hash table.
HashType		If HashType is set to 1 or omitted, any new database created will use the old hashing algorithm. If HashType set to 2, the new hashing algorithm will be used.

Tape parameters

Parameter	Default Value	Purpose
TapeNum	2	TapeNum defines the number of tape drives on the database, named Tape1, Tape2, etc.
TapeDevTypen	3	TapeDevType1, TapeDevType2, etc define the type of tape drive for TAPE1, TAPE2, etc, respectively. The types currently supported are: 28mm (Exabyte) cartridge 3¼ inch (QIC) cartridge 54mm (DAT) cartridge 8remote tape 9tape image
TapeDevSizen		TapeDevSize1, TapeDevSize2, etc defines the tape capacity size of the tape used in dbsave. Still relevant with virtual tape drives.
Tapen	As defined in the supplied config file	Associates a tape number with a UNIX device name.
CompressTapeImage	0	Specifies the default compression level (0 to 9) for tape images created from this database. 0 is no compression (fastest); 9 is maximum compression (slowest). Recommended level: 2.

The Tapen entries define the default devices for tape attachments without density specifications. For example, the TCL command T-ATT 2 will use Tape2. Additional entries in the form Tapen:density can be used to define different devices. For example, the command T-ATT 1 DEN = 6250 would require an entry Tape1:6250=/dev/rmt/0cbn.

How to configure tape devices is described in greater detail in the User’s Reference: Administration.

Configuring resilience features

For all resilience features - Transaction Handling, Rapid Recovery, Transaction Logging, Shadow Database or FailSafe - you must use the mklog command to create the raw log.

When you have created the rawlog, for all resilience features other than Shadow Database, you should then refer to the Resilience section of the on-line documentation for details of how to complete the configuration using tlmenu. If you are running Shadow Database, you should initially refer to the topic Shadow Database later in this section.

Creating a Raw Log using mklog

• If you intend using a dedicated partition for the raw log, you should have already created this - see Configuring a Log Disk. Now log in as root and use the mklog command to create the raw log. For example:

  # mklog –r /dev/rdsk/ct01d0s1

• If you intend using a file as your raw log, log in as root and use the mklog command to create a raw log file. For example:

  # $REALROOT/bin/mklog -r -ts10 /user5/rawlog

  This command creates a 10 MB file /user5/rawlog, to be used as the raw log.

When you have run mklog, stop and restart the central Reality daemon:

# killreal
# realstart

Shadow Database

Shadow Database is an optional feature that, when installed on a standalone host platform, provides all the functionality of Transaction Logging for data security and resilience, but in addition maintains a copy of the database in a separate disk partition that shadows the live database.

This section covers how to create the first shadow, pair0, using mount points /real0 (primary) and /real1 (secondary). A second shadow pair would be pair1 with mounts /real2 and /real3, etc.

1. Log on as superuser.

2. Create the directories to act as mount points for the primary and secondary databases.

   # mkdir /real0
   # mkdir /real1

3. Change the ownership of the database directories. For example:

   # cd /real0
   # chown dbaseowner .
   # chgrp other .
   # cd /real1
   # chown dbaseowner .
   # chgrp other .

   where dbaseowner is the user-id of the intended database owner.

   Note

   This step is not necessary when installing a shadow database on CentOS 6.5.

4. Logon as the database owner.

5. Create the databases. For example:

   $ mkdbase /real0/pdbase1
   $ mkdbase /real1/pdbase1

6. Refer to the Resilience section of the online documentation for details of how to complete the configuration of shadow database using tlmenu.

Making the new version live

If you did not accept the option to make the new version of Reality live on installation, you can do so now by editing the /usr/realman/installed file to show a space and then the word LIVE (all caps) after the entry for the new version and removing the word LIVE against any other version.