|
I eventually did get the image catalog upgrade to run on the 170, after deleting the PTF image catalogs. All the images were in different directories, e.g. /imgclg/upgrade, /imgclg/cumulative and /imgclg/groups. I did do the license acceptance prior to the upgrade. Regards, Scott Ingvaldson iSeries System Administrator GuideOne Insurance Group -----Original Message----- date: Fri, 28 Oct 2005 12:02:45 +1300 from: Evan Harris <spanner@xxxxxxxxxx> subject: Re: Image Catalogs for Upgrades Hi Scott I did a test of the same process on a 170, and I'm pretty sure it was even the same cume level (C4244520) and that worked fine doing the upgrade, so I'd guess it's not that. I didn't figure out at the time how to cause the V5R3 upgrade to continue and do the whole PTF thing as well although I wanted to (I still haven't figured out whether this is possible) One thing that occurs to me: did you load all the files into the same directory or did you copy them into separate subdirectories ? In other words, did all the Image Catalogs exist in the exact same directory ? Also, did you load the PTF required to do the license acceptance thing in advance of the upgrade ? Regards Evan Harris At 09:44 a.m. 28/10/2005, you wrote: >Since this topic is being discussed today: > >Back in February we upgraded our test box (V5R2 - V5R3) from an Image >catalog. The system was at C4244520 with all of the required Image >Catalog and upgrade PTF's. > >It appeared that having multiple image catalogs on the system caused >the LIC install to hang. I had the LIC and O/S in image catalog UPGRADE05. >I also had image catalogs CUMULATIVE and GROUPS. The command entered >was: PWRDWNSYS OPTION(*IMMED) RESTART(*YES) IPLSRC(*IMGCLG) >IMGCLG(UPGRADE05) > >After the LIC installs hung at srcC6004001 (three times) I would IPL >and find image catalog UPGRADE05 unloaded from OPTVRT01 and either >CUMULATIVE or GROUPS loaded. After deleting image catalogs CUMULATIVE >and GROUPS the LIC install completed successfully and I was able to >continue with the O/S install. > >Supportline opened a discussion group and their conclusion was that >they had never seen this before and that it might have something to do >with the system being an older 170. > >Two weeks ago I upgraded our prod system, an 810 and ran into the same >issue again. I IPLed, deleted the PTF image catalogs with DLTIMGCLG >IMGCLG(xxxx) KEEP(*YES) and then completed the upgrade successfully. >After the upgrade I recreated the image catalogs using CRTIMGCLG >IMGCLG(CUMULATIVE) DIR('/imgclg/cumulative') CRTDIR(*NO) and ADDIMGCLGE >IMGCLG(CUMULATIVE) FROMFILE('/imgclg/cumulative/C5207530_01') >TOFILE(*fromfile) Since the images were already loaded the add >completed in about a second. > > >SupportLine STILL says that they have never heard of this problem from >anyone other than me. One recommendation was to load all of the PTFs >in one image catalog rather than two, but they still can't go in the >same one as the upgrade images so I'm not sure what difference that >would make. > >The upgrade completed very quickly using the image catalog, about two >hours not counting IPLs. I like the image catalogs for upgrades; it >sure beats standing there swapping CD's all night, but I would like to >be able to preload the CUME and groups also. As far as normal PTF >operations go there doesn't seem to be much advantage to image catalogs >unless you are downloading the ePTF .bin files. If you use CD's the >effort is the same. > >My biggest concern here is that the whole idea is to automate the >process. If I have to stand there and watch it then the image catalogs >are useless to me. I need to have a reasonable expectation that an >image catalog upgrade will complete succesfully. > >Has anyone had similar experiences or is this just an id10t error? I >have not seen this behavior documented and SL seems to think that it >should not work this way. > >Regards, > >Scott Ingvaldson >iSeries System Administrator >GuideOne Insurance Group
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.