Opening a file in GMULTI mode means that ALL accessors of the file SHARE
ONE FILE POINTER.  Thus, locking is very important, as is making sure that
you position the file pointer before reading or writing.  A customer of
mine (US Navy) uses GMULTI quite a bit, particularly when "sharing" data
structures between multiple jobs/sessions.

When accessing files in GMULTI mode, always:

   1) enclose your file operations within FLOCK, FUNLOCK
   2) use FPOINT and then FREAD or FWRITE, or use FREADDIR, FWRITEDIR
   3) assume that the file pointer is somewhere other than where you want it

GMULTI has some really neat applications, if you are careful.  It also has
some really odd behavior at times.

John

At 03:25 PM 97/09/05 GMT, GF wrote:
>We have this program FINDSTR (a great program btw ... get it from the
>CSL) which searches for strings in a file. Well this one file would
>return an error:
>
>FINDSTR DOUT.WORKDB ~V LOG
>
>Dynamic LOCKING was specified on a previous OPEN of this file, and
>dynamic
>LOCKING was not specified on this call to HPFOPEN.  (FILE OPEN ERROR
>-430)
>File System message 430
>
>So I went in to the source and added code to open the file with the
>dynamic locking option set on and multijob access on. The Fopen now
>returns success.
>
>However, the FREAD is then failing on this file. It's returning:
>
>END OF FILE (FSERR 0)
>
>Why??  So after some experimentation I determined if I add an FPOINT
>before each FREAD (FPOINT to rec 1,2,3 ....) then the FREAD succeeds.
>
>So why for files of this type do you have to FPOINT to each record
>before the FREAD? Anyone know? Is there a "correct" way to get this to
>work?
>
>Thanks. Greg Fudala. Circuit City Stores
>Greg [log in to unmask]
>
>
--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.