Solved: Problem upggrade SD 4.2 to 4.2.2

reinstall SD 4.2 and then apply patch for upgrade to 4.2.2
solved the problem.
this was a solution from ibm support.

Raluca Baciu

Business Information Systems S.R.L. (BIS)
746741 Bucharest, Lucretiu Patrascanu Street, Bl. MY3, 5th Floor, Sector 3
P.O. BOX: 37-166
Tel/Fax:  +40 21 255 45 77, +40 21 255 45 78
Mobile: +40 0722 302 270
Web: http://www.bisnet.ro


This message is strictly confidential, between the emitter's and the
addressee's companies.
It's mandatory to have the approval of the initiator, to send it entirely or
partially, to a third company.

Acest mesaj este strict confidential, pentru companiile emitentului si
receptorului.
Pentru a putea fi transmis, intreg sau partial, unei terte companii, este
obligatoriu a avea aprobarea initiatorului
----- Original Message ----- 
From: "Thomas Seeling" <TSEELING-tA70FqPdS9bQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
To: <tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 22, 2005 8:28 AM
Subject: [tme10] Problem upggrade SD 4.2 to 4.2.2


> Hallo,
>
>
> > you the log from failed installation, I think that after it sees that
> > Inventory is not upgraded, it removes ProductInfo for swdis!!!:
>
> it is definitely a problem in the installation script to delete the swdis
> ProductInfo object
> in case of a failed inventory upgrade. Open a PMR for this one.
> A failure must not destroy existing information.
>
> To create a new swdis object try this (after wbkupdb of course):
> identify a ProductInfo object that looks nearly similar to the missing one
> (i.e. installed on the same machine/s).
> wlookup -ar ProductInfo swdis # looking for regex swdis
> # pick one OID from the list.
> objcall $OID o_clone 1 # clone this object
> # note the OID you get.
> idlattr -ts $newOID label string '"swdis"' # label it "swdis"
> # wregister the OID you get with the resource ProductInfo.
> wregister -r ProductInfo swdis $newOID
> wchkdb -ut
>
> It might be that after the deletion of the previous swdis object the
> connection
> between product and patches is missing, wchkdb should be able to repair
> this
> (there might be PatchInfo objects referring the "old" #670 object).
>
> Alternatively you could extract the ALIDB after script from your swdis
> installation (4.2):
>
> no=`grep :fp swdis.ind | grep w32-ix86| cut -d: -f7`
> $BINDIR/TAS/INSTALL/sapack -u -D install_progs=yes -mc FILE.$no
> look in TivoliCntlDir/FILE.$no/nt_after.sh for the code that creates a
> ProductInfo object.
> -mc is vital so that the after script is not executed after unpacking.
>
> In case you have a backup TMR server you could extract the 670 object from
> there
> by restoring a good backup to that machine and getting all attributes from
> the backup.
>
> Tschau...Thomas
> --
> "Do you wanna be a legend or a passing footprint on the sands of time?"
>
> Senior Consultant, Tivoli Certified Enterprise Consultant + Instructor
> santix AG, www.santix.de, info-/JKUMw0Y9jazQB+pC5nmwQ@xxxxxxxxxxxxxxxx, fon 
> +49-89-321506-0, fax -99
> Weihenstephaner Str. 4, D-85716 Unterschleissheim, GSM +49-170-9135811