×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 8/2/21 11:38 AM, Mark Waterbury wrote:
A "save file" is not really a true "file" in the traditional sense,
underneath is an MI "dump" object (a kind of space) that contains the
saved object(s).
Yes and no. It is a special type of file, but it's a file none the less.
It can be read in a HLL program and transferred using FTP.
You cannot read and update individual "records" in a save file; it
can only be read or written in its entirety, from start to end ... as
a sort of "atomic" operation. If you have ever canceled a SAVOBJ
command and tried to display an "incomplete" save file, you will get
errors.
I understand that ... but there is no reason (that I can think of) that
displaying a save file (or reading) should require an exclusive lock on
the object.
Reading (in the case I'm encountering, using FTP) a save file should not
fail if it's simply being displayed in another job.
Trying to display, or read, a save file that's being saved to should
absolutely fail. As should trying to save to a save file that's being
displayed.
FWIW: My original question was to find out if anyone knew WHY, not to
debate if it's needed.
david
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.