At a given point, the modulo of one of our data files

begins to decline as the number of records expands.

Eventually the modulo is reset to 1. We need to know

the limitations of REV. G. file specifications.

thanks.

Wow! Is that ROS or LNK files? Doesn't matter since this really shouldn't be happening. In ARev, there's a couple of thing I could suggest. RevG, well, that's a different story. Neither ROS nor LNK files should have modules that could change at all.

For ARev, what you'd have to do is remake the file. Better yet, rename the old file, create a new file and copy all the records in.

Probably the alpha is getting corrupt. Generally this shouldn't happen, so I'm guessing there's a bad spot on the disk you're hitting. Copying the file should help with that.

Alternatively, you could always set the sizelock to 1. This way the file will never shrink, but can grow.

apk@sprezzatura.com

Sprezzatura, Inc.

Rev G2b has a maximum number of 65536 for usable modulos in an LNK file. You can create a file with any size modulo (e.g., 100003) but G2b will only use groups 1-65536. With a modulo of 100003, G2b will hash all of the record keys to groups 1-34467; with a modulo of 140009 G2b will hash all record keys to groups 1-8937 (140009 - (2*65536))= 8937.

Understanding that G2b uses only the first 65536 groups for all records, a file should never be created with a modulo greater than 65536 (or maximum prime of 65521 less than 65536). A file that has enough records to require a larger modulo, will still only use this maximum, with overflow frames created for additional records.

I realize this is your busy time of the year (taxes). I'm just down the street from you. Ask Ann if she wants me to come by for a few minutes and look at your file maintenance code; I'll be happy to.

switt-thompson@spectrumhr.com

The modulo of a RevG file never changes on it's own. It can only be adjusted by re-creating the file.

A networked file with an extension of .lnk will create overflow frames (max size 1k) as necessary when the main frame is full. These overflow frames are added to the end of the DOS file. When records are deleted the DOS file stays the same size, just with empty frames . Space can be recovered by re-creating the file with an appropriate modulo. An example of a file in serious overflow is one who's modulo is reported as 5 but who's DOS size is 125k.

A single user file has one group for the dictionary with the extension .000 and one or more groups for the data; the precice number of primary groups being the modulo. Therefore, if you had a file with a defined modulo of 5, records in every group, and no overflow conditions, there would be 6 DOS files present. file.000, file.010, file.020 ….. file.050 . When a group (max size 64k) goes into overflow a new DOS file is created with the same modulo extension with the last digit incremented by 1, thus the first overflow for file.030 would be file.031. This can increase up to file.03Z at which time the record write should fail. Long before this time, though, you would probably experience one of two things. A, you get so frustrated by the sloooooooooooow data read/write times that you recreate the file; or B, the system crashes with corrupt groups so often that you again recreate the file.

Capt'n

View this thread on the forum...