Processing to add/create real fields in an existing file

[John Esak]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Fairlight
> Sent: Sunday, August 15, 2004 9:13 PM
> To: Filepro List
> Subject: Re: Processing to add/create real fields in an existing file
>
>
> When asked his whereabouts on Sun, Aug 15, 2004 at 08:55:14PM
> -0400, George
> Simon took the fifth, drank it, and then slurred:
> [Weird formatting fixed.]
> > I don't think that can be done.  If you need those fields, and they are
> > filePro files, why don't you just add the most number of fields
> you would
> > need to the file and the store the info into them.  If no info
> is stored,
> > no big deal.  Mass storage is very cheat these days.
>
> I think it could be done, but it would require use of a secondary control
> file to avoid locking issues if you tried to do it all in processing (or
> just a plain old shell script of some sort to handle it externally).
>
> Basically, I thought you could change the map file, and then just run
> autoshuf to rewrite the key/data segments (and use dxmaint to rebuild
> indices).
>
> Make sense, anyone?
>
> I won't get into the unstructured data aspect of it from a design point of
> view.  But -technically- I thought it was possible.
>
> mark->
> --

I'm coming in late on this thread... this is the only message I've seen.
Autoshuf can do the trick, along with rewriting the required map(files)...
but to do this "live" while other things might need to be posting to this
file would be (essentially) suicide.  You need an absolutely quiescent
period when the file will not be needed by any other process while
auto-shuffling happens. If this can be arranged, the whole thing can easily
be orchestrated/programmed.

Not knowing anything about the need in question... this much I know about
autoshuf.

John