Yeah that fixed it, by removing the fmultiacc option. Thanks very
much!

Thanks. Greg Fudala. Circuit City Stores
Greg [log in to unmask]


On Sat, 06 Sep 1997 20:53:12 GMT, [log in to unmask] (GF) wrote:

>On 5 Sep 1997 17:28:56 GMT, [log in to unmask] (Bill Bennett CSY)
>wrote:
>
>>On Fri, 05 Sep 1997 15:25:16 GMT, GF ([log in to unmask]) 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.
>>
>>You might not want to add dynamic locking to all the HPFOPENs this
>>utility does.  By doing this it means that any other program that
>>accesses these file must open with dynamic locking if you want
>>concurrent access. So by making this one file work you may have
>>caused other programs to have problems accessing files when they
>>are being searched.  So you might change the code to try to open
>>with out locking then if you get a file error 430 then try with
>>locking.
>>
>
>I did in fact put code in to look for the 430 and do what you said. =)
>
>
>>: 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?
>>
>>This problem is because you added the multijob access.  With multijob
>>access the program is sharing file pointers with the other program accessing
>>the file.  So in your case the first program probably was waiting to
>>append to the end of file (so the record pointer was at EOF), so you
>>keep changing it.  I'm not sure if your changing the pointer effects
>>the other program but it may.  For your application you don't want
>>multijob access, you want your own copy of file pointers.
>>
>
>Hrm ... I'll have to remove this multijob parameter and see what
>happens. I'll let you know. Thanks!
>
>>: Thanks. Greg Fudala. Circuit City Stores
>>: Greg [log in to unmask]
>>
>>Hope this helps
>>