CADO Systems Technical Information

This article documents the CADO Systems Architecture. Initially developed in 1976 for CADO Business Systems running on CAT machines, it was ported to Contel's Tiger ATS platform in 1983 and later to the VERSYSS hardware in the 1990's.

System Overview

The CADO architecture is designed to allow multiple users to run business applications in a multitasking environment. The emphasis is on rapid software development and deployment. The primary software development language is CADOL.

It is possible to write 8086-based instructions directly into CADOL code by means of an "escape to ASM" instruction, and return to CADOL with an "escape to CADOL" routine. This was rarely done as assembly programming:
* Was beyond most CADOL programmers (who were trained for rapid application development)
* Suspended multitasking on your 8-user transaction processor.
* And an assembly bug could result in the entire machine crashing. (Whereas a bug in CADOL code would only terminate that user's session.)Assembly-language routines were not portable beyond the Tiger ATS series.

Compiled CADOL code runs in a private, memory protected, compartment on the machine. Each user is allowed 1 program to run at a time. From an applications standpoint there are no threads, other processes, or shared resources.

CADOL

CADOL is a BASIC-like language which is "compiled" into an intermediate language bytecode (IL). Each CADOL instruction becomes from one or more bytes depending on complexity. For example N5 = 1 becomes two IL bytes, but IF N5 = 15 RESET becomes 5 IL bytes (push 15, test N5, intra-segment goto, reset).

Internally each IL instruction maps to an Assembly language routine in the OS to manipulate the correct registers, or perform I/O.

Originally in CADOL, programs were limited to 256 IL bytes each. Later in CADOL III, chained program segments were allowed. Thus, at the end of one 256-byte block of code, the next segment would be loaded. Longer, more complex programs can be built in CADOL III.

Many of the other, later, additions to the CADOL language are syntactic sugar over older IL statements. Thus, a FOR loop is simply broken down to an assignment, conditional check, and a pair of GOTO instructions. IF statements that could perform other instructions (i.e. IF N5 = 1 RETURN) were broken down into a negated IF,GOTO pairing.

A CADOL III compiler can produce CADOL II code, if it's written carefully and does not exceed 256 bytes of IL.

It was not uncommon for CADOL programmers to become familiar with the IL instructions themselves. Many program fixes were distributed as patches to the IL code and the operating system came with a utility for patching programs.

Libraries

CADOL programs are stored in special files called Libraries. CADOL Libraries can contain up to 256 programs in numbered slots.

Calling other programs can be done through the LOAD instruction, which causes an immediate branch to the other program. Or the GOSUB instruction which places a return address onto a call stack, and runs the other program until a RETURN instruction is reached whereupon the caller resumes running.

CADO/Contel/VERSYSS distributed a library of system routines which could be addressed with a GOSUB instruction to a "negative" program number. So GOSUB -100 will call program 100 in the system library instead of program 100 in the current library.

Calling between libraries (other than a system library) is difficult and required a system call to perform it. So typically, a library will contain an entire functional application (Payroll, Patient History) along with a reserved block of "utility" programs for that library. These "utility" programs are often standardized within a programming team or a project. For example, programs 1-50 might be reserved for "variable initilization", "date conversion routines", or "sort setup".

Since each CADO/Contel/VERSYSS location was run as a separate office, they were rarely standardized between applications.

Terminal

CADOL programs assume a standard output device. This device is based (loosely) on a VT100-type terminal.

Each cell on an 80x24 terminal contains two types of information: a display character, and an attribute. Display characters are 7-bit ASCII characters.

Attributes marked regions of the screen as protected, unprotected, dim, bold, or blinking. When a CLEAR instruction is processed, all characters in unprotected fields on the screen are removed but the attributes remain behind. If a RESET instruction is processed all characters and attributes are removed.

CADO terminals had two special keys that were treated as exceptions if they were pressed while the system was waiting for input:

* "ESCAPE" -- Will cause Program 0 of the current library to load. This can be trapped for a special behavior (i.e. to force the user to finish the current task) but that generally isn't done.

* "CANCEL" -- Will cause the current program to restart at Segment 0, IL byte 0.

Additionally, there is an ESCAPE and a CANCEL instruction.

Screen layouts can be designed by programming through a series of ATT and DISPLAY instructions, or using an external program called a "mask" editor. The masks can then be loaded onto a blank screen via a system routine.

Buffers and Memory

User memory is private, protected by the OS. Accessing memory outside of the assigned area causes a memory fault for that user. Memory space is fixed and global, with the exception of being able to temporarily allocate an 8k track buffer (only on later Tiger models). Each user's memory footprint is 8k including variables, buffers and call stack space.

Each user of the system has available:

* 25 6-byte integer registers, labeled N1-N25
* 9 Alpha registers.
** A, B, and C of 40 bytes each
** A1, A2, B1, B3, C1, C2 of 20 bytes each
*: The alpha registers are arranged in A, A1, A2, B, B1, B2, C, C1, C2 order. If a register overflows, it will be continued into the next register. Thus, there is room for 240 bytes of alpha storage in the A register as long as you didn't use the other 8.
* A special-purpose 20 byte alpha register called "key" for file I/O.
* A special-purpose numeric register called "rec" also for file I/O.
* 5 256-byte Buffers: R, W, X, Y, Z
** The R buffer is where records are be read into by READ, READ REC, and READ KEY statements.
** Records are written from the W buffer by WRITE, WRITE REC.
** The remaining buffers are general-purpose.

Calling conventions for subroutines and other programs generally means placing the arguments in low numbered registers (N1-N5, A, A1) and making the call. Well behaved programs will document which registers will be used so that the programmer can re-load them after the call if necessary.

Strings

String values in CADOL are stored with the high-bit on for the length of the string, and then the high bit off on the final character to designate the end of string. Thus "Hello, World" becomes (in hex):

48 65 6C 6C 6F 2C 20 57 6F 72 6C 'E4'

This is done to save space as there's no need for a trailing Null character.

Record Structure

Records are keyed by an up-to-20 character alphabetic key. The record structure isn't externally defined for the file (as with an SQL data base) or in a header (as with a C struct). Alpha and numeric fields are lumped together and accessed by "skipping" fields you aren't interested in:

READ KEY 1 100 # Read a record INIT RP SKIP RA(4) # Skip 4 alphabetic fields SKIP RN(12) # Skip 12 additional bytes N4 = R(2) # Move two bytes to N4

Files and Disk I/O

Disk storage on CADO systems is arranged in a series of nested containers. The "Device" represents a single disk drive. A "Volume" is an contiguous area on a Device where all files are contained. A Device can have multiple Volumes. Within a Volume, file and library names must be unique. Allocation for files and libraries is done when they are created, must be contiguous, and cannot be expanded once created.

This creates a major problem on systems with large files that are tight on space. If a file spans 20 tracks and is full, to allocate an additional track there must be 21 "contiguous" tracks free on the disk. If there are not, the system must be backed up, files deleted, a new file allocated, records copied, the original file removed, and then the rest of the system restored from tape.

File on CADO systems are one of three types:

* Text files. These are rarely used, and usually only for word-processing applications.
* Sequential files.
* Hashed files.

Hashed and sequential files are fixed sized. The entire extent of the file is reserved when the file was created. The extent is calculated based on the number of records, the length of the key for the record, and the average size of the records in the file. Some adjustment to the record size during declaration (usually reducing it) can be done to avoid wasted space at the end of a track.

For programming purposes, files are not named they are numbered. Normally a "fileset" is opened which consists of nine files. Once the proper fileset is opened, a program would move on to read and write those files in known positions (i.e. an employee file as file 6, invoice file as file 7, options file as file 9, etc..).

Up to 20 files can be opened at one time by any user.

Record locking is achieved through the LOCK and UNLOCK statements. To avoid deadlocking and keep lock management simple, only one record can be locked by any user at one time. Attempting to lock a second record results in an error.

Track Format

Each file is a collection of 8k tracks, divided into 32 256-byte sectors. Some of the sectors in each track are designated as "key" sectors, some as "data" sectors.

When a record is written, the key is hashed to determine which track it belongs to. That track is read and (if possible) the key is written into a key sector, and the data is written into a data sector. If the key will not fit (the key sectors are full) or the data will not fit (the data sectors are full), then it is written to the next available track. As a consequence, deleted records are simply marked as deleted on the track, but the space is left allocated. The file must be compressed to removed deleted data or re-hashed to another file to removed deleted keys.

Sequential files are identical to hashed files, except that the hashing algorithm is disabled so each record is written to the first track and overflows as necessary.

References

* Kent, Allen. "Encyclopedia of Microcomputers", CRC Press, ISBN 0824727037.

External links

* [ http://99-bottles-of-beer.net/language-cadol-ii-1222.html 99 Bottles of Beer as done in CADOL II ]