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