Create Duplicate Object (CRTDUPOBJ)

[Guest.Visitor]

In place of CRTDUPOBJ you could use: CPYF FROMFILE(MYFILE) TOFILE(QTEMP/MYFILE) CRTFILE(*YES) FROMRCD1) TORCD(1) CLRPFM QTEMP/MYFILE I haven't noticed performance issues with the CRTDUPOBJ since SYSTEM 36 environment days. On the System 36 files were routinely created and deleted during a job. The early AS400 did not handle this well.

[Guest.Visitor]

Create Duplicate Object (CRTDUPOBJ)

Use CPYF FROMRCD(1) / CLRPFM not CRTDUPOBJ! Unless you *really* want to also clone the trigger program definitions, constraints, etc. In other words, you could be updating a copy of the file and still firing off other things behind the scenes. Yikes! And CPYF can be run while the object is in use. Say NO to CRTDUPOBJ. Chris

[wbois]

Create Duplicate Object (CRTDUPOBJ)

Just recently had a conflict between two submitted jobs where the first program failed trying to open an access path for update because a second job was doing a CPYF where the *FROMFILE was the same physical file involved. The first job could not allocate the member of the update access path. I always thought that the CPYF only had a lock on the *TOFILE for the duration, but it appears to me that the CPYF may also allocate the *FROMFILE if it is not already in use. It has been difficult to replicate this problem with these two jobs because of the short timings involved, but it has happened to us a couple of times, and the only thing I can see that might be a culprit is the CPYF command. Neither job does an explicit *ALCOBJ for the file involved. I'd be interested to know if anybody else has experienced this. We're on V5R1. WBois@Unifirst.com

[David Abramowitz]

Create Duplicate Object (CRTDUPOBJ)

For a similar topic I posted the code below. It really does solve this particular problem. It is worth repeating. You have to have S/36 mode operational. Dave

---

Code

[Guest.Visitor]

Create Duplicate Object (CRTDUPOBJ)

I believe that if you use CPYF to copy the whole file, and there are no locks on the input file when it starts, it will do what appears to be a CRTDUPOBJ instead of the CPYF. If not a CRTDUPOBJ, it puts a *EXCL lock on the input file and the copy proceed without any I/O showing, looking just like a CRTDUPOBJ. I first noticed this at, I believe, V5R2. Sam

[Guest.Visitor]

Create Duplicate Object (CRTDUPOBJ)

...an *EXCL lock on the input file Not quite. An *EXCL lock might be put on the OUTPUT file. Do a CPYF, F4, F1. I can do a CPYF on an input file that other jobs have open, no problem. Chris

[Guest.Visitor]

Create Duplicate Object (CRTDUPOBJ)

Does create duplicate object require to lock the owner (say QPGMR) of the file before creating the object? If multiple programs try to create duplicate object using CRTDUPOBJ command, does it impact the performance because of the lock as explained above? If this is true, what is the alternative way of creating duplicate file object?

[Guest.Visitor]

Create Duplicate Object (CRTDUPOBJ)

"I can do a CPYF on an input file that other jobs have open, no problem." Sure you can. What I'm saying is that *if* there are no locks on the input file when the CPYF *starts* it will operate differently then if there was, say, a *SHRRD lock on the file. Sam