RE: Object ownership during CRTDUPOBJ -- MIDRANGE-L

Hi Rob,

Thanks for your answer. I have added the target library to a journal and watched the journal entries to see if I could explain the behaviour as described in my previous mail.

On the physical file I see (irrelevant entries ommited):
1. Object added to library
2. Create database file
3. Change owner
4. Record added x times.

So yes, this works as I thought: The object is placed in the library, has its ownership changed and then has the records added to it.

On the logical file that gives the errors I see:
1. Create database file
2. Change owner

What it doesn't show me is the moment when the access path is being built, but I assume this is between the creation and the change of ownership. The journals have helped me analyse, but have not yet confirmed my explanation to the errors. Is my assumption correct on the moment the access path is being built? And i fit is, why would it work this way? Is this a bug or is there some kind of logical explanation fort his behaviour?

Regards,
Erwin Donker

-----Oorspronkelijk bericht-----
Van: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Namens
rob@xxxxxxxxx
Verzonden: dinsdag 27 oktober 2015 13:04
Aan: Midrange Systems Technical Discussion
Onderwerp: Re: Object ownership during CRTDUPOBJ

Journal
Journal
Journal

I have a library with everything set to automatic journal.

Watch this:
CRTDUPOBJ OBJ(RCO*) FROMLIB(ERPLXF) OBJTYPE(*FILE) TOLIB(ROB)
DSPJRN JRN(#MXJRN/USERS) FROMTIME(102715 0756)
Sequence Code Type Object Library Job Time
72446455 J XP RCO ROB ROBS1 7:56:44
72446456 Y YO ROB QSYS ROBS1 7:56:44
72446457 D CT RCO ROB ROBS1 7:56:44
72446458 D JF RCO ROB ROBS1 7:56:44
72446459 D GO RCO ROB ROBS1 7:56:44
72446460 D RV RCO ROB ROBS1 7:56:44
72446461 F JM RCO ROB ROBS1 7:56:44
72446462 D MA RCO ROB ROBS1 7:56:44
72446463 F MC RCO ROB ROBS1 7:56:44
72446464 D GT RCO ROB ROBS1 7:56:44
72446465 D GT RCO ROB ROBS1 7:56:44
72446466 D GT RCO ROB ROBS1 7:56:44
72446467 J XP RCOL01 ROB ROBS1 7:56:44
72446469 D CT RCOL01 ROB ROBS1 7:56:44
72446470 D JF RCOL01 ROB ROBS1 7:56:44
72446471 D GO RCOL01 ROB ROBS1 7:56:44
72446472 D RV RCOL01 ROB ROBS1 7:56:44
72446473 D MA RCOL01 ROB ROBS1 7:56:45
72446474 F MC RCOL01 ROB ROBS1 7:56:45
...
You can see the steps. Some are change owner entries.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to:
2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Erwin Donker <erwin.donker@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 10/27/2015 07:52 AM
Subject: Object ownership during CRTDUPOBJ
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

Hi,

Situation:
Create duplicate objects of a physical file and its logicals, using
CRTDUPOBJ OBJ(FILE*) FROMLIB(LIB1) OBJTYPE(*FILE) TOLIB(LIB2) DATA
(*YES).

File information:
Physical file size: 1.8 GB
Logical file 1 size: 500MB
Logical file 2 size: 100MB

Userprofile issuing the command (XXXXXXXX) has:
MAXSTG = 250000
GRPPRF = SOMEGRP
OWNER = *GRPPRF

Group profile SOMEGRP has:
MAXSTG = *NOMAX

Result:
Physical file is created just fine, including the data.
Logical file 2 is created just fine.
Logical file 1 is created, but contains no members because of:
- MCH4601: Storage limit overflow for user profile XXXXXXXX.
- CPF3217: Not enough storage to create file LOGICAL1 or add member to
file.

Since the new objects being created will get the groupprofile as owner,
which has *NOMAX as storage limit, I expect no problems with storage limit
on the user profile. This is true for the physical file. Why is it that
the logical that is larger than the max storage limit of the user, but
smaller than the physical that copied just fine, gives an error while
adding the member?

The only logical explanation I can think of, is that both the physical and
logical files are first created with user profile XXXXXXXX as owner, but
with the physical file the owner is changed to the groupprofile before
adding the data, and the access path is being build BEFORE changing the
object owner.

I could not find any information on this in the documentation. Does anyone
know if my explanation is correct? Or know why this is happening? We are
on version 7.1.

Regards,
Erwin Donker

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.