Re: INZPFM in RPG

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

Rob,

>I can't see the use for a direct file anymore.  

I didn't even use them back then...  But WSU did as I recall, although I stayed
away from WSU too and just wrote real Workstn programs instead.

>I could see someone 
>wanting to make sure that space was available for a big batch post. 
>Something to stick in the big bag of tricks.

You can do that with a regular file with CRTPF ... ALLOCATE(*NO), and still only
have records added to the file when you write a new record.

The benefit of a direct file is that all of the records are considered to exist
immediately, and you can "add" records randomly at any given RRN, typically
computed as a hash with a collision detection routine.  You would thus do a type
of "scatter load" of records in the file

>I actually did some MAPICS work around 17-18 years ago and from what I 
>remember they liked to preallocate a lot of space.  

SSP allocated space for the specified number of records, because files were
always stored contigously.  This was true for sequential and indexed files, as
well as direct files.

>If you initialized to *DFT instead of *DLT, how do you know how many 
>records you actually do have?

By keeping track yourself, if you cared.  The main purpose of a direct file over
sequential was not the preallocation, as that happened anyway under SSP.  It was
the ability to write records at what amounted to random RRN's based on your
hashing algorithm.

Originally, SSP didn't have delete capable files either, so the entire filespace
was filled with blank records.  You'd hash a value to use for where to store a
given record, chain to it and check your own status code to see if available,
and if so fill it with your record contents.  If already used, you needed to
code your own collision algorithm to decided on a different RRN to use instead.

Once files became delete capable (on or about the same time IFILE support was
added to SSP/34), you could have direct files built with deleted records instead
of blank records.  That let you chain to determine if the record was already in
use, instead of needing to set your own in use flag byte.

These days, just using keys is much simpler, and you don't worry about whether
performance suffers because of an index.  In fact, these days you build extra
indexes to *help* performance...

Doug