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