Re: *nomax on file size.

This thread kind of morphed from *NOMAX on a regular file to the fact that SQL creates all tables with *NOMAX and no increment information is avaiable on the table..

Vern said

I don't know the answer- and I don't have a connection - but such a
table is just a PF - maybe create a table, then use DSPFD to see how SQL
sets the SIZE parameter.

("just a PF" and so much more!)


This is our standard DDS created file:

Member size                                   SIZE                  
  Initial number of records . . . . . . . . :                 10000 
  Increment number of records . . . . . . . :             1000      
  Maximum number of increments  . . . . . . :             1000      
Record capacity . . . . . . . . . . . . . . :               1010000 


This is a newer (better?) SQL created table:

Member size . . . . . . . . . . . . . . . . : SIZE       *NOMAX  

So, when we create a SQL table, we don't control the increments. I just tried an experiment and used CHGPF on it to set the SIZE parameters and it let me.


Paul said

IIRC, when a physical file extends itself it allocates itself another

'extent' (?).  I'm not sure how big it is, but 20 MB sticks in my mind.
According to the SIZE, it extends by number of records. The size of that would depend on how big the records are.

Chuck said

There is a minimal extent, I believe based on the
effective [fixed-length] record size along with the expected number of
records to be added according to the current activity statistics for the
dataspace.

This makes sense. Let the system use its knowledge of the way the file is being used to determine the increments. This also gives me some confidence that a high insert table might get substantially bigger increments than a low insert table. Kind of liking that idea.