|
midrange.com
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 mailing list archive is Copyright 1997-2025 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.
