DATABASE INSTALLATION PROGRAM:
The DBSEMAKR program installs new datafiles designed by the user. It also
loads and edits existing datafile structures, then writes a new datafile
definition in another directory. The POWRCOPY program can be used to move data
from one or more files into a new format.
To start the program select install user-designed datafiles from the menu of
the GO program. DBSEMAKR will load in the normal manner and ask whether you
wish to load/edit an existing file, or start fresh. If you opt to edit an
existing file you enter the name of the directory where the established file is
recorded and the format is loaded and displayed.
If you opt to start a new file the program asks if you wish the file to be
assessed by the POWRMAIL program. If you may desire to do a mass mailing to
the persons/organizations detailed in the file then you must opt to make the
new datafile compatible with POWRMAIL, or originate your own label print
program. When the program displays the fields automatically dedicated to
POWRMAIL none of them will be indexed. You may alter the indexing any way you
wish, but you may alter neither the class nor the length of the program-
generated fields. Doing so will render the file un-accessible to POWRMAIL.
Perhaps you are installing an inventory file. Since you will have no need to
mail things to your stock, opt for a file that is not accessible to POWRMAIL.
The dialog box will guide you through the first field, then it will be
The data display of the DBSEMAKR program is quite similar to the browse
function of the BASE program. You "navigate" by pressing the up/down arrow
keys, the page up/down and home/end keys. When the number of the desired field
is flashing it will be the object of the functions selected.
Pressing the return key causes the program to re-prompt you for the details of
the high-lighted field. If you don't wish to change what's there just press
return. Pressing the "A" key causes the program to prompt you for the details
of a new field, then adds that field to the end of the file.
When you are specifying or correcting a field you are first prompted for the
name. If the name you enter has been used it will be rejected. Then you are
asked the type of data to reside in that field. If you select alpha-numeric
data you will, unless all indexes have been used, be offered the opportunity to
establish an index for the new field.
If you select numeric data storage you will be prompted for the number of
decimals to record in the field. If a number is entered or otherwise written
into the field it will be automatically rounded to the specifyed format.
The last part of the definition process specifies the maximum number of
characters allowed in the field. The maximum number is 35 for string data, and
numeric data ALWAYS occupies eight bytes per field. When you specify a numeric
field the length of eight will be automatically chosen.
Inserting a new field will move the high-lighted field (and those that follow
it) "down" one, then prompt you for the details of a new field to be inserted
in that position. Deleting a field will remove it, and bring all those
following it "up" one.
Your progress may be printed at any time, as many times as you wish.
When you have your datafile designed as you wish press "W" to record it to the
disk. You will be prompted for a name to be assigned the new directory the
program will make to hold the new datafile. You will also enter a 35 character
description of the datafile. The directory name and the user-assigned
description will both be displayed when the BASE program makes a menu of the
files on that disk.
The operation of this program is really simple. As usual, the dialog box
guides you and makes you aware of your options at any given time. The program
has a single help file that is displayed by pressing "H" from the data display
screen. If you become confused during the program opt to view the on-screen
Before starting the DBSEMAKR program your datafile should be carefully designed
to efficiently record data pertinent to the record and to exclude non-
indicative or overly-long portions of your current paper filing system.
Telling you how to define your file is beyond the scope of these instructions
due to lack of information on my part. You will find, in the next section,
some concepts and "tips" gleaned from having read/written too much data on too
INSTALLING YOUR OWN datafile
DATAMAGE is in the gray area between a program and a programming language. By
definition, a program causes the computer to perform a specific task, and a
programming language allows the user to select and execute any operations
included in the language. With the power of "in flight" programming,
unfortunately, comes at least some of the responsibility of the programmer. If
you press the wrong keys, for example, you will get the wrong results.
Further, you will need to do some planning before you set up your own datafile.
These instructions can only offer you some helpful hints, because we have no
idea of the type of data you want to store.
PLANNING YOUR DISK SPACE:
The raw materials this program has available to it vary from computer to
computer. With a floppy based computer, having 40 track drive(s), the gross
storage available is around 300 KB. The file index can occupy up to 40K, and
the DB definition files take some room, etc.
You should know the approximate number of records your datafile will be called
upon to hold. Divide 300,000 by this number, and you will get the maximum
allowable record size, in bytes.
For example, suppose you need to place up to 2000 records on a forty track
floppy. 300,000 divided by 2000 is 150. And, at 150 bytes, the data segments
must be small, if they are to be many. Using four string segments at the
maximum length of 35 bytes, and a single numeric segment (8 bytes) covers 148
bytes of disk space. Most datafiles have between twenty and fifty segments.
This program can access 224 megabytes on disk. (32,000 records X 7,000 bytes
per record) One datafile can fill any H.D.!
NUMERIC STORAGE CONSIDERATIONS:
All numeric data stored by the program is double precision, having 16 digit
capacity, and full floating point. To store this type of number on disk
requires 8 bytes. All numeric segments, whether their class is numeric, or
numeric dollar format, reside in eight of their own bytes on disk.
Calculations done by the program have 16 digits to work with, and are more
precise than the same calculations done with all but the most expensive
calculators. Some numbers are printed by the program with scientific notation,
in the d format. If you see a number followed by "D ( + or - )," then a
number, the printed number needs to have the decimal moved left (+) or right
(-) the number of digits indicated by the number printed after the sign.
STRING STORAGE CONSIDERATIONS:
The maximum length of a string (STRING is defined in the glossary) segment is
35 characters, and each character requires one byte of disk space. Using too
many possible characters in a string segment causes wasted disk space, and too
few causes the data to be difficult to read, due to over-abbreviation, etc.
String segments offer more than the ability to store a name, address or the
like. A one byte string segment can be declared as a "switch" This could be
used, for example, in a sales history datafile, to indicate whether or not a
sale was pre-paid. The name of the data segment might be: PREPD? (Y or N)
When entering records, you would enter a "Y" if the sale was prepaid, or a "N"
if it was not.
An expansion of the switch structure is the code. A code occupying a two byte
string on disk could have 416 possible meanings, working with the 26 lower case
letters, only. Rising to 2,704 if case is incorporated. Both the switch and
the code are ways to save disk space. A paper record of the possible codes for
each data segment should be prepared, and used to interpret the codes stored in
An good example of the proper use of a code is to identify the source of a
part, as one of 127 possible vendors. Space on disk is saved, since a lengthy
data segment holding a company name is replaced by a one byte segment holding a
code, but the datafile needs the code sheet to be read.
Of course, you could also record the record number detailing that vendor in
GENERAL DATAFILE DESIGN CONSIDERATIONS:
The programs produce listings of the records, and their name fields. To do
this, the program needs to know where the name is in the record. All records
must, therefore, have their name fields in segment number one, and segment
number one must always be declared as a string segment, code one.
In many paper files, some records have more "sheets" than do others. If a data
is present for only one record, and is foreseen to be available for or
pertinent to few others, it should not be included in the datafile.
To know what information to include in your datafile, you need to know how your
computer works. In general, computers are neither intelligent nor creative.
But they can perform a great number of the same operation, using different data
for each, at frightening speed. And, they can store huge amounts of data in a
Let's say that you need to computerize your employee file. The paper records,
besides the obligatory information on name, scale, tax status, credit union and
insurance deductions, etc. contain performance evaluations, commendations and
write-ups (disciplinary) for some employees. These "comment" sections of the
employee records can consist of several pages.
In this case, you would not store any of the comments information in the
datafile, but you could place data segments in the datafile to indicate the
presence of, and type of, comments for that employee outside the computer
If you need the portability of the comments as well, have a steno to record
them all on disk, with your word processor, which is designed for this job.
You could place the filenames of the comment files, produced by the word
processor, in the datafile. Then, the package could produce a list of all
comment files on an employee, or a group of employees made by your sorting
The date of the comment may also be considered important enough to be in the
datafile. If it were in the numeric date format used in the sample datafile,
you could produce lists of all employees, having a comment in their files dated
after a certain date. The filenames of these comments could be included in the
datafile, and the disks containing the comment files could then be loaded by
the word processor, and reviewed.
Once defined, a datafile can not be changed. Inevitably, after designing and
entering a datafile, someone will say: "Why don't we put the __________ in,
too?" POWRCOPY will move the data to an expanded format, but this may not be
The usefulness of extra, or unassigned, data segments is not limited to the
addition of pertinent information. While using the BASE program you may find
it convenient to write the results of some computation to disk, for temporary
storage. You will need unassigned, general-purpose numeric segments to hold
the transient data.
In the case of permanently resident data, added after datafile design, the
HEADINGS.SAD file can be loaded into any word processor that will read and
write a pure ASCII file, or modified with the EDLIN program included with MS-
DOS, to change the name of an unassigned segment to reflect the added datas'
Upon loading the new file, the programs will reference the segment by the new
name (25 CHARACTERS OR LESS!!!!)
Another use of unassigned segments is for flags. A flag is a message that is
left in the record, to indicate whatever you like. A valid example of flag use
is to identify newly entered records, so that they can be sorted into the
survivor group after entry, to be processed in some manner. Provided that the
numeric format of the entry date of the record to the datafile is not included
in the record, (it seldom has any relevancy) there is no way for the operator
to identify the newly entered records from records entered ten years ago.
An unused segment is selected as the flag, and when records are entered, the
value held in that segment is set to a pre-determined value. After the new
records are entered a sort is done to detect the presence of the flag value in
the flag segment. Only the flagged records are included in the survivor group,
for exclusive processing of any type you wish.
You must, of course, reset the flags to the "off" state when you are finished
processing, in order to prevent the newly entered records you have completed
being included in the survivor group, the next time the sort for active flags
If you combine the formats of flag and code, you can leave a very great number
of messages, meaning anything you wish, in a two byte string segment. But,
with the almost infinite flexibility of a program that allows user-designed
flagging processes, you also inherit the responsibility of keeping track of it
all. We recommend you start simple.
In general, the more time taken to design a datafile, the more useful it will
be. You will have a lot of work to do, entering the records. You should take
time, now, to maximize the return you will get from your investment.
When you are ready, start the DBSEMAKR program. It is #5 on the menu of the GO
program. If you have a floppy-based machine have the target disk ready to
receive the datafile definition files.
The datafile definition will be written to the chosen directory when you
finish. Now, you enter the records by starting the BASE program, and loading
the new DB.
INITIAL RECORD ENTRY:
After typing for a week, you are the proud user of a bouncing baby datafile.
To cause baby to mature, print off the entire datafile after entry. Check all
entries, including the four made by Tess whilst swooning for Bruce Springsteen
playing on her contraband walkman. Baby bases are real cranky. If you fail to
"potty train," be prepared to cleanup ungodly messes.