TPFDF 
Author Message
 TPFDF

Hi, TPF guys:

      I am sure some of you ever used or are using TPFDF (TPFDB). As I
heard, there are more and more TPF workshops are approaching to apply TPFDF
in their system. Some big shops have been utilizing it for many years. And
TPFDF becomes a standard to apply on their new records, even on the
temporarily used work records.  In some extreme case, conventional files
were a history that only allowed to survive in the old records, which were
defined before TPFDB was created / implemented and whose related package
have not been rewritten yet.

    Yes, TPFDF has a lot of advantages, which simplifies and standardizes
the record I/O accessing with macro calls. To programmer, the chain handling
becomes no longer a nightmare and they are enabled to accomplish some
complicated process with few codes.  Just append/insert/add and meanwhile
TPFDF still maintains all the logical records in proper, organized order
perfectly. (Absolutely, he is a hard worker behind the scenes, those who
ever traced it will agree on that.) For some programmers, it is longing
relief and regarded as an upgrade that promotes TPF's DB handling with
SQL-alike syntax. Others might feel the coding (calling) is going dry and
less challengeable. System may be getting more stable since the dumps
associated with I/O error are more likely to be decreasing as well as the
records can be maintained with less effort. But the system also copes with
the monster that has a good appetite on CPU resource. As the CPU's computing
capability is improving and memory's price plunging year after year, for
some shops, that may not be a big issue to keep them away from implementing
it.

      There are so many controversial issues around this topic, but I
haven't seen related discussion in the Internet/ Newsgroup. Maybe it has
been regarded as an inevitable trend as it naturally came along with some
packages that prevail in this industry. And once a shop implements it for a
certain package, people might like to exploit more value from it, instead of
wasting its shining features.

      I believe TPFDB is a valuable tool and with which there are plenty of
requirements can be well fulfilled. But since it is a tool (or utility)
instead of a foundation, I wonder if it is worth using it all-inclusively
through out the system? Or we should have an another thought like - TPFDF
should be used where it needs to or where it better fits with.

      OK. Here is my question, assume you agree with my point, - Is there a
criterion that you ever applied or ever thought of to determine when, where
or how a TPFDF should be used, instead of a conventional file? Surely, your
experience or comment about TPFDF using or the comparison with conventional
file will be very helpful.

Many thanks

Rick



Fri, 14 Sep 2001 03:00:00 GMT  
 TPFDF
I use DF a LOT...  Basically, I use DF whenever there will be lots of additions,
deletions, or searches.  If my data is fairly small (i.e. just a few forward
chains), and fairly static, I go with a flat file.  DF adds a bit of overhead,
like any database would, but the benefits far exceed the minuses.

Quote:

> Hi, TPF guys:

>       I am sure some of you ever used or are using TPFDF (TPFDB). As I
> heard, there are more and more TPF workshops are approaching to apply TPFDF
> in their system. Some big shops have been utilizing it for many years. And
> TPFDF becomes a standard to apply on their new records, even on the
> temporarily used work records.  In some extreme case, conventional files
> were a history that only allowed to survive in the old records, which were
> defined before TPFDB was created / implemented and whose related package
> have not been rewritten yet.

>     Yes, TPFDF has a lot of advantages, which simplifies and standardizes
> the record I/O accessing with macro calls. To programmer, the chain handling
> becomes no longer a nightmare and they are enabled to accomplish some
> complicated process with few codes.  Just append/insert/add and meanwhile
> TPFDF still maintains all the logical records in proper, organized order
> perfectly. (Absolutely, he is a hard worker behind the scenes, those who
> ever traced it will agree on that.) For some programmers, it is longing
> relief and regarded as an upgrade that promotes TPF's DB handling with
> SQL-alike syntax. Others might feel the coding (calling) is going dry and
> less challengeable. System may be getting more stable since the dumps
> associated with I/O error are more likely to be decreasing as well as the
> records can be maintained with less effort. But the system also copes with
> the monster that has a good appetite on CPU resource. As the CPU's computing
> capability is improving and memory's price plunging year after year, for
> some shops, that may not be a big issue to keep them away from implementing
> it.

>       There are so many controversial issues around this topic, but I
> haven't seen related discussion in the Internet/ Newsgroup. Maybe it has
> been regarded as an inevitable trend as it naturally came along with some
> packages that prevail in this industry. And once a shop implements it for a
> certain package, people might like to exploit more value from it, instead of
> wasting its shining features.

>       I believe TPFDB is a valuable tool and with which there are plenty of
> requirements can be well fulfilled. But since it is a tool (or utility)
> instead of a foundation, I wonder if it is worth using it all-inclusively
> through out the system? Or we should have an another thought like - TPFDF
> should be used where it needs to or where it better fits with.

>       OK. Here is my question, assume you agree with my point, - Is there a
> criterion that you ever applied or ever thought of to determine when, where
> or how a TPFDF should be used, instead of a conventional file? Surely, your
> experience or comment about TPFDF using or the comparison with conventional
> file will be very helpful.

> Many thanks

> Rick

--
Chuck Rush
Pond Rushes, http://members.home.net/crush11

N. Texas Water Garden Society, http://www.ntwgs.org
Anti-spam note - to reply, remove the _nojunkmail from the address.

Si fallatis officium, quaestor infitias eat se quicquam scire de factis vestris.

If you fail, the secretary will disavow all knowledge of your activities.



Sun, 16 Sep 2001 03:00:00 GMT  
 TPFDF
Hi Chuck :

    Thanks for your information. And I believe since the 4K records
introduced to this environment, we got a better chance to manage
conventional file without bothering to deal with chains.

     In fact, If a conventional file is well organized and all the chain
index could be stored in prime, chain handling might not be that {*filter*} as
most TPFDF-favored programmers thought.

     After all, not all records are expanded endlessly. If TPFDF is applied
sheer for that purpose, more system overhead suffering for achieving some
programming / record maintenance benefit, which may need to be weighed a
bit.

Rick

Quote:

>I use DF a LOT...  Basically, I use DF whenever there will be lots of
additions,
>deletions, or searches.  If my data is fairly small (i.e. just a few
forward
>chains), and fairly static, I go with a flat file.  DF adds a bit of
overhead,
>like any database would, but the benefits far exceed the minuses.



Sun, 16 Sep 2001 03:00:00 GMT  
 TPFDF
I've tried posting also, since it's a moderated newsgroup the
moderator has to take actions and I have not been able to contact
him.


Mon, 17 Sep 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 
 

 
Powered by phpBB® Forum Software