I've been studying both Bruce and Stan's notes on FUNLOCK and thought
I'd toss in my $.02 worth in the ring.....(kinda long...)
 
On MPE-V systems it really made a lot of sense for the FUNLOCK to post the
changes to disc.  Primarily because the premise behind setting-up a file
for locking was it was being shared amoung different processes yet the
file's buffers were local to each process.  Given that, once a process was
finished and issued an unlock, for the other processes sharing the file to
obtain that same update it was necessary to post the changes to disc from
the process's local buffers.  This wasn't really that noticeable on these
buffered files for there was a 'dirty' bit in the buffers which indicated
which file blocks had changed.  The file system only had to post back to
disc those blocks whose 'dirty' bit was on, signaling only these blocks
had been changed and needed to be updated.
 
Now, my knowledge of what internally happens with mapped files is weak, so
I may be off in the weeds.  But it seems to me that mapped files can be
somewhat viewed the same as processes sharing a memory data segment.  In
this case, each process essentially has access to the same space and
therefore immediately 'sees' any updates placed in the file by other
processes.  The issue here is the file system also is charged with keeping
the disc copy of the file current with the memory copy.  This is a one of
the features of mapped files.  Based upon the previous thread on this, it
seems to achieve this by always posting the entire memory copy of the file
to disc upon an FUNLOCK.
 
I believe that without FUNLOCK, the file system posts the mapped file back
to disc in background, without impeding the process.  This is probably
why using a separate mechanism for managing file contention (file or RIN)
gets the same results without the performance impact caused by the posting
of the entire file. But what would happen if a system failure occurs?
It would seem that there is a risk one would not know if it was only the
last transaction that was not updated to disc or several transactions due
to the background posting as opposed to immediate posting.  I guess this
risk is a design decision based upon the critical nature of the application.
Obviously one could periodically issue an FLOCK/FUNLOCK/FCONTROL against the
file to ensure it gets posted to disc at various points in the process....
 
I believe Stan's contention is that FUNLOCK shouldn't do the posting.
Instead FCONTROL/FCLOSE should force the flush to disc.  If a background
posting goes on, so what....as long as the user isn't forced to wait.  But
all this ties back to the intent/design of mapped files and if this was
considered and the reasons for the decision for the current approach.
 
So I agree with Bruce's thoughts yet I also agree with Stan's premise as
it relates to the performance problems.  However, I'm wondering if both
needs can be met with some form of the old 'dirty' bit which allow the
file system to only post to disc the dirty memory pages instead of the
entire file?  I'm not sure what this might all mean to the file system
and how it would affect the attributes of mapped files.  Perhaps someone
from CSY can/will comment.....
 
 
Managing Access Contention
--------------------------
 
If indeed one's design can tolerate the background posting or final posting
upon FCLOSE, and the design issue is managing contention, certainly using
other methods to control access makes alot of sense.  If all access is
local to the same user using different, concurrent processes, I would agree
that local RINS are a good mechanism.  On the other hand, if different users
are doing concurrent access, FLOCK/FUNLOCK of a separate, small (1 record)
file works well.
 
However, if it is necessary to manage concurrent access to different portions
of the file there are several methods which come to mind.  One involes using
Global RINs, acquiring one for each portion of the file.  However, one does
not have a choice as to the RIN number one gets.  So one would also have to
setup a side-file with the RIN numbers and then program the application to
obtain the RINs from this file and use them based upon their logical
assignment.
 
Another obvious approach would be to have a number of separate 'lock' files
and use these to denote separate areas in the main file, performing FLOCK and
FUNLOCKs on them to manage contention.
 
Over the years I've used another technique which doesn't add the additional
files nor does it have the problems of acquiring Global RINs, (especially
when a system has exhausted their configured limit and a 'reload' was
needed to expand the table!)  When I couldn't obtain any more Global RINs
without a reload to expand the table, I programmatically acquired some
additional 'file' RINs using 'ALLORIN' and tablized them so all users
would be able to share them.  Then, the 'RLOCK/RUNLOCK' procedures were used
to do the locking.  These RINs where then released when the last application
user exited or were released automatically should there be a system failure
(heaven forbid!).
 
The next time I needed this type of function I decided it was too much
bother to setup mechanisms to share the RIN ids.  So instead I decided to
setup my own 'RIN table' and use the procedures 'OBTAIN/RELEASE'.  In this
case, I didn't have to worry about tracking RIN numbers, for I could simply
assign them myself.
 
These last 2 techniques using multiple 'file' RINs or setting up one's own
RIN table both require the use of PM coding techniques and are probably
beyond the need of most applications.  In my case, we were working with
a fairly critical process involving interfaces to process control systems
where timing of data and concurrent access were important.  Also, with all
the PM coding, these methods made more sense at the time.....
 
For those who aren't interested in all this I apologize for rambling so
long.  On the other hand, my notions as to mapped files, etc. may be
completely out in space so those more knowledgable please don't be too hard
on me....  :->
 
-- Jerry (still learning MPE/iX Internals...) Fochtman