RE: Accessing files In QTEMP -- RPG400-L

Hi Dan

> >I have a number of multi member file that were created by developers. No
>clean up routines, no housekeeping, no management.<
>
>I will grant that you've got a nightmare to deal with, but I'd place the blame
>squarely on the developers, not on the multi member file technique.

Agreed. My point was more that the multi-member approach allowed them to do 
this in the first place. Anyone can use something potentially useful badly 
I guess.


> >Any strategy that doesn't solve/perform it's own housekeeping or relies on
>"other" tasks to run regularly is doomed to failure.<
>
>Evan, there are plenty of examples of dependencies in the AS/400 world that
>require the developer to perform housekeeping-type tasks.  Hardly anything is
>*that* automatic.

I am talking about a strategy that includes it's own housekeeping routines 
- not something that relies on another independent process that somehow 
"knows" what housekeeping has to be performed. To put it another way, the 
logic to remove things is generally aligned somehow with the logic to add 
things. My point was that applications that add records, files or file 
members need to provide the routines to remove them, not expect them to be 
somehow removed by some other process that remains undefined and separate 
from the addition logic.

> >I think the solutions that presented a master file with some kind of key for
>the temporary data, or the use of QTEMP and rolling the whole job into one
>chunk of code sound more like the way to go to me.<
>
>I concur, but only if a major rewrite of an existing application is not
>requirred.

Any application that cannot access and control it's own data already needs 
a major rewrite.

> >Just my particular take on this.<
>Everybody's got their favorite way to do things.

It's not a case of being my favourite (or otherwise) way of doing this.  I 
have just seen close up how bad multi-member file solutions can be. 
Granted, it is dependent on good housekeeping practises and sensible 
control of the data.

But multi-member files can bite you other ways as well.  As far as I can 
tell multi-member files (if you have lots of them) will also fill up the 
object ownership bits in the profile internals to a surprising degree.

Also, if an application has some way of managing  data in multi-member 
files it also has to deal with what happens if they get moved to another 
file or library.

They also affect save and restore operations in terms of timings and object 
locks as they behave somewhat like an object.

As a data storage object they present some real difficulties with journalling.

They may have their place, but I don't see that the apparently convenient 
solution justifies what can occur downstream.

As a final point, I am not saying don't use this approach, I am merely 
saying use it carefully and be sure it's the correct approach, not just 
something that is convenient and easy.

If I wanted to get things going here I could refer to them as the "goto" of 
AS/400 databases :)

Regards
Evan Harris

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---