Prevention of allocation errors when copying files

 

The i5/OS^® operating system places locks on the from-file and the to-file when you copy files. To prevent allocation errors when copying files, you can place stronger locks on those files.

When a database file is copied, each from-file member is allocated with a shared-for-read (*SHRRD) lock state. When a device file is copied, the copy command allocates it with a shared-for-read (*SHRRD) lock state. The copy command allocates the member only while it copies it. A shared-for-read lock state lets other users read and update the file while you are copying it.

Generally, the member being copied to is allocated with a shared-for-update (*SHRUPD) lock state. However, if you specify MBROPT(*REPLACE), the command allocates the member you are copying to with an exclusive (*EXCL) lock state, and the records in the to-file are removed When you are copying one physical file to another, you can place stronger locks on the members to allow internal system functions to perform the copy.

• The command can allocate the from-file member with an exclusive-allow-read (*EXCLDRD) lock state.

• The command can allocate the to-file member with an exclusive (*EXCL) lock state.

The command requires these stronger locks depending on the type of copy you perform. If you cannot get these locks, run the copy command and specify a value of 1 (or any valid value other than 0) on the ERRLVL parameter. These values do not require the stronger locks.

There are many reasons for allocation errors when you copy files. For instance, you should not use functions that touch the to-file during the copy.

• Reasons for allocation errors when copying files
  If another job allocates a member with too strong a lock state, the copy operation might end with an error message. This is also true if the library containing the file is renamed during the copy operation.

 

Parent topic:

Preventing errors when copying files