You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Preventing allocation errors when copying files<br />
126 <strong>File</strong> <strong>Management</strong> V4R5<br />
When a database file is copied, each from-file member is allocated with a<br />
shared-for-read (*SHRRD) lock state. When a device file is copied, the copy<br />
command allocates it with a shared-for-read (*SHRRD) lock state. The copy<br />
command allocates the member only while it copies it. A shared-for-read lock state<br />
lets other users read and update the file while you are copying it.<br />
Generally, the member being copied to is allocated with a shared-for-update<br />
*SHRUPD) lock state. However, if you specify MBROPT(*REPLACE), the command<br />
allocates the member you are copying to with an exclusive (*EXCL) lock state, and<br />
the records in the to-file are removed<br />
When you are copying one physical file to another, you can place stronger locks on<br />
the members to allow internal system functions to perform the copy.<br />
v The command can allocate the from-file member with an exclusive-allow-read<br />
(*EXCLDRD) lock state.<br />
v The command can allocate the to-file member with an exclusive (*EXCL) lock<br />
state.<br />
The command requires these stronger locks depending on the type of copy you<br />
perform. If you cannot get these locks, run the copy command and specify a value<br />
of 1 (or any valid value other than 0) on the ERRLVL parameter. These values do<br />
not require the stronger locks.<br />
There are many “Reasons for allocation errors when copying files”. For instance,<br />
you should not use functions that touch the to-file during the copy.<br />
Reasons for allocation errors when copying files<br />
If another job allocates a member with too strong a lock state, the copy operation<br />
may end with an error message. This is also true if the library containing the file is<br />
renamed during the copy operation.<br />
When a copy command runs, the to-file may be locked (similar to an *EXCL lock<br />
with no time-out) so that no access is possible. Any attempt to use a function that<br />
must touch the to-file locks up the work station until the copy command<br />
completes. For instance, you should not use the following functions on a to-file<br />
that you are copying:<br />
WRKACTJOB<br />
Option 11 (Work with Locks)<br />
Option 5 (Work with Job Member Locks)<br />
Option 8 (Work with Object Locks)<br />
DSPDBR<br />
DSPFD<br />
DSPFFD<br />
WRKJOB<br />
Option 12 (Work with Locks, if active)<br />
Option 5 (Work with Job Member Locks)<br />
F10 (Display Open <strong>File</strong>s, if active)<br />
WRKLIB<br />
The library containing the to-file<br />
DSPLIB
Change language