Gavin writes:
 
> file created just for that purpose. If you are FLOCK/FUNLOCKing your shared
> data mapped file, performance is going to suck.
 
Yep.  The bigger the file, the worse the performance hit.
 
From my viewpoint:
 
  1) this is a bug in FUNLOCK ... it should *not* be posting pages to
     disk;
 
  2) it was probably put into FUNLOCK as a workaround to some other
     problem in MPE (my assumption).
 
Similar performance problems occur when doing an FCONTROL to "complete"
the I/O (FCONTROL 2), although more "legitimately".
 
<PLUG>
 
Here's the output from our CSEQ Nugget, which has some hints/notes/warnings
on selected intrinsics:
 
CSEQ    [1.22] - NUGGETS [K.2805.22]                        Demo version[     ]
(c) 1989 Software Research Northwest, Inc.
For help at the CSEQ prompt, enter:  ?
 
 
CSEQ [nm]: fcontrol
 
Procedure FCONTROL (
   filenum      :        int16   ;        {R26}
   controlcode  :        int16   ;        {R25}
   param        : anyvar UInt16  )        {R23, R24}
                                          {Address type = LongAddr}
   {controlcodes (selected values)                                     }
   {  1  general -> param                                              }
   {  2  Complete all I/O (can be slow on XL)                          }
   {  3  read hardware status --> param                                }
   {  4  set timeout interval (param = seconds)                        }
...
 
CSEQ [nm]: funlock
 
Procedure FUNLOCK (
   filenum      :        int16   )        {R26}
      { CCE: ok                                                  }
      { CCG: denied, you didn't have the file locked             }
      { CCL: error                                               }
   {NOTE: FUNLOCK has serious performance problems                     }
   {on MPE/iX, scaling with the size of the file,                      }
   {because it "posts" all pages of the file to                        }
   {disk each time you call it.                                        }
 
</PLUG>
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html