|
Hi, With all due respect, I was not referring to running in a restricted state (which came in V4R1) versus the relationship of RSTUSRPRF to RSTAUT. Al - in Charlotte on vacation Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com thomas@inorbit.com Sent by: To: midrange-l@midrange.com midrange-l-admin@mi cc: drange.com Subject: Re: go restore optn 21 source code 03/27/02 05:53 PM Please respond to midrange-l Al: I can't claim it'll work except to point to this quote from the V4R3 Backup and Recovery guide, chapter 17, topic 3.8.4.2 Restoring Authority On a System in a Non-Restricted State: <quote> There are several advantages to running the RSTAUT command on a system in a non-restricted state. These advantages include the following: <snip> Authority reference tables are not always deleted after RSTAUT is run for a user profile. If all private authorities are successfully granted or an abnormal error occurs then the authority reference table is deleted. If some of the private authorities are not granted for any reason such as 'object not found' or 'object in use', then the entries for those private authorities that were not granted are kept in the authority reference table, and the RSTAUT command may be run again for the user profile to try granting the failed private authorities before the next IPL or the next restore of the user profile. </quote> This seems to contradict the direct documentation of the RSTAUT command itself but it makes some sense. Tom Liotta On Wed, 27 March 2002, "Al Barsa/Barsa Consulting" wrote > For each and every RSTAUT, you need to do a previous RSTUSRPRF. RSTAUT > propagates the specific authorities from the user profiles to the objects > themselves. It is critical that you do NOT to a RCLSTG between RSTUSRPRF > and RSTAUT, because RCLSTG takes the authorities on the objects, and > spruces up the user profiles. The would be tantamount to the MAKEAMESS > command. > > Evan Harris > <spanner@ihug.co.nz To: midrange-l@midrange.com > > cc: > > my recollection is that Tom's suggestion will work. I have done this a few > times to get parts of applications working again before the entire restore > is completed. > > So you could RSTUSRPRF then -> RSTLIB -> RSTAUT -> RSTLIB -> RSTAUT as many > times as necessary. > > In the old days - slow tape drives and no raid (not to mention 3370's and > 9332's) - a staged recovery allowed a business to be restarted well before > the entire recovery was completed. > > Maybe this has changed but I'd be surprised. > > regards > Evan Harris > > > >Won't work again without restoring profiles again... > > > >thomas@inorbit.com wrote: > > > > > > Steve: > > > > > > I've never had to do this, but for future reference it might work > > > for somebody. Maybe someone could verify this. > > > > > > Given the sequence that you first ran the commands in, it seems > > > possible that simply running RSTAUT a second time after you ran > > > the others would've fixed most problems. I wouldn't expect > > > running RSTAUT twice like that to cause more trouble. > > > > > > Tom Liotta > > > > > > On Mon, 25 March 2002, "Steve Richter" wrote > > > > > > > The reason I asked is because the procedure in backup and > > > recovery , chapter > > > > titled: "How to restore specific types of information" ( chap > > > 17 in my v4r3 > > > > version ) has the wrong sequence of events. > > > > > > > > It says "the topics are presented in the same order as the > > > recovery > > > > operations should occur". > > > > First is RSTUSRPRF, next is RSTAUT !!, then RSTCFG, RSTLIB, ... > > > Following > > > > these steps caused all sorts of problems which I corrected by > > > restarting the > > > > scratch install. > > > > > > > > -----Original Message----- > > > > From: midrange-l-admin@midrange.com > > > > [mailto:midrange-l-admin@midrange.com]On Behalf Of Kirk Goins > > > > > > > > It may be there somewhere... The Backup and Recovery guide > > > gives you each > > > > cmd > > > > > > > > Here's the short version > > > > RSTUSRPRF > > > > RSTCFG > > > > RSTLIB *NONSYS > > > > RSTDLO > > > > RST > > > > RSTAUT > > > > > > -- > > > Tom Liotta > > > The PowerTech Group, Inc. > > > 19426 68th Avenue South > > > Kent, WA 98032 > > > Phone 253-872-7788 > > > Fax 253-872-7904 > > > http://www.400Security.com > > > ___________________________________________________ > > > The ALL NEW CS2000 from CompuServe > > > Better! Faster! More Powerful! > > > 250 FREE hours! Sign-on Now! > > > http://www.compuserve.com/trycsrv/cs2000/webmail/ > > > > > > _______________________________________________ > > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > > > To post a message email: MIDRANGE-L@midrange.com > > > To subscribe, unsubscribe, or change list options, > > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > > or email: MIDRANGE-L-request@midrange.com > > > 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@midrange.com > >To subscribe, unsubscribe, or change list options, > >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > >or email: MIDRANGE-L-request@midrange.com > >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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. -- Tom Liotta The PowerTech Group, Inc. 19426 68th Avenue South Kent, WA 98032 Phone 253-872-7788 Fax 253-872-7904 http://www.400Security.com ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/ _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com 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-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.
midrange.com
