@(#) README   6.2.8   1997-02-20   admin

Zweck:
=====

Kurzbeschreibung zur Installation und Durchfuehrung 
der Single-User-Tests (SUT)

Die SUTs dienen als Verifikationsmittel fuer den Nukleus. Die 
SUTs muessen auf den jeweiligen Plattformen genau den gleichen
Output wie unter SCO UNIX liefern. Ist dies nicht der Fall, sollte
man sich an die Kernentwickler wenden. Daraus leitet sich die
Wichtigkeit des Tests ab.

Ein Testrom kann aus bis zu vier unterschiedlichen Komponenten bestehen.
Beipiel:

    ==> AK01TEST

    [1] AK01TEST.vdnts : Enthaelt SQL Kommandos, die ueber den
                         slowci an den Kern geschickt werden.

    [2] AK01TEST1.cmd  : Ist eine "Include-Datei", die auch in
                         das AK01TEST.vdnts einfliesst und ebenfalls
                         SQL Kommandos enthaelt. Dient zur besseren
                         Gliederung der Teststroeme.

    [3] AK01TEST.punix : Ist der Output des Kerns, der korrekt
                         bezueglich des Eingabestroms ist. Zu
                         jedem Teststrom existiert solch ein Refe-
                         renzprotokoll.

    [4] AK01TEST.tpunx : Verhaelt sich der quicke Kern anders als
                         im slow'en Fall, dann existiert dieses
                         weitere Referenzprotokoll.


Die VDNTS Datei fungiert als Eingabe fuer den Kommandointerpreter
(sprich: SLOWCI), der die SQL Kommandos ausliesst und dann sukzessive an
den Kern weiterreicht. Die Rueckgaben der Kerns werden vom SLOWCI in
einer Protokolldatei gespeichert, die dann anschliessend mit dem
passenden Referenzprotokoll verglichen wird.

Im Normalfall existiert zwischen dem gerade erstellten Protokoll und 
dem Referenzprotokoll keine Differenz. Sollte dies doch einmal(?) der
Fall sein wird der Unterschied der Protokolldateien, beispielsweise 
in der Datei AK01TEST.pdiff, festgehalten. Das komplette Protokoll
des SLOWCI findet sich dann in der Datei AK01TEST.prot.

Ist das Protokoll des SLOWCI korrekt, weil sich beispielsweise die 
Syntax eines SQL Kommandos geaendert hat, dann muss das Protokoll 
zum neuen Referenzprotokoll gemacht werden.


Umgebung einrichten:
====================

Die Single-User-Tests werden mit der VMAKE-Description 
"$DESC/fast/sut.mac" in das Verzeichnis $TEST/kern/sut kopiert, 
das gleichzeitig als RUNDIRECTORY des DB-Kerns fungiert.

Die Datenbank mit dem die SUTs auf der ALL durchgefuehrt wurden
hat die nachfolgenden Parametereinstellungen.

Es empfiehlt sich die beschriebene Konfiguration zu uebernehmen, damit
moeglichst wenig Differenzen in den Protokollen auftreten.

Single-User-Test
----------------



KERNELVERSION     KERNEL 6.2.8.0           DATE 1997-02-19
UNICODE           NO
MAXSERVERDB                  2
MAXARCHIVELOGS               1
MAXDATADEVSPACES             1
SERVERDB          axel628
MIRRORED_DATA     NO
LOG_MODE          DUAL
LOG_SEGMENT_SIZE           400
CONTROLUSERID     SUPERDBA
CONTROLPASSWORD   ????????
MAXBACKUPDEVS                4
_MAXAUTOBACKUPDEVS           1
MAXSERVERTASKS              14
MAXUSERTASKS                 2
MAXDATAPAGES              3000
MAXCPU                       1
PACKET_SIZE              32768
CAT_CACHE_SUPPLY            96
DATA_CACHE                 500
SEQUENCE_CACHE               1
DBPROC_DATA_CACHE           40
DBPROC_CODE_CACHE           80
LOG_IO_QUEUE                16
ROLLBACK_CACHE              20
_LOG_MAXCOPY_PAGES           0
CONVERTER_CACHE             18
MAXLOCKS                  2500
DEADLOCK_DETECTION           0
RUNDIRECTORY      /u/upd628/test/kern/sut
OPMSG1            /dev/null
OPMSG2            /dev/null
KERNELDIAGSIZE             100
KERNELTRACESIZE            800
SESSION_TIMEOUT            900
LOCK_TIMEOUT               360
REQUEST_TIMEOUT            180
DEFAULT_CODE      ASCII
DATE_TIME_FORMAT  INTERNAL
SYSDEV_001        ../SYSDEV
SYS_TYPE_001
M_SYSDEV_001
M_SYS_TYPE_001
ARCHIVE_LOG_001   ../ARCHLOG
ARCHIVE_TYPE_001
ARCHIVE_SIZE_001           900
M_ARCHIVE_LOG_001 ../M_ARCHLOG
M_ARCHIVE_TYPE_001F
ARCHIVE_LOG_002
ARCHIVE_TYPE_002
ARCHIVE_SIZE_002
M_ARCHIVE_LOG_002
M_ARCHIVE_TYPE_002
ARCHIVE_LOG_003
ARCHIVE_TYPE_003
ARCHIVE_SIZE_003
M_ARCHIVE_LOG_003
M_ARCHIVE_TYPE_003
ARCHIVE_LOG_004
ARCHIVE_TYPE_004
ARCHIVE_SIZE_004
M_ARCHIVE_LOG_004
M_ARCHIVE_TYPE_004
ARCHIVE_LOG_005
ARCHIVE_TYPE_005
ARCHIVE_SIZE_005
M_ARCHIVE_LOG_005
M_ARCHIVE_TYPE_005
ARCHIVE_LOG_006
ARCHIVE_TYPE_006
ARCHIVE_SIZE_006
M_ARCHIVE_LOG_006
M_ARCHIVE_TYPE_006
ARCHIVE_LOG_007
ARCHIVE_TYPE_007
ARCHIVE_SIZE_007
M_ARCHIVE_LOG_007
M_ARCHIVE_TYPE_007
DATADEV_0001      ../DATADEV
DATA_TYPE_0001    F
DATA_SIZE_0001            2000

Fuer das INIT CONFIG mit dem die SUTs beginnen, werden insgesamt
vier DEVSPACEs benoetigt, die alle ueber das XPARAM bekanntgemacht
werden. Die Einstellung erfolgt mit x_param SHOWALL -u superuser usw.

Es empfiehlt sich vor Beginn des Testlaufes die entsprechende Anzahl 
an Dateien zu 'touchen' oder ausreichend RAW-DEVICES zur Verfuegung 
zu stellen.

Es ist sinnvoll den LOG- und den DATENDEVSPACE auf jeweils ein RAW-
DEVICE zu legen. Der SYSTEMDEVSPACE kann dagegen auf einer Datei ar-
beiten.


Starten:
========

Die Durchfuehrung der SUTs erfolgt mit dem Shell-Script sutall, wobei
die Aufrufsyntax beispielsweise wie folgt aussieht:

Enter Command > sutall $SPEED slowci $SERVERDB.

 - SPEED:    bezeichnet natuerlich den DB-Nukleus, also slow, quick oder
             fast.
 - SERVERDB: sollte am besten sut612 heissen.


Auswerten:
==========

In dem Verzeichnis $TEST/kern/sut stehen die Ergebnisse des Testlaufs.
Sollte zu einem Teststrom eine Differenzdatei existiert ist diese mit
"check-sut" oder "check-sut <Teststromname>" auszuwerten.  

Sollte es sich um keine Standarddifferenz wie Datums-, Zeitausgabe,
Byteswap usw. handeln, ist dem  dem Phaenomen nachzugehen (sprich: 
Kernentwickler benachrichtigen).


Standarddifferenzen:
====================

Die folgenden Teststrome sind bekannt dafuer, dass sie Datums- und 
Zeitwerte behandeln und deshalb entsprechende Ausgaben liefern,
die zu Differenzen mit den Referenzprotokollen fuehren:

A01DBA          ==> Laufzeitabhaengige Unterschiede bei Log Queue
AK01TEST        ==> Laufzeitabhaengige Unterschiede bei Log Queue
C05TIME         ==> Zeit
CHARNULL        ==> Diff unter WINDOWS scheitert bei 0x00
CHRORA          ==> Diff unter WINDOWS scheitert bei 0x00
CONSTR1         ==> Zeit (siehe Protokollheader)
C05TIME         ==> Zeit
DEMO            ==> Zeit
E02LIKE         ==> Diff unter WINDOWS scheitert bei 0x00
FD              ==> zwischen 9 und 12 Uhr kein "INTEGRATION VIOLATION"
MONITOR         ==> Laufzeitabhaengige Unterschiede bei Log Queue
N40DATE         ==> Zeit
N40DATEA        ==> Zeit
N55VIEW         ==> Zeit
N64VALUE        ==> Zeit
ORABOOK         ==> Zeit
ORADATE         ==> Zeit
STAU            ==> WORK ROLLED BACK (sporadisch)
S05STATI        ==> Laufzeitabhaengige Unterschiede
S06REST1        ==> Laufzeitabhaengige Unterschiede bei Converter Cache,
                    Log Queue, Physical Writes
FUNC            ==> es treten Rundungsfehler ab der 15'Stelle auf
ODBC   


Ansprechperson:
===============

Die Datei $SUT/ISUT enthaelt eine Auflistung, die angibt welcher
Kernentwickler fuer welchen Teststrom zustaendig ist. Bei frag-
wuerdigen SUT Ergebnissen sind dann diese Leute anzusprechen.
