HP3000-L Archives

September 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Sat, 6 Sep 1997 20:53:12 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
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
>

ATOM RSS1 RSS2