[Info-vax] OpenVMS - file selection abnormally with Copy / Rename or user ignorance?

[Jan-Erik Soderholm]

David Froble skrev den 2015-03-29 05:36:
> JF Mezei wrote:
>> On 15-03-28 16:36, Stephen Hoffman wrote:
>>
>>> AFAIK, the circumstances are not officially documented.
>>> This because there's no upside to discussing the details.
>>
>> I declare that satisfying JF's curiosity to be an "upside". Therefore
>> the above statement is false. :-)
>
>
> Ok
>
>>
>>>         Also, all cases in which these data corruptions can occur
>>>         in the data that BACKUP transfers are not reliably reported
>>>         to you;
>>
>> Are there cases where BACKUP/IGNORE would NOT report a file as currently
>> opened at the time BACKUP begins to copy a file ?
>
> No, if the file is open, BACKUP will report that fact.  Also, consider, the
> /IGNORE=INTERLOCK is to allow BACKUP to OPEN the file.  Once the file is
> open, things are different.  If other writes occur, BACKUP is unaware, and,
> frankly, doesn't care.  It's doing what it needs to do. Or, should I say,
> what it's been TOLD to do.
>
> I've never tried it, but, I'm betting that once BACKUP has a file open,
> others cannot open it.
>
>>
>>
>> And in terms of problems, instead of "corruption" isn't it more correct
>> to state "unpredictable data" ?
>
> Well, as corrupt data is unpredictable, that's Ok to say.  But, true
> corruption is possible.  Consider a keyed file.  The data is written after
> BACKUP has copied that part of the file, but, not yet copied the secondary
> keys.  So, it's going to have a secondary key, or keys, pointing to perhaps
> a record not in the BACKUP save set.  I'd call that corruption.  And all
> that's before considering transactions written to multiple files as a
> single transaction.  That's when it gets bad.
>
>
>> From a true "corruption" point of view, would the only corruption
>> possible be an indexed file where bucket split and new records added
>> after BACKUP has already copied the index blocks , and ends up copying
>> the new data buckets ?
>>
>> From a sequential or relative file point of view, wouldn't file
>> integrity remain , but new data may or may not be copied ?
>> (unpredictable). ?
>
> It's transactions that really matter.

Correct. That is why no one would concider a plain RMS files
"database" today. It is just so easy to get the files out
of sync. Move to a real database product where this is a
non issue.