Re: Unload/Reload screwed up security. -- MIDRANGE-L

#1 you said you upgraded to V5R3 since your last savsys... so to recover 
you system had it crashed you couldn't have done it very cleanly.

#2 I've done your shortcut many times but, since there would be "NO" 
current PTFs installed for the LIC, I always "Restore Lic" when I get 
ready to upgrade or use my V5R3 (or whatever rel I'm migrating) savsys to 
"Install Lic" to it has my current PTFs on it.
I don't know if having down level LIC caused your problem or not. What it 
sounds like is that USRPRFs did not get restored correctly ( 1st thing in 
restore #21).


_____________________
Kirk Goins CCNA
Systems Engineer, Manage Inc.
IBM Certified iSeries Solutions Expert
IBM Certified iSeries e-Business Infrastructure
IBM Certified Designing IBM e-business Solutions 
Office 503-353-1721 x106 Cell 503-577-9519
kirkg@xxxxxxxxxxxxx      www.manageinc.com

There are 10 types of people in the world:
Those that understand binary, and those that don't.



rob@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
09/22/2004 07:56 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
Unload/Reload screwed up security.






We did an unload/reload following appendix D of the Backup and Recovery 
Guide.  We did one modification we thought to "save" time.  Prior to the 
downtime we preinstalled lic on the new system using the IBM CD's.  Just 
lic - not OS or anything else.  This allowed us to initialize the disk 
drives - a long running task on a 3.3TB machine.  We stopped at the start 
of step 14.  In the past we used to use the SAVSYS to do the LIC install 
but we upgraded to V5R3 after our last SAVSYS.

We are wondering if this "time saving" step caused us numerous problems. 
This is not our first unload/reload.  However this is the first time we 
remember numerous painful events regarding security not being restored. 
Here's one scenario:
Used GO RESTORE - 21.  Definitely told it to restore to a different 
system, which, among other things appends ALWOBJDIF(*ALL) to all commands.
RSTCFG runs.  Restores devices, automatically creates matching output 
queues in QUSRSYS.
RSTLIB of QUSRSYS runs.  Get numerous errors like
CPF370B    Information             10   09/18/04  09:07:12.299504 QSRRSLIB 

    QSYS        1015     QSRRLCP2    QSYS        0091
                                     Message . . . . :   QSECOFR owns OUTQ 

P01A14 in QUSRSYS.
                                     Cause . . . . . :   OUTQ P01A14 in 
library QUSRSYS already exists on the
                                       system and is owned by QSECOFR. 
QSECOFR remains the owner although
                                       SYSGENPGMR owned the object at the 
time of the save operation, because the
                                       ALWOBJDIF parameter was specified 
as either *ALL or *OWNER. Recovery  . . .
                                       :   Change the object ownership 
(CHGOBJOWN command), if necessary.
So great, I get to manually change the ownership of 300+ output queues. 
Typed faster than I thought I could.  Users could not get to their spool 
files until I was done.

So, did this preinstall of LIC from IBM media cause this error?  Some 
option I did wrong?  Or was I just numb to it in the past?

I also noticed that V5R3 also added a new option on CHGOUTQ, "Display any 
file" or DSPDTA.  Perhaps a changed default on that caused the issue?

I opened up a pmr with IBM and was given a working as designed kind of 
answer and a suggestion to submit a DCR.  I've submitted several DCR's in 
the past but this strikes me as a significant restore issue.

Oh, by the way.  Also noticed that APACHEDFT web server got resurrected 
from the dead during this restore and allocated port 80 to itself.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
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.