John, from your reply here, I still think you're "going as deep" as I am. Yes, Karen's situation is much closer than 40 years, or even 20, but the same dynamics apply: Computer programs and hardware get obsoleted. My cousin and I approached "the keeping of the data" and the end of TMG thus: He recruited two of the next generation and bought them each a copy of TMG9. But this is still a stop-gap approach. And a stop-gap approach is really all we can ever do, is my assertion, given the realities of the computer world. Karen's situation is also a bit unusual in its timing. Two years ago, it would have been easy: Buy TMG. Two years from now, maybe (I hope) it will be easy: Buy "Son of TMG" and import the files intact. But the point you're really raising (as I read it) is, what do we "data donors" need to do now to "make life easier" "someday" for the "data recipients", our "Karens"? My basic assertion is that even if we had a "stable" software product*, we can't count on that lasting until somebody "picks up the mantle" for our family. We have to do things with our data that get copies of it outside of our software. Rick Van Dusen ----------------- *"Stable" and "software" are almost contradictory words. As has been discussed on this list, software from big companies and from one-person operations alike are vulnerable to vendor decisions to change, "upgrade", and/or drop the product at any moment. I contend that history has shown us that we simply can never count on the future of any software title, that the best we can hope for is that we can update our data to the successive new versions, or import it relatively intact to a new title. Therefore, if our data "sits in a drawer" in computer form for any length of time, it's almost guaranteed to be useless. On 9/21/2015 7:55 AM, John Nunnally via wrote: > I agree with everything you said, Rick, but you dug a little deeper than I > had in mind for someone like Karen who is not 40 years away from her > relative's running TMG system. > > Karen alluded to one issue that I think is critical: Can she "inherit" her > relative's TMG license? Or, is she obligated to find a version 9 license of > her own? > > And secondly, if Karen is entitled to use the license left by her relative, > Is there still a way she can recover the original registration information > and/or transfer it to her own name? > > And thirdly, if our successors must get a license of their own, does anyone > know how many licenses are left? > > > John N.

So to spin off in another direction.... I'm looking at my TMG database and the number of people in it. I have a rabbit hole approach to research which means I end up on tangents and researching 3rd cousins 8 times removed and in-laws to out-laws and other distant kin rather than my direct line exclusively. It's easy to output such a database with Second Site (thank you John Cardinal). But less so to paper - which the gist of this (and previous) discussions has shown is probably the best way to have the data outlive me. Obviously I need to break it down into smaller, more manageable chunks of family and also accept that not everyone will make it to paper. I just get overwhelmed at where to start. God willing - at 45, I have many years left to me but as we all know, there are no guarantees. And the lack of a successor to TMG thus far makes the need to have my data in another format more necessary since as a user of witnesses and roles and sentences - it's unlikely to GEDCOM out easily. Ideas? Thoughts? Thanks Linda Towne On 9/21/2015 11:54 AM, Rick Van Dusen via wrote: > > My basic assertion is that even if we had a "stable" software product*, > we can't count on that lasting until somebody "picks up the mantle" for > our family. We have to do things with our data that get copies of it > outside of our software. > > Rick Van Dusen > > > > >

Some of the past discussions of how to ensure our work gets to future generations have included periodically running reports for EVERYONE in the database to PDF, which can either be printed and filed now and then or just stored as PDF. This is my strategy of choice, although I admit I haven't yet done it. However, I do something similar for manuscripts I'm working on--periodically save them to PDF with the date in the file name so that if I ever need to see what I had earlier, I can just open a file. On Wed, Sep 23, 2015 at 5:59 PM, Linda M. Towne via <tmg@rootsweb.com> wrote: > So to spin off in another direction.... > > I'm looking at my TMG database and the number of people in it. I have a > rabbit hole approach to research which means I end up on tangents and > researching 3rd cousins 8 times removed and in-laws to out-laws and > other distant kin rather than my direct line exclusively. > > It's easy to output such a database with Second Site (thank you John > Cardinal). But less so to paper - which the gist of this (and previous) > discussions has shown is probably the best way to have the data outlive me. > > Obviously I need to break it down into smaller, more manageable chunks > of family and also accept that not everyone will make it to paper. I > just get overwhelmed at where to start. > > God willing - at 45, I have many years left to me but as we all know, > there are no guarantees. And the lack of a successor to TMG thus far > makes the need to have my data in another format more necessary since as > a user of witnesses and roles and sentences - it's unlikely to GEDCOM > out easily. > > Ideas? Thoughts? > > Thanks > > Linda Towne > > >

Just a note on dates in the filename, in case anyone finds this useful: 1. First, a disclaimer: Some will argue that a date in the filename is redundant, because the date is also listed. My replies to that: a. I don't want to write over a previous file by using the same name; putting the date into the filename prevents that. b. Not everyone uses a display form that shows the date readily. 2. Another disclaimer: I've been doing computer for so long that I still tend toward the old DOS requirement of 8.3 filename format. (Just call me T-Rex.<g>) But I still think short-ish filenames (or at least structured filenames) make finding a file easier. 3. I append to the filename a four-digit code for the date, thus: Y=one digit for the year. (Yes, this means that I run into duplication after ten years; this hasn't been much of a problem for me so far, and I've been doing this for about 26 years.) M=one digit, using a-c for Oct-Dec. DD=two digits for day of month. Putting the date in YMD order makes sorting by date easy. (Alpha characters sort after numerals, so a comes after 9. Caution: 0 [zero] comes before 1 [one].) So today is 5923. In a month it'll be 5a23. Letters to Mike and John might be named thus: Mike5923.docx John3c24.doc John5c24.docx Mike5102.docx ...and would sort by John before Mike, then in date order. Makes finding the file I want (and/or identifying a file) easy-peasy. For anyone who finds the four-digit coding confusing, I'd suggest an alternative such as YYYY-MM-DD. (I would avoid month names, which would sort with April and August first.) Rick Van Dusen On 9/23/2015 3:13 PM, Karla Huebner via wrote: : : : > However, I do something similar for manuscripts I'm working > on--periodically save them to PDF with the date in the file name so that if > I ever need to see what I had earlier, I can just open a file.