*EXCLRD lock when copy file (CPYF)

Eric Loe

unread,

Oct 19, 1996, 3:00:00 AM10/19/96

to

Recently I found that when I copied (CPYF) from a physical file A to another
physical file B, CPYF will allocate the member of file A exclusively but shared
for read (ie. *EXCLRD). This lock will cause problems in other jobs that open
file A as update or output.

However, if before I started CPYF command, I submitted another job that would
ALCOBJ (file A) as *SHRUPD and hold for a period of time, CPYF still works and
will lock member of file A as *SHRRD in this case.

I guessed CPYF will try to lock *EXCLRD first. If failed, it will try *SHRRD. It
happened in both V3R1 and V3R6

Questions:

1. if CPYF will work under *SHRRD lock, why it try to do *EXCLRD first ?

2. Is this what you guys think CPYF work this way?

Any comments welcome.

Before this incident I am not aware of this problem, my application got a
message waiting when I (another job) was trying to copy data from production
library for testing. My program failed since it was unable to allocate the
object member.

Walden Leverich

unread,

Oct 27, 1996, 2:00:00 AM10/27/96

to

On Sat, 19 Oct 1996 00:20:25 GMT, eri...@interlog.com (Eric Loe)
wrote:

>Questions:
>
>1. if CPYF will work under *SHRRD lock, why it try to do *EXCLRD first ?

I have not confirmed this but it is possible that CPYF will fall back
to a copy-on-write page buffering sceme similar to Save While Active.
Since this involves additional disk and CPU time my guess would be
that if CPYF can get a *EXCLRD lock it will use a normal copy, else it
will allow the copy, but with additional disk and CPU usage.

-Walden

Jeffrey Lanham

unread,

Nov 8, 1996, 3:00:00 AM11/8/96

to

This all depends on if the CPYF is used to build the target file, or
if the target file already exists. If it has to build the file, it
obtains *EXCLRD to duplicate the object descriptor (just like
CRTDUPOBJ).

Jeff

The TEAMIBM Network

unread,

Nov 22, 1996, 3:00:00 AM11/22/96

to

Walden,

>>Recently I found that when I copied (CPYF) from a physical file A to
>>another physical file B, CPYF will allocate the member of file A
>>exclusively but shared for read (ie. *EXCLRD). This lock will cause
>>problems in other jobs that open file A as update or output.
>>
>>However, if before I started CPYF command, I submitted another job
>>that would ALCOBJ (file A) as *SHRUPD and hold for a period of time,

>>CPYF still works & will lock member of file A as *SHRRD in this case.
>>
>>Questions:
>>1. If CPYF will work under *SHRRD lock, why try to do *EXCLRD first?

Jeff,

>This all depends on if the CPYF is used to build the target file, or
>if the target file already exists. If it has to build the file, it
>obtains *EXCLRD to duplicate the object descriptor (just like
>CRTDUPOBJ).

If the parameters specified on the CPYF are compatible with a full
dataspace copy <effectively the same results as CRTDUPOBJ, but with
the possibility to copy to an existing file.mbr> then the described
occurrence is expected. Such a copy is much quicker than blocked reads
with data mapping and/or field dropping etc. which requires going
between VLIC and OS/400 for each buffer to be modified before inserting
into the target dataspace.

Chuck Pence
-- Comments provided "as is" with no warranties of any kind whatsoever.