bt@eng.auburn.edu (bt garner) (01/29/91)
For those of you that have used the JPI compiler for any amount of time,
you probably know that there are a few problems (which, to be fair, can
be found in almost ant commercial software package), however if you've
ever reported one of these problems to JPI, then you are aware of how much
of hassle it is to get a fix for these "bugs." I have been using the JPI
products for about 8 months, and in that time have reported several (around
8?) - and of those, only one has been resolved (and the person with whom I
was able to get an answer from, no longer works at JPI, what rotten luck!)
This is a bug report which I first made to JPI in December of last year,
I asked them to get back to me with a fix as soon as one was found, and I
was assured by Chris Pratt (Programmer, JPI) that he would get back to me.
By the middle of January, I still had not heard back from JPI, so I called
them back and Chris could not even recal our earlier conversation, let alone
the opportunity to keep a customer happy by finding a fix and giving a
return call.
After receiving no answer (now another week and a half after the second
call) we got tired of fighting this stupid thing and sat down to find a
work around, which we did, eventually.
The problem exists when using the FIO.AssignBuffer routine in conjunction
with the FIO.Seek function for a randomly accessed file.
-------------------------------------------------------------------------
FIO.AssignBuffer under OS/2; JPI bug and bt/TDP fix:
When doing file IO under OS/2, we often use the FIO.AssignBuffer routine to
help speed up the disk processing. This poses no (obvious) problem when
performing a sequential read, however when using it in conjunction with the
FIO.Seek routine (ie, random access) you run the risk of generating an OS/2
access violation when the file is closed. The fix to this problem lies in
the problem itself, before closing the file, perform a Seek(0) on the file,
it may then be safely closed (at least as far as we can tell) with the
program not bombing out.
The error seems to be generated when you are at a certain point in the file
and then immediately access a point behind the current position. The problem
(I am guessing) stems from JPI OS/2 NOT being able properly back up inside
of a buffer of data.
This fix is (currently) being used is:
FileStream := FIO.Open(FileName);
FIO.AssignBuffer(FileStream, FileBuffer);
:
LOOP
FIO.Seek(FileStream,position);
Actual := FIO.RdBin(FileStream,TextBuffer,NumberOfChars);
:
END; (* loop *)
FIO.Seek(FileStream, 0); (* BUG FIX LINE *)
FIO.Close(FileStream);
---------------------------------------------------------------------------
I might also add that FIO.GetPos will not work with FIO.AssignBuffer under
OS/2, rather than getting the true location in the "file" (by file I mean
place in the file and buffer relative to both) where you are, you instead
can only generate where the file pointer is (ie, if you assign a buffer of
2K, GetPos will return 0,2048,4096,6144,8192... no matter how many bytes
you have actually read).
bt garner (bt@eng.auburn.edu)
systems programmer, process modeling group
chemical engineering dept, auburn university
--
* bt garner * 230 Ross Hall * Auburn University * Alabama * 36849 *
* internet: bt@eng.auburn.edu * Opinions: Mine, don't blame (or flame) AU *
* "Help, I'm horny as hell, and I can't get it up!" -bt *