home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Share Gallery 1
/
share_gal_1.zip
/
share_gal_1
/
GE
/
GE003C.ZIP
/
SECTION6.DOC
< prev
next >
Wrap
Text File
|
1990-07-08
|
19KB
|
367 lines
VI. Validating System Maintained "Pointer" Information (F3-E)
In order to permit you to place variable amounts of "miscellaneous"
information and comments about an individual in your family files
without requiring excessive amounts of space on your diskette or hard
disk, an individual's information is stored in many "records" distri-
buted among 3 datasets (name, address and miscellaneous information).
All of these records are "drawn together" by a collection of system
maintained pointer fields. You are no doubt familiar with some of
these fields: the mother and father ID numbers in the name record are
two, and the spouse ID in a marriage record is another. There are
many others that you are not (and need not be) aware of. In addition,
each record in the family file datasets has an identifier as to the
type of information stored in the record and the "source" of the
information (whether an address record is an individual or family
residence, for example). It is important that the complete set of
"pointers" and record identifiers for those records relating to an
individual be valid and consistent.
The first record of each family file dataset also has information that
helps the programs determine whether the datasets that you are using
"belong together". This is to protect you from inadvertantly
attempting to enter information into, or produce reports using
datasets that are from two or more family files that you may be
working with at different times. In the ".ADR" and ".OTH" datasets,
these "header records" also have some additional "hidden pointers"
that help the file update program keep track of deleted records.
There are several ways in which inconsistencies may be introduced into
this "hidden" collection of information. Because updated file records
may remain in memory and not be written to disk until the files are
closed (or until you return to the Main Menu program from the file
update program) any interruption of an update session by prematurely
turning off your coumputer or by a power failure may result in
incomplete updates to the system information. Errors in some versions
of the file update program are another (unfortunate) source of
inconsistencies in system pointers (for instance, at one time you
could enter the same ID number for mother and father, which would
introduce errors in the files).
The purpose of the program invoked by Main Menu option "F3-E" is to
detect and correct any errors in the system maintained "hidden"
information. Upon entry to the program you will see that all three
datasets that make up your family file are used by the program. You
also will see displayed some information about these datasets that is
not shown by other programs in the system; this includes the "date of
(most recent) update" for each dataset, the number of records in each
dataset, and the number of "free" records in the address and
Miscellaneous info datasets. ("Free" records are ones which have been
deleted by you using the file update program, thus permitting them to
be re-used the next time information is added to the dataset.) These
dates and record counts are stored in the "header records" of each
dataset and are maintained by the file update program when you enter
or change information in the files. As usual, program option "F1" of
the validation program may be used to respecify the names of datasets
51
to be "validated".
(NOTE: if a family file has been corrupted as a result of an
interrupted update session and a recent backup is available, it is
always preferrable to restore the file from the backup, since
correction using the validation program may result in some loss of
information. If there have been many updates to the file since the
last backup or the file errors are also in the backup copy, then the
validation program can provide a "clean" file for you to continue your
work with minimal loss of data.)
Option "F2" of the validation program is the one that does all the
work. When you select it you will be asked whether error messages
should be sent to the screen or printer, whether you want the program
to make corrections to the files, and which name record ID number to
begin with.
If you get the message:
"Unmatched Files...Do you want to Continue?"
when you select the F2 option then the program has determined that the
"header record" of the ".ADR" or the ".OTH" dataset does not have the
same date or time of creation as the ".NAM" dataset does. This may
happen as the result of a problem with previous versions of the file
update program in which the "date time stamps" in the header records
were not "synchronised" when the files were first CREATEd. In very
early FHS versions, the programs didn't make use of these date and
time fields for determining whether files went together, so you may
not have had any problem until you updated your version of the
programs to one that DID check these values....If you are absolutely
certain that the files you are using DO belong together, you may reply
"Y" and the header records will be "synchronized" during the
validation procedure.
Actually this validation procedure is divided into several phases.
More will be said about what is done in each phase later but they may
be described briefly as follows:
I. Validate information in Name records (this is by far the most
time consuming of the phases, taking perhaps 90% of the total
execution time); this is the only phase of checking performed if
you request to begin with an ID# other than 1;
II. Check for broken "sibling" chains (determine children who are
not "listed" as a child of a recorded parent);
III. Check Address dataset free record chain;
Check for isolated or unreferenced address records;
IV. Check Miscellaneous dataset free record chain;
Check for isolated or unreferenced miscellaneous records;
Check for "partially referenced" marriage records;
V. Synchronise date time stamps in "header" records if files are
"unmatched" and updates are being performed.
The suggested procedure for using this program is:
1. Backup your family file datasets. If none of the datasets
exceed the capacity of the diskettes you use, the DOS COPY
command can be used to back them up, otherwise you will have to
use the DOS BACKUP command (or some equivalent utility) to back
52
them up;
2. Run option "F2" of this program with output going to the printer
and allowing the program to make file changes;
3. Run option "F2" again with output going to the printer...all
program correctible errors should now be gone.
4. Using the file update program (Main Menu option F1), review
information for individuals whose ID# appeared in any of the
error messages.
Some suggestions and comments concerning the use of this program:
if possible, run this program with your family files located on a
RAM disk. It will greatly reduce the time required for the run;
(incidentally, running the validation program against my files,
which contain information on about 1500 individuals, required about
55 minutes using a standard IBM-PC with all datasets on a single
floppy diskette using the interpreted version of the program; it
takes about 55 seconds running the compiled version off the hard
disk of an AT);
a "progress report" is given when you tap the space bar while the
program is processing the name record file (phase "I" above); the
validation procedure can also be interrupted if you press the
ESCape key during this phase of operation.
The remainder of this section gives more detailed descriptions of the
various phases of the validation process. This information is
primarily for my own documentation so don't feel that you have to
understand it to make use of the program.
Before discussing the phases in detail, let's first look at the type
of "identity" information stored in the "prefix" of each address and
misc info record. Each record begins with a 1 character record type
as shown in the "RTYPE" table which follows. (The record types were
changed in the December 1985 update of the system. This program
recognises both the old and new record types, but changes all old
record types to the new type when updating the datasets.) In
addition, the "header" record of each family file dataset has a
leading 1 character file type which is used to check that a dataset
used in one of the report programs has been properly initialized.
This "file type" is also shown in the following table.
TYPE Table: Old RTYPE New RTYPE
CHAR ASCII ASCII
Name record 1 049 001
Address record 2 050 002
Spouse Record 3 051 003
Place Record 4 052 004
Comments F 070 005
Education record 7 055 007
Work record 8 056 008
Military record 9 057 009
Medical record A 065 010
53
NAME dataset N 078 078 (unchanged)
ADDRESS dataset A 065 065 (unchanged)
MISC dataset M 077 077 (unchanged)
In addition, each address and misc info record contains the record
type and record number of the "source" record to which it is appended.
In the error messages produced by this program, the "source record
type" is labeled "SRTYPE" and the "source record number" is labeled
"SRNO". (For example a "family" residence will have SRTYPE=3, the
record type of a spouse record. A comment record attached to an
Education record will have SRTYPE=7.)
I. During "Phase I" of the validation process, each name record is
read successively (beginning with the ID# specified by you at the
beginning) and the following checks are performed:
1. Mother and Father ID
a. must be between 0 and the highest ID# on record (invalid
parent ID's are set = 0);
b. if parent ID>0, sex of parent is checked and discrepancies
reported (father's sex should be "M", mother's sex should be
"F"); no corrections are made since the program cannot
determine whether the sex or the parent ID is in error;
2. Sibling chain
a. the name record for the oldest child is retrieved and parent
ID's checked to make sure that ID# of name record being
validated is either the father ID (FID) or mother ID (MID);
b. younger children's records are retrieved and parent ID's are
similarly verified; (if the ID# of the name record being
validated is not found as a parent in a child's record, the
sibling chain is terminated);
c. if a child's ID is encountered a second time while following
the sibling chain, the "loop" is noted and the sibling chain
is terminated;
d. a note is made of each child correctly located on sibling
chain; this information will be used later for identifying
"broken" sibling chains;
3. Birth/Death Place Record
a. record number must be between 0 and max Misc Rec #;
b. if record number>0 then record is retrieved and record type
and source record information is checked (see previous table
of record types and discussion of source record information);
4. Comment Records for individual
a. first comment record ID must be between 0 and max Misc rec#;
b. if comment records are present, first comment record is
retrieved and record type and source record information
checked; total comment record count from first record is
saved; backward pointer should be 0;
c. successive comment records are retrieved and record prefix
verified as for first record; backward pointer should point
to previous record;
d. after last comment record is retrieved, total record count is
54
compared to what had been stored in first comment record;
(if record type or source record information is incorrect,
the comment chain is terminated; all other discrepancies are
corrected by the program);
5. Address Records for individual
a. first address record # must be between 0 and max addrs rec#;
b. if address records are present, first address record is
retrieved and record type and source record information
checked;
c. successive address records are retrieved and record prefix
verified as for first record;
(if record type is incorrect it is corrected; if source
record information is incorrect, the address chain is
terminated);
d. address comment records are checked (as in 3.)
6. Spouse information
a. first spouse record # must be between 0 and max misc rec#;
b. if spouse records are present; each spouse record is
retrieved and checked for valid record type and source record
information;
c. spouse ID's in the record are checked to see if one
corresponds to the name record being validated;
(if record type or source record information is incorrect, or
ID# is not in spouse record, the spouse record chain is
terminated);
d. if marriage place record is present for any of them, that
record is retrieved and record type and source record
information is checked;
e. spouse comment records are checked (as in 3.)
f. spouse residence records are checked (as in 4.)
7. Miscellaneous information
a. first misc record # of each type must be between 0 and max
misc rec#;
b. if misc information is present, first record is retrieved and
record type and source record information is checked;
(if record type or source record information is incorrect the
chain is terminated for that type of misc info);
c. misc info comment records are validated (as in 3.)
d. misc info address information is validated (as in 4.)
II. After all name records have been individually checked, the record
of all validated parent pointers is checked to see if any name
record was not located on a parent-child chain. (Unverified parent
ID's are set =0 in the name record.)
III. Records on free chain of Address dataset are checked to see if
they have been referenced during Phase "I". Address records which
were unreferenced in Phase "I" and not on FREE record chain are
noted and added to FREE record chain. Count of FREE records in the
address dataset header record is compared to the number of records
on the FREE chain. A discrepancy is noted and corrected.
55
IV. Records on free chain of Miscellaneous Info dataset are checked to
see if they have been referenced during Phase "I". Records in Misc
Info dataset which were unreferenced in Phase "I" and not on FREE
record chain are noted and added to FREE record chain. Count of
FREE records in the misc info dataset header record is compared to
the number of records on the FREE chain. A discrepancy is noted
and corrected.
While checking for unreferenced misc records, the number of
references (during Phase "I") to each spouse record is checked. A
message is displayed if a spouse record was not referenced exactly
2 times. This situation may be correct in the case that a marriage
record was created with a spouse ID=0. This is permitted by the
system to allow for the (unlikely) case that a marriage date is
known but insufficient information about the spouse exists to
justify creating a name record (the spouse name is given as
"(Unknown)" in descendant and family group reports). If both
spouse ID's are shown to be non-zero in the error line produced by
the program, then an incorrect situation does exist. You must then
use the file update program (main menu option F1) to retrieve the
marriage record from the spouse ID that it is accessible from,
delete the marriage record, and then readd it.
56