Does BACKUP lock files when scanning /FAST /MODIFIED /SINCE=BACKUP?

[csewell]

We have recently started using the /SINCE=BACKUP qualifier for incremental backups, after using /RECORD on a full backup. Now we are starting to see batch jobs failing to start if they are due to start at the same time BACKUP is doing it's scan. According to ACCOUNTING They fail with the error "%RMS-E-FLK, file currently locked by another user" immediately after starting, and no log file is created. The submitted command file should not be locked by anyone.

Anyone else seen this behavior?

[abrsvc]

You are looking at this in the wrong direction. The message indicates that the file is locked by another user and thus not available for backup. This is why many users add the qualifier /Ignore=Interlock which will tell backup to ignore the lock status and backup the contents anyway. You run the risk of having incomplete data from that file however. The proper way to end up with true backups would be to cease all activity on the system and close all data files. Or, better yet, use standalone backup.

Dan

[csewell]

I'm afraid you didn't understand the problem.

The issue is not regarding backing up a file, it is about a batch job failing to start. A command file has been submitted to a batch queue to start at a scheduled time. Just seconds before that scheduled time, a backup job runs and starts to scan and backup up the disk that the batch command file resides on. While BACKUP is scanning files, the scheduled batch job attempts to start and fails. The batch queue (set to retain on error) and ACCOUNTING show the job starts and fails immediately with the error "%RMS-E-FLK, file currently locked by another user" and no batch log file is created. I assume the batch scheduler was not able to open the command file to execute it because it was locked by another process. I also assume that that process was BACKUP since the failure occurred during the BACKUP file scan. No batch job failures were noted before the change to the BACKUP command. The change I had made to BACKUP was to add the /SINCE=BACKUP qualifier. Previously the qualifier was /SINCE="<fixed date-time>". Note that the batch command file that failed to run was not backed up and should not have been since it had not been modified since the backup date recorded for it.

Maybe it has something to to with the /FAST qualifier on the BACKUP command, so I am removing that to see it if makes a difference.

[volkerhalle]

Code: Select all

$ HELP BACKUP /FAST
...
     To perform a fast file scan, you need write access to the
     INDEXF.SYS file on the input medium or the input medium must
     be write-locked.

This may imply, that INDEXF.SYS is - at least temporarily - write-locked during the fast scan, thus preventing a new file entry to be created.

Volker.

[csewell]

That's what I suspect. However the /FAST qualifier has always been there without affecting batch jobs as far as I can tell. It's only when I added /SINCE=BACKUP that some batch jobs failed to start.

I removed the FAST qualifier so we'll see if that fixes it.

[abrsvc]

I believe that perhaps it is a combination of the modifiers that is the issue here. The FAST qualifier will lock the index file long enough to get a file list (IRRC) and with the qualifier of /since, there is more work to perform outside of just getting the file list which would increase the time for locking the index file. You may have been lick that the lock was short enough in the past to not cause any problems with the batch job starting.

Dan