File restructure bastardization
John Esak
john at valar.com
Wed Sep 28 09:39:32 PDT 2005
> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Jeff
> Harrison
> Sent: Wednesday, September 28, 2005 11:47 AM
> To: Fplist (E-mail)
> Subject: RE: File restructure bastardization
>
>
> --- John Esak <john at valar.com> wrote:
>
> [snip]
> > Boy, I wish I had your "excepting the 2.5 hours per
> > night"!!! We run truly
> > 24/7/365 and we are constantly struggling with how
> > and when to re-define
> > maps. It is a very big problem. So far, one I have
> > not come up with any good
> > answer for yet. It would be great if all the
> > brain-trusts here could come
> > up with something do-able in this regard.
>
> [snip]
>
> What I have done in the past is pre-expand the files
> that are likely to need additional fields. I know
> this is not always practical, but its has helped me
> tremendously at times.
>
> I just make sure the last field in the map is called
> "Extra" and I give it a length equal to the amount of
> space that I want to reserve. Then, when this file is
> active, I just need to make a backup of the map, then
> edit the map with my favorite editor, making sure to
> preserve the 2nd and 3rd columns in the map header. I
> then insert the appropriate fields before my "Extra"
> field in the map, I then decrement the length of my
> Extra field so that the total lengths of all of the
> fields together stay the same. I then go back to the
> header and change the 4th column of the header to be
> the new number of total fields in the key segment.
>
> I then quickly go into clerk on the file and make sure
> I did not mess anything up. If I have the data will
> appear scrambled on the browse, and I just quickly
> exit and copy the backup of the map back in place.
>
>
Well, two things. I would guess that you took this technique from the NEX
Accounti8ng Group which I released back in the late 80's. All the modules
had a last field in the map called "extra" and I filled it with lots of
extra characters usually to the boundary of 512. In this way, I could send
out new maps to people with some of those characters pulled up into the end
of the map. (I had also left about 20 or so extra blank fields before this
actual last "extra" field. I called the "extra" routine something like
sponge or some such. There is an article on it in The Guru somewhere. The
only difference I can see to what you do, is that I never bothered to edit
the map file. Just sucking up the extra characters into the top-most empty
field and decrementing the value in the very last expansion field does it
all. The restructure does not affect anything that comes before it, and it
does not change the total number of fields. The whole scheme worked without
flaw for the many packages of NEX that I sold.
However, even though this method is useful, I dropped it years ago. Instead,
I pre-allocate dozens and dozens of various length/edit fields in most
important maps. I label these fields as "r" for reserved. Then, when I need
one of these edit lengths/types, I just give it a meaningful name and start
using it. However, there are times when a particular size and shape
(especially a long one like 30,allup is needed and I don't have a reserved
one like it available. Or when a legacy field needs to be changed. It is
these times that filePro running in "real" 60/60/24/7/365 mode is very
thought to deal with. There is simply no "go to the safety map real quick
and put it back" possibility... None. :-) Things have to be absolutely
foolproof on these particular 21 year old files. (Company started pre-1980,
but we were on various TRS-DOS/non-filePro apps for a while... in 1984 we
went all filePro.)
JE
More information about the Filepro-list
mailing list