&
- A Cautionary Tale by Tim Cook
- Ideas from Users by J. Steele, B. Wills, R. Smith, D. Grant, and M. Ellis
- Troubleshooting
- TMG as a Research Tool by John Lindley
- What Next? by Cliff & Lynn Watts
- Recording Census Data by Bob Kingsley
- Census "Birth" Dates
- Census Codes by Thomas Gull
- Tips
- Custom Report Writer:
| Maine Genealogical Society/Maine Historical Society | South Portland, Maine | June 21-22, 1996 |
| Federation of Genealogical Societies | Rochester, New York | August 14-17, 1996 |
| GENTECH Conference | Plano, Texas | January 24-25, 1997 |
| National Genealogical Society Conference | Valley Forge, Pennsylvania | May 7-10, 1997 |
We've been so busy with TMG for Windows that we've let the schedule slip for TMG News. In an effort to catch up, we're making this a double issue, jam-packed with 16 pages of helpful hints and tips written by other TMG users and technical support personnel. Pull up a chair and learn about all of the things you didn't know TMG could do!
We are now accepting advance orders for TMG/Win, which is expected to ship in July, 1996. The retail price is $129.00, and an update from any previous version of TMG is $30.00 (requires serial number). Prices exclude shipping. Orders can be placed by calling 1-800-982-2103, fax to 410-379-5424, or by e-mail to 76366.1760@compuserve.com.
As a reader of TMG News, you are among the first to hear the inside scoop about a technology transfer agreement between Wholly Genes, Inc., of Elk Ridge, Maryland, and Progeny Software of Nova Scotia!
Industry watchers know Progeny Software as the makers of PAF*Mate, a fabulous charting program for users of Personal Ancestral File (PAF). More recently, Progeny Software has announced a similar product, GED*Mate, which makes the same charts available through a GEDCOM file transfer. These products generate the most amazing wall charts, drop charts, and fan charts in a wide variety of formats and support any Windows-compatible printer or plotter. You've got to see them to believe them!
TMG's Custom Report Writer (CRW) has been recognized as one of the most powerful and flexible on the market. Its extremely customizable narrative reports with professional source citations and direct output to word processor formats are unmatched in the industry! That's why we're so excited about our alliance with Progeny Software--to make the same high standards available in the form of presentation quality charts! Watch your mailbox for the TMG/Win upgrade announcement, which will also include details about a joint promotion!
Return to Table of Contents.
Timothy Cook
Northern Cheyenne Reservation, Montana
Greetings, All!
At the end of April I posted a note to the VA-ROOTS mailing list asking about my SALYERS and DEAN families.
Three weeks ago I got a marvelous message that began "you might be interested in this." Well, this fellow had sent me info on my g-g-grandmother and her ancestry. This had been a real hard nut for me to crack, and all of a sudden the dam broke and I have been on a great ride for the last few weeks.
Throughout this, several people kept telling me to contact a certain researcher who had lots of info. Today I finally was able to make contact, but unfortunately he had died recently. His widow was very nice and as helpful as she could be.
Now here is the real kicker. Her husband had put all his stuff in the computer, but she has no idea how to even turn it on! There sits this computer full of information, and no one there knows how to access this treasure. She has file cabinets full of papers, but no idea as to what they are.
This has taught me a valuable lesson. Tonight my wife will begin computer lessons, and she will go through my files with me. This is the only time I have ever told my wife she will do something, but I do not want some researcher calling here and finding the same thing!
Tim Cook in Big Sky Country!
Return to Table of Contents.
Jeri Steele responded to a question about keeping track of correspondence:
I have used two different ways: one is to attach research tasks to the person; the other, if I am going to have lots of correspondence with an individual over a period of time, is to enter that person into TMG just like any other person. Then I add a new tag with the name "Correspondence": When I receive a letter, I add the date and attach a transcription or highlights of the letter as an exhibit to each 'event.' That way I can also add an event for the address. Another possibility is to add an "Associated" tag to tie my correspondents to the various ancestors mentioned in the letter.
Benson Wills suggested:
When corresponding with parties or organizations not in your data set--about general information, not about a particular individual--attach a research task to your own name. For example, I wrote a letter to the LDS about getting technical information on submissions to Ancestral File, and I wanted to document when the request was made and the address it was mailed to.
Robyn Smith has another idea:
Using my TMG database, I record the name and address of my correspondents. I have tags called "Letter-In" and "Letter-Out," where I keep a brief record of each letter sent or received as a memo. I have a flag called "Correspond," which defaults to N for most people in the data set but is set to Y for my correspondents (who may or may not be relatives) so that I can search for them. Finally, I give my correspondents a Reference relating to the surname of mutual interest.
Dick Grant explains his method:
I struggled with this question until I discovered that you can enter the date with a following question mark. Thus:
ca 1855 in my records means "about 1855," as estimated from a census record, etc., and accurate to about +/- 1 year with a surety value of 1.
ca 1855? in my records means this is a wild guess, which may be off by several decades with a surety value of 0.
I found this handy when doing a search for people when the list contained only birth and death dates, as in the TMG search function. I could also prevent the ca 1855? date from printing if desired by selecting only surety 1 or higher.
At present there is no way to sort Research Tasks by task name or keyword. The next release may change this, but in the meantime, Mary Ellis has found a workaround. She says: I assign a Search Number beginning with 1000 and input that number in the "Designed" date field, which accepts it as a year and sorts on the Date Designed (default) field. (Pending tasks will all be given the number 1000). The down side is that when I reach 3001 (my Search Number 2001), it won't work, as the date field won't accept years below 1000 or above 3000. However, the highest Search Number I have at this point in time is 600 (1600), so it'll be a while before I top out.
Return to Table of Contents
You may sometimes receive one of the following error messages when you attempt to back up your data set from within TMG:
Backup Aborted: Error Opening Work File
or
Backup Aborted: Insufficient Memory for Backup
These messages indicate that the work file couldn't be created. One of the following is likely to be the case:
1. The "work drive" specified on the File-->DataSet-->Backups screen does not exist, or
2. it has no disk space, or
3. there is insufficient conventional memory to run the backup routine.
Note that "work drive" does not mean "destination drive." It is the drive on which temporary work files will be maintained. It is a common mistake to specify a floppy disk drive letter there--so that the work files and destination file are saved onto the same floppy. That makes it very easy to run out of disk space during a backup.
In the event of any error backing up, TMG then suggests: Alternative Backup Method: Run BACKDATA directly from the TMG program directory. This is a fall-back position until you can resolve whatever is causing the backup to fail from within TMG. You can always back up your data by going to the C:\TMG1> prompt and typing "BACKDATA". You will then receive more specific instructions.
Return to Table of Contents.
by John Lindley
Woodside, California
Val D. Greenwood[1] makes the argument for collecting "all information relating to all persons of the surname of interest in the locality of interest." If you follow his recommendation, you will rapidly acquire a variety of records and notes which may not have any obvious connection to your family at the time of collection. Can you store these notes in TMG for later review and association when you find the connection to your family? Yes, you can, if you use a few tricks.
We all know that TMG is an excellent family history database and report formatter. We can enter an individual's data without limitations, and we can use the extensive filtering capability to generate many detailed genealogical reports. Normally, the information we enter is family relationships and events in the life of a specific individual. In times Bc (Before computers), we would record the notes on family group sheets or hand-written research notes in files or binders. Now they are easily entered into the TMG Person View.
The Person View is a chronological list of tags which are events or relationships associated with that specific individual. Thus the Person View is like an index to all the tags that reference that individual's ID# in the tag's primary or witness fields. A tag can be an event such as a birth, death, or land grant in which the information is contained in that tag. A tag can also show an association or relationship with other people through the second Principal ID#, the parent tags, or the witness fields.
But how do we use TMG when we don't know who the specific individual is? The trick is that a Person View does not have to refer to a Person. TMG, as a tool for genealogical research, can be used to catalog more than just people. For example, I am searching a line where there is a large amount of information. Also, there are many people with identical names that I cannot connect to my line with certainty, but I need to collect and catalog the information for further reference. The information is in many different forms, including:
- miscellaneous data, like indexes to deeds, where only the surname is shown;
- individual records, like deeds and court cases, which list a person's name but do not include genealogical relationships;
- fragments of family relationships like wills; and
- complete genealogies
To use an example, my oldest known ancestor in the Patterson line is Robert, born about 1775, who was supposed to be in Cynthiana, Harrison County, Kentucky, in the early 1800's. There are many indexes to early Kentucky events. One reference[2] has 36 land grant entries for Pattersons, 15 of which are Roberts, and eight have no given name at all. Obviously interesting information, but not enough to connect these Pattersons to my family without further research. I have each of these land grants entered as tags in a "person" called "Patterson Kentucky Land Grants." In effect, this is a chronological index to all the Kentucky land grants I have entered. For those cases where the given name is shown, but no relationship is known, I have a "person" named like "Robert Patterson Data," where "Data" is the name suffix. The land grants and other records involving a Robert Patterson are put in that Person View with all the detail and citation in an appropriate tag. This view is an index to all data on the Robert Pattersons who are not associated with some family tree. In this example, Principal 1 ID# would be for "Robert Patterson Data" and Principal 2 ID# for "Patterson Kentucky Land Grants."
As in a normal Person View, the tags are all listed chronologically. Highlighting a tag and pressing <Enter> gives me the tag information and citation. Pressing <Ctrl>+P jumps between the two Person Views, and I can rapidly review and compare the two indexes. Indexes (Person Views) can be defined for any grouping of tags that would help in locating your research notes. The ID# of the index can be placed in one of the two Principal fields or as a Witness to the tag.
Why use the Principal instead of the Witness field? If the Principal field is used, highlighting the tag and pressing <Ctrl>+P will jump to the other Person View. This works in both directions. But if the Witness field is used, <Ctrl>+P can be used in only one direction--from the Witness' Person View back to the Primary Person View.
Similar techniques can be used to index Person Views. For example, I have a "Person" named "!Miscellaneous People Data" (the "!" puts this at the top of the Picklist). A tag connects all the "Data" people into this one index (People View) so that they can be rapidly found. I use the "Association" tag with one Principal being the "Data" person and the other the "!Miscellaneous People Data." A surety of "0" prevents the association tags from printing on my formal reports.
Another example is an index to catalog the Patterson genealogies and will fragments that are presently not connected to my family. Over the years I have found many published Patterson genealogies which start before 1775. I have copied them into TMG--at least up to the point when Robert was born. I created an index to the various lines by making a fictitious person named "The Patterson Families." The surname is "Patterson Families" and the given name is "The." Then I use the Association tag, with one Principal ID# being the oldest ancestor in each line and the other ID# being for "The Patterson Families." This gives me a Person View which shows all these genealogy fragments, and I need only highlight an item and press <Ctrl>+P to jump to the oldest member of that family line. Conversely, in the oldest member's Person View, highlighting the Association tag and pressing <Ctrl>+P jumps back to "The Patterson Families." This works very much like the hyper-text links on the World Wide Web. You can think of these indexes as permanent filtered picklists.
When you finally have enough documentation to establish a connection to your line, it is easy to transfer the tag. It is necessary only to go to the tag or person and change the ID# from the fictitious person to your real ancestor. The data and citations are already in the TMG database.
The use of TMG as a database for subjects other than people did not originate with me. There was an online discussion about a year or so ago called "Are places people?" The researcher was trying to compile all of the residents of a small town and a chronological list of home occupancy. He made each house a "person" and then listed each family that lived there as tags to that house. [Editor's Note: See also Paul Harris' article in TMG News, Volume 2, No. 1 (March, 1995)--Using Places as Subjects (tracking the history of a college) and Bob Kingsley's article on Recording Census Data in this issue.]
By the way, in the last couple of weeks I have reviewed some original documents from Cynthiana which established a connection between 2 wills, deeds, court records and a pension deposition. They combine to show that Robert's father was Samuel Patterson who married Catherine Patterson from Harford County, MD.
________________________________
[1] Val D. Greenwood (1990). The Researcher's Guide to American Genealogy. Baltimore: Genealogical Publishing Co., Inc., p. 52.
[2] Willard Rouse Jillson, Sc.D (1969). Old Kentucky Entries and Deeds. Baltimore: Genealogical Publishing Co., Inc., pp. 137-138.
Return to Table of Contents.
by Cliff & Lynn Watts
Westborough, Massachusetts
One of our enduring genealogy laughs came from the polite, innocent comment of an unaddicted relative: "I'd love to see your work when it's all finished."
We aren't researching a single line, a finite period, or a tight geographic area. Nor are we facing a publication deadline or tiring of our hobby. Our two ancestries intersect about a dozen times in early New England. Our younger son's wife added a new cluster of interwoven colonial roots. We pursue information, perspective, and entertainment by examining any and all siblings. At this point (June, 1996) our single TMG data set holds 23,000 people. Our innocent kinswoman is in for a long wait!
Working in this far-flung landscape, both independently and collaboratively, we quickly came to appreciate Research Tasks. The longer we've used this unique facility, the more we consider it an invaluable, yet oddly under-emphasized, TMG treasure.
A casual look at the sequence of tags in some Person Views has often been enough to rattle our fillings. We've had no ancestors precocious enough to earn PhDs at age four. Nor did any of our grandmothers bear two children separated by five months. Many such blatant errors (often typographical) can also be detected by TMG's Audit Report. Each demands some attention, and many need further investigation. For the latter, pressing F12, then F4, takes us directly to the Task Entry Screen.
We don't personally use all of the facilities available. In most instances, a few directive words such as "Recheck the birth dates of Simon and Elizabeth" are all that we enter before pushing F10. Once in a while, some memo elaboration seems necessary, so we follow the "headline" with a press of F7 and create whatever amplifying text is helpful.
Because most of our research sites are within a reasonable radius, we seldom use the Keyword line, preferring to carry a full list as we wander within New England. If we were facing longer, more focused expeditions, then a list of incomplete tasks containing a specific keyword would make sense. Lynn has an upcoming jaunt to St. Louis and southern Illinois, for which we'll isolate the open problems in that area and create a specific list.
The list just mentioned is a simple CRW report. At some point we created a "List of Tasks Open as of ______." Because we delete completed tasks, we specified that it include all tasks. The <Setup> screen options called for including Memos and Event Memos and specified sorting by Type and Name. This gives us a reasonably alphabetized listing compact enough to carry and use in the field with our traveling notebook PC. It becomes increasingly messy as we cross out completed tasks. To update it without a full reprint, we specify a List of Tasks with a filter for Designed Date later than the date of the original list.
This is probably the crudest form of Research Task use. Even at this level, the fact that we don't lose sight of problems and that they are readily transportable is TMG's real cost justification. We've saved TMG's price several times over by being able to resolve an entire group of related puzzles in a single trip.
Since TMG users seem almost obligated to develop new wishes, we see at least one weakness in the way Research Task information is currently handled: the stages appear overly limited. It would be nice, especially in Planned and Progress (but probably throughout) to be able to enter multiple dates and multiple memos if we are investigating and eliminating one source after another at different places and dates. A chronology of such information can, of course, be buried in the existing Memo (as we used to intermix and bury all sorts of things in PAF Notes), but this flies in the face of TMG's general spaciousness. Until Bob has more free time, we can live, rather happily, with the present tool set.
Return to Table of Contents.
by Bob Kingsley
South Bend, Indiana, TMG User's Group
For the genealogist, census data are seminal information. In the United States after 1850, these data provide snapshots of family composition, relationships, and residency. Furthermore, an individual's year of birth can be estimated, and the decade of death can be deduced in certain cases. Few sources give as much information and are as readily accessible.
Census data can be difficult to manage. A single individual may appear in six or eight different US censuses, as well as in a number of state censuses. Furthermore, if one is researching several lines, one may gather census data from dozens of different reels, representing information from many states and counties. Using TMG to record census data provides an excellent example of how a well-designed database manager can be used as a research tool, as well as a repository of information. I developed a system for census data management that works very well for me, and I hope others will find it useful. I am sure that this system can be improved and I encourage everyone to experiment.
1. Enter Each Census as a "Person"
The first step in census management is to create "people" for each census. For example, the 1790 and 1800 US censuses would be entered:
Given Name: 1790 US Surname: Census Birth: 2 Aug 1790
Given Name: 1800 US Surname: Census Birth: 4 Aug 1800
This method is not limited to the US Census. For example, the 1795 New York census would be entered as:
Given Name: 1795 New York Surname: Census Birth: 1795
By entering the censuses in this way, they all appear in the Picklist under the surname "Census" and are ordered chronologically. This makes it very easy to find a particular census. The "birth date" of the census corresponds with the official date for which the information is supposed to be accurate. This is very helpful when trying to estimate the birth year of a listed individual. For example, suppose John Doe was born 30 Aug 1800 and Jane Doe was born 30 Apr 1800. The "birth date" of the 1850 census is 1 Jun 1850, so John would be listed as 49 years old and Jane 50. Knowing the official date of the census can help you reconcile census data with data from other sources.
2. Create a Source for each Census
Citing and maintaining a source bibliography is what separates good genealogical work from hearsay. Therefore, it is essential to maintain census sources carefully in TMG. Simply stating that John Doe was found in the 1850 US Census is insufficient: your readers need to be guided to the state, county, reel, and page number. However, making a separate source for each page, or even each census reel, soon becomes unwieldy, so I have chosen to organize my census records by state and county. In the citation detail, I note the reel number and page. For example, the 1850 US census for Lynn, Massachusetts, would be entered as follows:
Abbreviation: 1850 Census--MA, Essex, Lynn Full Title: 1850 US Census--MA (Essex) Lynn Default Surety: 2
Entered in this way, all the census citations appear together in the Master Source List, arranged chronologically and sorted by state. The default surety of 2 is chosen because much of the census information is not primary data. People often lied to the census takers about their ages. It can be quite amusing to note how someone's bisth year changed over the years if you look only at census data.
Relationship information, when it is present, can usually be taken as primary (surety level 3), particularly for the direct family relations of wife and children. Strictly spe taker had no direct kaowledge of the relationships but was only reporting what s/he was told (like age). The only truly primary information on the census is the residency of the people and the date, since the census taker did have direct knowledge of that.
TMG te the repository in which you found a source. Since the US census is so ubiquitous, I never set up a repository for it. This is certainly not true for state and foreign censuses, however, so I do set up a repository in those cases.
3. Entering the Census Data
With this system, the key to entering census data into your TMG data set is to make an individual a witness to a census. There are two ways to do this.
a. The most direct method is to bring up the appropriate census in the Person View. Add a "Census" tag (from the Tag Types List) and fill in the appropriate location information. I use only the year for the date of the tag, although the birth date of the census would be appropriate, too. Enter the source and, in the detail window, add the reel and page numbers. Set the sureties of the date and place to 3. Now go to the Witness window and add, as witnesses, all the people you found in that census on that reel and page. Exit the Tag Entry Screen to get back to the Person View and see what you have.
You will note that the census tag appears with the date and location as you entered it on the Tag Entry Screen. After you have entered several census tags for the same census year, you will note that all data that you have gathered for that year from all states and counties appear together in one place. This is a great help in keeping track of what census data you have gathered.
Now check the Person Views for the individuals you entered as witnesses to the census. You will note that exactly the same information appears in the individual's Person View as appears in the census's Person View. Open the individual's census tag, and you will note that at the top of the page the number of witnesses is indicated for that particular tag (not all the witnesses to that census year). If you have entered more than one person, you can open the Witness window, and their names will be displayed. In this way it is easy to see who was living in the same household with this individual at the time of that census. Very handy.
b. The second way to enter census data is from the Person View of the individual you are working with, rather than from the Person View of the census. Again, add a census tag for this individual, but when the Tag Entry Screen opens, change the "Principal 1" entry to the ID number of the census (use the Picklist), rather than the individual person you are making a witness to the census. Fill out the rest of the fields the same way as described above, making this person a witness. This method is easier if you are adding a lot of new information for one person because it saves you the trouble of having to jump to the Person View of the census.
You may want to modify the default sentence structure for the census tag if you use the narrative form for output. To do this, open the Tag Types List and highlight "Census." Press the edit key (F5), which opens the Tag Definition Screen, and modify the sentence structure. First, insert two hyphens (--) in front of the default sentence in the first line labeled "Sentence." This will prevent it from printing, since it doesn't make any sense to create a narrative for a census "person."
[** CORRECTION ** (from a later edition of TMG News)
This is in error. It is not necessary to exclude the sentence from printing, since it would print only if the principal (in this case, the census being recorded as a person) were the subject of the report, and ordinarily, that would not be the case. Inserting the hyphens has the effect of suppressing the witness sentences also - an undesirable result. Please ignore that advice. ]
Replace the "Witness Sentence" with:
[W] appeared on the [P] <in [L]> <and [WO] were living in the same household>
which will read:
John Doe appeared on the 1860 US Census in Cincinnati, Hamilton County, Ohio, and Jane Doe, Jimmie Doe, Mary Doe were living in the same household.
We can carry this system a step further by creating a tag that will allow us to enter census data that were searched for but not found. To do this, create a new tag. Open the Tag Types List and highlight the "Census" tag. Press the F4 key to add a new tag based on the census tag model. I call this new tag "Census--Not," since I want it to be alphabetized next to the regular census tag. The abbreviation I call "Cenx" and the GEDCOM label, for what it's worth, I also call "Cenx." Again, place a double hyphen in front of the "Sentence" line to prevent it from printing and replace the "Witness Sentence" with:
[W] did not appear on the [P] <in [L]>
Summary
I have found this method of recording census data useful for several reasons. First, it is easy to navigate to the census data from the Picklist because all census data are listed there in chronological order. Once in the Person View of the census, it is easy to determine which censuses have been consulted for that particular year. For any particular state and county, it is easy to find individuals for whom I have census data and just as important, find people who, for some reason, have failed to appear on a given census. From the Person View of an individual, it is easy to see who else was living in the same household at the time of the census. It is also easy to see if that person has not shown up on a census.
This method also illustrates the principle that the computer, with its database manager, ought to be a research tool, as well as a repository of information. It becomes a tool when it facilitates one's ability to see new connections between pieces of data that are collected at different times and under different circumstances. In this example, when you collect new census data, this method almost forces you to re-consider the census data you have already collected in light of this new information. It also makes it very easy to review and re-think family relationships as revealed by census data.
Return to Table of Contents.
(from Croon, E. A., Unpuzzling Your Past, Cincinnati: Better Way Books, 1995.)
1790--1810 (appears to be the first Monday in August):
- 2 August 1790
- 4 August 1800
- 6 August 1810
- 7 August 1820
1830--1900:
- 1 June
1910--1940:
- 15 April 1910
- 1 June 1920
- 1 April 1930
- 1 April 1940
by Thomas Gull Rockville, Maryland
An approach of possible interest for census tags: I've wrestled with the fact that individuals besides Head of Household (HOH) aren't listed by name in censuses prior to 1850. It's obviously useful to try to assign a child to an age category for earlier censuses, but the census tag by itself implies that the person is there under his/her own name. To make the reality clearer, I built the following tags:
| Census HOH | Head of household, mentioned by name (1790 on) |
| Census Spouse | Spouse of HOH, mentioned by name (1850 on) |
| Census Child | Child of HOH/Spouse, mentioned by name (1850 on) |
| Census Other | Person mentioned by name but not child of HOH (1850 on) |
| Census Implied Spouse | Spouse of HOH, implied by a hit in an age bracket (1790-1840) |
| Census Implied Child | Child of HOH, implied by a hit in an age bracket (1790-1840) |
| Census Implied Other | Person implied by hit in an age bracket, but not a child of HOH (1790-1840). Example: grandchild known to be living with grandparents. |
On the Person View, you can tell rather readily what type of census entry applies to a person in a given year. I also modified the sentence structures to include the status. I put some important extra data for each person in the memo field. In the following examples, "xxx" is the location.
Cs as spouse of HOH in 1850 at xxx, age 35, she/parents b. Pa.
Cs (implied) as child of HOH in 1840 at xxx, 1M<10.
An unexpected side benefit of this style of tag is that it becomes fairly easy to spot the decade when a person left the parents' home.
- It is not commonly known, but in any alphabetical list, such as the Picklist, you can click on the space between two columns to widen them--even so that they are wider than the screen. You can also click on the title of each column and drag it left/right so that the columns are in a different order.
- You can press <Ctrl>+<Enter> as shorthand for selecting a screen button with double brackets <<Like This>>. The double brackets usually surround the most common or likely selection.
- If you have lost the "*SAMPLE*" report definitions and would now like to refer to them again, you can restore them by running Install, choosing Partial Installation, and Sample Reports. All of the sample reports will then be added to the current list.
Return to Table of Contents.
It is no secret that we haven't done a good enough job publicizing the flexibility of the Custom Report Writer or explaining its many features to users. We frequently hear (online) users tell other researchers how much they love TMG but that they export to another program to print reports because, for instance, they think TMG prints only in Courier!
There are several possible reasons why some people haven't discovered the power of the Custom Report Writer:
- TMG v1.0 set new standards of data entry and source documentation--but it had weak reports, and that reputation sticks with us. Two years later, TMG's report writer is arguably the most powerful in the industry--but many people just haven't heard the news!
- Many people are not accustomed to (or don't see the value in) a list of user-defined report configurations. They see a list of reports and assume that it represents everything that TMG will do.
- For some, the report options are buried too deep in the program. Others can't seem to escape them and complain that there are too many of them.
- The default reports are tailored for compatibility across all printers--and they don't do the CRW justice.
- The Reference Manual was printed before many of the best CRW features were finished, so one has to look in the addendum file (ADDENDUM.DOC) to find them.
Those who immediately grasp the layout of the CRW are usually off and running and printing great-looking reports. But few realize how much is still under the hood.
The line between flexibility and ease of use is a fine one to walk, and in that area we haven't done as good a job on the CRW as in the rest of the program. The interface of the CRW is being redesigned for v2.0 (especially for TMG/Win), and we are re-writing the manual, creating more sample reports, and designing new promotional material which highlights TMG's report-writing strengths. And the word is starting to get out.
We're considering a "TMG Slideshow II" which concentrates on the CRW--with perhaps one interactive "lesson" each for filters, printer setups, and word processor output, as well as one for each major report type. The original slideshow demo got rave reviews, and many people still learn from it after using the program for a couple of years. It seems to be a good way to learn the program.
In the meantime, we dedicate the second half of this News to a number of ideas and answer a number of questions that have arisen with respect to the CRW.
Return to Table of Contents.
Q: On my descendancy report a few people, represented by lines, are in the right place, but their names are omitted.
A: This is surely caused by a particular combination of options.
1. "Surety threshold" is set too high or does not "Include Blank Surety." (These are options on the report <Setup> screen which you can access by pressing F5 twice from the CRW Log.) This will cause TMG to not report names and other data which do not have citations with surety values meeting the threshold you specified.
Normally, this will cause the report to say things like "unknown person" to fill in the gaps. Unless you also turn on....
2. "Blanks for missing Data." This will cause it to print...well, blanks for missing data--including those which are "missing" because they failed to meet the surety threshold above.
Q: I printed out a Descendancy Narrative, asking for place elements. In some instances where no place data have been entered, the report prints "(an unknown value)" where the place should be. How can I avoid this?
A: The only time "an unknown value" prints is when the sentence structure calls unconditionally for a place (i.e., [L]) and there isn't one. If the [L] is enclosed in conditional brackets (i.e., <[L]>), then the absence of a place won't have any effect on the sentence.
The controlling factor on an unconditional variable should be whether the place is known. For that, any part of a place will do.
Q: When I print out genealogy reports with children whose birthdates are unknown, I sometimes get:
Children of Adam Brown and Cecily Drake are as follows:
i. Eve; born.
ii. Frank; born.
iii. George; born.How do I set it up so I don't get "born" after the child's name?
A: You will probably find that the memo fields for these events contain a carriage return which, while not visible, is enough to trigger the printing of the event. Be sure to use the <Tab> key rather than <Enter> when scrolling through the fields on the Add-Person Screen. If you were to get into the memo field and press <Enter> there, then a carriage return would be inserted into the memo. That would qualify the event for printing, but since it wouldn't print anything visible for the memo, it would just say "born."
If that's the case. then outputting to a word processor would show carriage returns in those spots. Running Util --> Advanced---> Strip Trailing Carriage Returns would fix it. (It's not a bad idea to run this feature periodically to forestall problems.)
Another instance where "born" is printed with no other information occurs when there is no information about the birth event except an estimated date with a surety of "0" and the surety threshold is set higher.
This is by design since, in many other circumstances, people may want the event to print, even if none of the conditional variables produce any data. For example, "He served in the military." or "He was lost at sea."
The birth event is printing because the principal surety meets the threshold. Then the date doesn't print because it doesn't. If you want to control the printing of the entire sentence based on the surety threshold, then you can make the principal surety "0" as well.
Q: I can't get certain events, such as immigration, to show on my report.
A: Go to the report <Setup> screen (from the Log, press F5 twice) and then PgDn to page 2 to make sure "Events" is set to "All Variations." If immigration still does not show up, then check for another option (like "BMDB Only" or "Surety Threshold") that would suppress it.
Q: I would like to include the Zip/Postal Code in sentences for address tags. But the [L] sentence variable does not include it. How can I get it included in reports?
A: All you need to do is to check the <Postal Code> box on the report setup. The [L] sentence variable includes all the place fields, but only those that are checked in the setup pages will print.
Q: Because I'm using some sources as catchall sources (i.e., "Membership Card") and enter the date, etc., in the Citation Detail, I'd like to enter "[CD]" in the Override Bibliography field and remove "n.d.,". When I tried to do this, my List of Sources (Bibliographic) printout showed "[CD]," rather than the actual text I had entered in the Citation Detail.
A: "[CD]" isn't supported in the bibliography field. That is because a bibliography is a list of sources but the citation details ([CD]s) are citation-specific. That is, there could be hundreds of different citations--each one with a different [CD]--for any one source. The program would have no way of picking a particular citation detail from the lot.
If you define your sources that way, then it seems that you don't want a bibliography or list of sources at all--but a list of citations.
Q: I've used an Occupation tag and put the information in the memo. But the memo doesn't print.
A: On the Job Manager, make sure that you have [X] Memos/Sources checked. Also, check the setting for memos on that <Setup> screen to be sure that [ ] None is not checked.
(See also the first question and answer under "Formatting" below for more missing information: names in an index.)
A "|" (vertical line) is used to distinguish the two halves of a conditional variable in a sentence structure (e.g., "[P] <was|were> employed..."). If this vertical line is used in a data-entry field (e.g., "Lieut.|Capt."), it will cause information to be omitted from a report. Don't do it!
Q: Is there an easy way to handle a place such as "near Atlanta" in a genealogy report, so that it doesn't print "in near Atlanta"?
A: TMG inserts a preposition only if the "[L]" is alone inside conditional brackets (i.e., "<[L]>"). You could make it "<near [L]>", but that would sacrifice the "near" in other non-narrative contexts. It would be best to just make it "[L]". That will print it exactly as it is in the place field--without an additional preposition.
Q: Why do arrows appear at the end of my memos when I press F10 to save--and then print out on reports?
A: Mary Lou Bailey found the answer to this problem by diligent trial and error. If "Add Ctrl-Z" is selected in Preferences in the Edit Text menu, arrows appear when you save a memo or alter a sentence construction. Perhaps "Add Ctrl-Z" should not be on the list of choices, but it does do just that.
Q: Why is it that some of the names on my pedigree chart don't show up in the index that is produced?
A: TMG won't index any part of a name that is truncated prematurely on a pedigree chart. That is, if it doesn't entirely print, then it won't index. Under default conditions, this won't happen. But if the "Abbreviate Names" option is turned off, then names/numbers are truncated on the right, and the result is that these names will not be indexed.
How much of the name will print is a function of the horizontal spacing you've assigned to the report and the font styles for given names and surnames. You can get much more data to print in 17cpi, for instance, than in 10cpi. And if you ask for ID numbers to print after the names, then those lines are even longer (the ID number is tacked onto the surname).
Normally, this is not a problem because the default <Setup> option is to "Abbreviate Names." TMG will then abbreviate the name (starting with middle name, then given name, then surname as necessary), so that the whole thing will print in whatever space is allotted--and everything will index! This is the way things are normally configured.
The ability to turn off the abbreviation option is intended for those users who want to print names in a proportional font like Times Roman directly to the printer. Because the text is proportional (and smaller on average), even long names will usually fit. So when this option is turned off, TMG will just print the whole name without stopping to calculate how much of it might "fit."
However, if you tell it to use a non-proportional font (like the default) and then you turn off the option which makes it "fit" (by abbreviating when necessary), then it will surely overrun the allotted space. It would index on given names--but if you tell it to index only on surnames, then any such people won't appear in the index at all.
Any of the following should solve your problem:
- Turn "Abbreviate Names" back on...or
- Use a smaller font(s) so that the whole name prints ...or
- Turn off ID Numbers so that the name text is shorter.
The third option is still subject to breakdown on really long names.
Q: In the printout of a Genealogy Report, the first child has a generation number, and if there is a footnote, its number joins the other, making it look like a dual number. How can I take care of this?
A: The problem is fundamentally that generation numbers and footnote numbers follow different rules as to when/where they appear. According to the leading genealogical writing guides, the two types of numbers should never be confused because generation numbers come after a given name but footnotes come after surnames (and events, etc.). What they don't recognize is the possibility that there is no surname--as is the case of children in a Register style report. In that case, the two numbers end up right next to one another.
The solutions are:
1. eliminate one of them
You can, of course, disable generation numbers. A better alternative for some may be to suppress footnotes on name records.
2. separate them
The easiest way is to have the report display surnames for children. But that would no longer be in a strict NEHGR format. If that is your highest priority, then you can use the "REFN" setup option in CONFIG.FP as described in ADDENDUM.DOC. With that, you can surround footnote numbers with some text, while generation numbers remain unchanged; for example, "John 2[14]." However, this will affect all footnote numbers--not just those that follow generation numbers. This method also has disadvantages when using certain word processors which don't recognize the numeric nature of footnote numbers which are surrounded by text. If you were to enter a new footnote by hand into such a document, the existing footnote numbers would not be incremented or renumbered to make room for the new footnote.
3. distinguish them visually
You can control the font of footnote reference numbers by using the "Exponent" font style on Page 2 of the Printer Setup Definition Screen. Generation numbers use the normal "Text" font style. You can also specify on the report <Options> screen that generation numbers should print in italics. So, for instance, you can print in Courier 12 with generation numbers in italics and exponents (footnotes) in Times Roman 8 Bold. Although the numbers would still be side-by-side, they would print in radically different styles and should be easily distinguishable.
Q: When I choose Times Roman, dates crash into the dates/people that follow them.
A: You shouldn't use a proportional font for things that need to line up vertically (like dates in this case). Try setting the "Labels" and "Dates" font styles to a fixed pitched font like Courier. Leave given names and surnames in Times Roman if you like. You might make them bold and a little larger too.
Q: When I print (directly) Family Group Sheets, the information following birth/death/marriage dates begins on top of the final character in the date (the last digit of the year). I am printing on a LJIII and the font appears to be a Sans Serif Helvetica. I could not find any way to edit the spacing of the report to add space after the date. What causes this and how can I avoid it?
A: It sounds as though the horizontal spacing is configured to allow less room than is necessary for the fonts you've chosen.
Go to the Printer Setup (CRW --> File --> Printer Setups > Edit) and check the "Horizontal Spacing" on Page 1. Set the characters-per-inch to a lower number (10/12/17) which will accommodate the larger font you've chosen on page 2.
Q: When exporting a report with endnotes from the CRW to a word processor, I always get a page immediately after the main body with nothing except the header "Endnotes." Then there is a skip to the next page, where the actual endnotes begin. I am exporting to Word Perfect 6.0 and to Ami Pro 2.0. Why the blank page?
A: TMG puts the "Endnotes" heading at the end of the document if you asked for endnotes. But whether or not there is a page break is a function of whether your word processor is set to start endnotes on a new page. (Be sure that it is a page break, not just a section break. The latter may be visible on the screen but have no effect on printing.)
Q: In a large database (about 7.5 Mb) which was mostly imported from PAF, with many notes, when I open a memo, the memo text does not wordwrap but sits there in one line and scrolls left or right as the cursor is moved through the text.
A: The solution to this problem lies in Edit-->Preferences when you're in the Memo itself. Set "Wordwrap" to "On" and specify that as the standard default, and all should be well.
Q: Has anyone figured out a combination of fonts and line spacing that will give unbroken lines on a compressed pedigree chart? I am using a HP Laserjet 4P.
A: If they are misaligned horizontally (i.e., the vertical lines for the same generation don't line up), then make sure that you are not using a proportional font.
If they are misaligned vertically (i.e., the lines aren't high enough to touch the ones above), then make sure that you're using a big enough font.
The lines in both cases are controlled by the "laBels" font style.
For the Compressed Pedigree chart on an HPIIIp printer, for instance, here are suggested settings with 17cpi horizontal spacing:
| <Text> | CG Times scalable | ||
| <Surnames> | CG Times scalable | Bold | 10.00 pts |
| <Given> | CG Times scalable | 10.00 pts | |
| <Dates> | CG Times scalable | ||
| <pLaces> | CG Times scalable | ||
| <Memos> | CG Times scalable | ||
| <Exponents> | CG Times scalable | up 3.00 pts | |
| <laBels> | Courier 12 port | 0.00 pts | |
| <tItles> | CG Times scalable | 15.00 pts | |
| <Page numbers> | CG Times scalable | 8.00 pts |
Return to Table of Contents.
There seems to be a fair amount of confusion regarding the different types of reports, as evidenced by such questions as "Why is there no way to set the number of generations on a Family Group Sheet?" and "Why does my Descendancy Chart, defined as 'Is a Descendant of ID Number x,' turn out to have hundreds of records, when I know there are only 87 descendants?"
1. First, there are reports which are centered around individuals. We call those people "targets" of the report, and they may be defined explicitly or by way of a filter. One report is generated for each target person. Most reports fall into this category, including the Individual Narrative, Descendancy Chart/Narrative, Pedigree, Ahnentafel, Genealogy Report, and Family Group Sheet.
Once a report is triggered by the presence of a unique person in the target group, some reports then allow for the user to define how far the report goes--or its scope. An Ahnentafel is centered around a person (Ahnentafel of...) but then may go on for y number of generations, as defined by the user on the <Setup> screen. Likewise, the Genealogy Report is triggered by a single person (progenitor), but the report then goes on to include other people as defined by its scope (number of generations).
The scope of the Family Group Sheet is, by definition, the immediate family--that is, parents and children--so you don't have any control over scope for the FGS. It is triggered by an individual and goes on until his/her entire family is listed. Then it stops and goes on to the next target person. (Actually, the FGS is unique in that a single target person may trigger more than one report if he/she has more than one family, i.e., partner. Don't let that confuse you.)
If you define a filter for these individual-based reports, then you should expect it to go through the entire report generation process for each person in that filter. If you ask for FGSs, for instance, and define the filter as "Is a Descendant of John Smith," then you should expect one FGS for each person (+ partner) who is a descendant of John Smith. That could be a lot of paper.
A common error is to ask for a Genealogy Report and define the target filter as "Is a Descendant of John Smith." While this may seem logical at first glance, it reflects a misunderstanding of the purpose of the target filter. This will cause a complete Genealogy Report to be generated for the first descendant of John Smith. When that's done, it will start over and generate another complete Genealogy Report starting with the next descendant of John Smith--and so on. That will use a lot of trees and be entirely redundant.
2. The second type of report is centered around a group of people, rather than an individual. In this category are the List of People and the Distribution of People reports. For these reports, the targets are handled as a group and generally defined with a filter (e.g., all males born in Virginia). The scope of the report is the filter itself--those people and only those people are considered for the calculations.
For instance, in the case of a Distribution of People report, the "Is a Descendant of John Smith" filter which we used above would trigger only one report. It would list those people and calculate the distribution of some characteristic about them. And then it would stop.
Return to Table of Contents.
A TMG user asked, "I have a woman in my data set whose birth name was Alice Bell Chalmers. She also had a nickname, "Dodie," which she used most of her life. In addition, she had three married names. How will this be handled in the index? Most people would look for her under "Dodie." Would there be an entry for Dodie under both maiden and married names?"
If you don't enter a surname (or any other piece of the name), then it acquires the one from the primary name. This is true for the Picklist and indexes.
So if you have as a primary name...
Given: Alice Bell
Surname: Chalmers
..and non-primary names of...
Name-Nick
Given: Dodie
Surname:Name-Marr
Given:
Surname: Smith
..then the index (and Picklist) would show the following entries:
Chalmers, Alice Bell
Chalmers, Dodie
Smith, Alice Bell
If you want "Smith, Dodie" to appear in the index, then you should create a Name-Var to that effect. It won't automatically take the given name from one non-primary tag and add it to the surname from another non-primary tag in order to index every possible combination.
On the issue of name variations and indexes, here is an interesting point which rarely gets mentioned. If you output everything in a Genealogy Report, then you may get constructs like this:
Alice Bell CHALMERS married John SMITH on 12 September 1842. Her married name was SMITH.
That is, it outputs the event and the name variation records. As the beta testers pointed out, the second sentence is pretty useless, and its presence in the narrative discourages the researcher from recording it in the first place.
So there is an option in the report <Setup> screen to "Suppress Name-Marr from Text" but even when the Name-Marr does not appear in the text for this reason, it still contributes to the index! So the sentence will read:
Alice Bell CHALMERS married John Smith on 12 September 1842.
And the index would show:
Chalmers, Alice Bell
Smith, Alice Bell
So you get the best of both worlds: a clean narrative and a complete index.
[NOTE: If you exclude the Name-Marr sentence explicitly, then it will neither appear in the narrative nor contribute to the index.]
Return to Table of Contents.
While we haven't provided a sample report for every conceivable task, the Boolean operators and recursive tools in the CRW are so powerful that you can do just about anything. Here are some suggestions for filters to achieve results that are often requested, as well as explanations of how filters work.
Q: How can I identify people in my data set who are unrelated to any others?
A: Define a List of People report with the following filter:
Number of children Equals 0 AND Father* ID# Equals 0 AND Mother* ID# Equals 0 AND Number of Spouses Equals 0 END
Q: How can I get a Descendancy Chart that shows how two people descend from a common ancestor, but excluding other lines?
A: Let's call the two descendants A and B and the common ancestor C. Then define a List of People report with a filter like the following (omitting the last column, which is added here for clarification):
( Is a Descendant of ID Number [?] AND C's ID Is an Ancestor of ID Number [?] ) OR A's ID ( Is a Descendant of ID Number [?] AND C's ID Is an Ancestor of ID Number [?] ) OR B's ID ID Number Equals [?] OR C's ID ID Number Equals [?] OR A's ID ID Number Equals [?] END B's ID
Save that report definition with a generic name (e.g., "Extract Common Lines") and run it. (If you use [?] in the third column, you can use the report again later for different people.) Generate the report. When it prompts you, fill in the blanks with the ID number indicated in the last column. (The last three clauses are necessary because C is not his own descendant, A is not her own ancestor, etc. Without those last three clauses, the three targets would not qualify for the compound condition!)
On the Job Manager, direct the output to a "[X] New TMG Data Set" called SCRATCH (or whatever). Then return to the main program and use that new data set. Then you're ready to run the Descendancy Chart with the focus set to C's ID Number. No filter! And you're done.
Q: I want to keep all my records in one data set and have them somehow identified by family. Is it better to create a FAMILY tag within the Name Group or to use the Reference field?
A: You may find that a FAMILY flag is a better solution. Although it is limited to one-letter codes, you can write to it globally from the CRW based on relationships which you specify. Or you can simply run a custom report when needed.
For instance, if you want to do a GEDCOM export of the ABBOTT family only, then you can set the filter to:
ID Number Equals (paternal grandmother) OR Is an Ancestor of ID Number (same) END If you want all of the siblings, aunts and uncles too, then you can filter for:
Is an Ancestor of ID Number (grandmother) END And their [X] Descendant(s) 1 generations. And if you use the "[?]" variable, then you can make generic reports that prompt you to fill in the blanks each time you run them. For example:
ID Number Equals [?] OR Is an Ancestor of ID Number [?] END If you want spouses of descendants, parents of those spouses, etc., then it may take you more than one such filter, run consecutively and output to a custom flag--but unless you perform this sort of function on an hourly basis, you'd probably find that easier than maintaining a FAMILY tag/flag, or using the Reference field.
Q: Why can't I get a List of People report that includes a person and three generations of his descendants, including their spouses?
A: There are two ways to get descendants in a List of People report:
1. Use the filter:
ID Number Equals (ID number) OR Is a Descendant of (ID number) END And their [X] Spouse(s)
or
2. use the filter:
ID Number Equals (ID number) END And their [X] Spouse(s) And their [X] Descendant(s) 3 generations.
Which method you use depends on what result you want to achieve. For instance, if you want to limit the number of generations, you must use the second method.
If you use the first method, then, when the expression is evaluated, all descendants of the original person are immediately added to the list. If you check [ ] Spouses, you will get the spouses of all the descendants. However, checking the box for [ ] Descendant(s) and marking the number of generations can have no effect whatever, since all those persons (and more) are already on the list.
The second method allows you to limit the number of generations, but it will capture only the spouse(s) of the original person, not the spouses of descendants. In order to include those spouses, you must direct the output to change a flag, then run another report for people with that flag changed, plus their spouses. For the report you want, the necessary steps are as follows:
a. if you have not already done so, define a temporary flag (from the Main Menu, Util Menu, Flag Customization), say TEMPFLAG, with possible values ? Y N;
b. from the Custom Report Writer, define a List of People report with the filter as specified in 2. above;
c. generate this report, specifying on the Job Manager that for all people identified by the report, the TEMPFLAG should be changed to Y; d. define another List of People report with this filter:
TEMPFLAG Equals Y END And their [X] Spouse(s)
Q: I defined a List of People report to include all the ancestors of my father, plus their descendants and spouses. But when I generated the report, the spouses were not included.
A: If you define the filter as:
ID Number Equals 45 END And their [X] Spouses [X] Ancestors [X] Descendants
..then it will produce a list that includes person #45, the spouses of person #45, the ancestors of #45, and the descendants of person #45.
I think what you want is:
ID Number Equals 45 OR Is an Ancestor of ID Number 45 END and their [X] Spouses [ ] Ancestors [X] Descendants
If you want the spouses of descendants as well, then you'll need to run one report that writes ancestors to a flag, and then a second which extracts those people and their descendants and spouses. (See also the second half of page 48 in the Reference Manual.)
Be sure to consider exclusion markers and sensitivity brackets when filtering by the contents of data-entry fields.
For instance,
Any Birth* State Equals Kentucky
will fail to find an event where the state is recorded as "-Kentucky". If you want to be sure to find such records, it would be better to search for :
Any Birth* State Ends With Kentucky
or
Any Birth* State Contains Kentucky
Return to Table of Contents.
The following two bugs have been encountered when filtered reports are generated. They do no harm. They will be fixed in the next update, but in the meantime, here are temporary solutions:
1. Fatal Error in FILTCOL module when attempting a report involving a filter.
Under some circumstances, one file does not update properly when the v1.2a installation disks are applied on top of an existing v1.2 installation.
Erase TMG1\ADMIN\FILTCOL.CDX (and nothing else!) and rerun the program. Then respecify the filter (important!) and rerun the report. That will fix it.
NOTE: This problem and solution are limited to those who had a v1.2 installation and purchased the $10 master v1.2a disks. It does not affect those who updated by downloading the patch, and it does not affect those for whom v1.2a was an original installation. If you aren't sure how you updated, however, it does no harm to erase this file, causing TMG to reinitialize it.
2. Message "Interest Flag is not Available to This Data Set" when attempting a report with a filter involving the ANCE_INT or DESC_INT flags.
Descendant Interest will erroneously decline to be processed unless there is a flag called "INTEREST" (literally--not ANCE_INT or DESC_INT). This bug is overcome simply by adding a flag by that name.
NOTE: You don't need to do anything with the INTEREST flag. A filter which measures the ANCE_INT flag will still evaluate correctly. And if you output the ANCE_INT flag, then its values are accurately reflected.
The INTEREST flag just has to exist in order to get past a stubborn guard at the door.
Return to Table of Contents.
Do you know how to...
...add a report to the CRW?
...suppress county names from printing?
...design a simple filter?
...output directly to your word processor format?
If you can answer "yes" to all of the above, then you're off to a good start.
Can you...
...control what is printed on a Pedigree Chart?
...extract a subset from one data set to create another?
...design a filter to isolate John Smith and all his descendants and their spouses?
...add new printer setups tailored to certain reports?
If you can answer "yes" to all of the above, then you are an advanced CRW user.
If you can:
print a narrative report with full justification,
print surnames in one font and given names in another,
generate a marriage index, and
build a cumulative bibliography across multiple reports,
then you are a TMG/CRW expert, and we invite you to write a book or News article (we'll help)!
Return to Table of Contents.
TMG NEWS is an exclusive newsletter for registered users of The Master Genealogist.
The text of this newsletter can be downloaded free from our BBS or at regular online rates from Compuserve (GO GENSUP) and other electronic services.
Hard copy subscriptions are available by U. S. Mail for $15.00 for four issues per year. Add $5.00 postage for Canada and Mexico; $10.00 for other countries.
This electronic version of TMG News may be distributed freely provided that it is copied in its entirety and distributed only in electronic form. Subscriptions are available for printed copies.
Contents © 1995 Wholly Genes, Inc. All rights reserved. The Wholly Genes logo, The Master Genealogist, and TMG are trademarks of Wholly Genes, Inc. All other trademarks mentioned herein belong to their respective owners.
Return to Table of Contents.
Back to Laura's Main TMG Page.
L.A.W. 19 October 2000