× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. September 2004

Re: Unload/Reload screwed up security.

I think the user profiles got restored:
...
CPC3712    Completion              00   09/18/04  09:03:55.520792 QSRRUCPR 
    QSYS        10DA     QSRRUCPR    QSYS        10DA
                                     Message . . . . :   USRPRF SYSGENPGMR 
restored.
...
CPC3705    Completion              00   09/18/04  09:04:05.006224 QSRRUCPR 
    QSYS        10EA     QMNRSTE     QSYS        0041
                                     Message . . . . :   1565 user 
profiles restored at 09/18/04 09:02:22.
                                     Cause . . . . . :   176 authorization 
lists and 1442 authority holders were
                                       restored with 1565 user profiles. 
If SECDTA(*PVTAUT) was specified on the
                                       command, then only internal objects 
used to restore private authorities were
                                       restored and the user profile 
objects were not restored.
And it was done prior to the RSTCFG and the rest.  Just like the manual.

Maybe a point there on the ptf's.  Except the IBM remark 'working as 
designed' has me a bit concerned.  Also if MFxxxxx has a coreq of SIyyyyy 
wouldn't SIyyyyy not get restored until OS is loaded?  But I believe that 
the RSTCFG, etc all run after the OS is reloaded so I suppose that point 
is moot.

As far as a system recovery; I'm not so sure that a simple SAVSYS after an 
upgrade would suffice anyway.  Aren't there numerous files in QGPL, 
QUSRSYS, etc that get upgraded, along with numerous licensed programs, and 
IFS files?  So, short of doing a complete go save 21 after a release 
upgrade, what would you have to save?  The SAVSYS would allow us to 
preinitialize disk drives I suppose.

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





kirkg@xxxxxxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
09/22/2004 10:12 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Re: Unload/Reload screwed up security.






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


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

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.