Scor­pio News

var1 = ""
var2 = ""
.
.
var<n> = ""

or you can do it simply and quicker:

store "" var1 = var2,....,​var<n>

All round a big improvement for the better, and it makes programs shorter.

What else has changed? Well an oddity is the ERASE command, that word was perhaps not the best choice for clearing the screen, but more convenient than the current word, CLEAR. Let me explain the word CLEAR in DBIII and DBIII+ has several uses, CLEAR clear the screen, CLEAR MEMORY clears all the memory variables (but not the screen), CLEAR ALL clears everything in sight including losing the databases (but doesn’ clear the screen) and CLEAR GETS chucks all pending inputs away (but still doesn’ clear the screen. So why CLEAR to clear the screen? Incidentally, the word ERASE which no longer appears in the DB list of commands, used in the following fashion:

ERASE filename.typ

will, none the less, erase a file without checking if you meant it!

Another little change is the use of the underscore character instead of the colon as a separator in variable names so that a variable

mstr:list

would be written as

mstr_list

Not that this made much difference, in fact, it appears more natural for as far as I know, DBII was the only programming language which uses a colon as a separator, whereas many use an underscore.

Perhaps the biggest pain (for me at least) was the much improved method specifying logical data types. In DBII, four different characters can be used to specify true or false; they are ‘t’ and ‘y’ for true and ‘f’ and ‘n’ for false. So the assignment:

STORE y TO var

would be interpreted by DBII as either a logical assignment or the assignment of a variable, y, depending upon whether y existed before the assignment, and what type of assignment it was previously. If in doubt, DBII would assume it to be logical, and would interpret it so if it hit a conditional statement which used it, and the syntax of the conditional was such that it appear as a logical assignment in the first place.

Very messy, but once you realised what was happening you could live with it. DBIII draws a definite distinction between other data-types and the logical data-type but placing a dot before and after the assignment variable to denote its use as a logical. Sound thinking that, it’s exactly the same construct they use to indicate logical operators in a command statement. Anyway, the logical assignment above becomes:

var = .y.

I lived with DBII method of doing things until I came to convert a load stuff from DBII to DBIII using the supplied utility DCONVERT.EXE, which, amongst other things, whips through source file converting all ERASEs to CLEARs, all colons in variable names to underscores and all occurrences of ‘y’, ‘n’, ‘t’ and ‘f’ to logical assignments regardless of context, etc. The problem was, the source software did a lot of positioning of a device not unlike a graphics plotter (actually moving a piece of microfilm to predetermined positions locked up in the database), and I had used the variables ‘x’ and ‘y’ to indicate the plot. All my ‘y’ positions turned into logical assignments, and I spent hours looking through the software for machine introduced errors.