Archive

Archive for the ‘Universe’ Category

Rocket Software bought the Universe from IBM

October 22, 2009 Leave a comment

Updated At End

I realized earlier today I referred to Universe as IBM Universe. This more out of habit than anything. As of October 1, 2009, Rocket Software fiinished its acquisition of IBM’s Universe. I learned this only a week ago myself.

So far I am not impressed with Rocket Software. I have twice sent requests for a support account, both times I have gotten no response.

Anyone going to the IBM U2  wiki will find their browser redirected to the rocket software support site. They do have a letter on their site asking customers for patience during the conversion of Universe from IBM to Rocket Software. I will give them the benefit of the doubt on this one. Migrating dev and support for a major product has to be a logistical nightmare. But then I have no emergency right now, so i’m a little more patient.

Updated!!!

I received a call from the Director of Support for U2 on Monday. He was able to pinpoint where my problem was. The route I had taken into their website was the problem. And just as I figured I’m supposed to go through my reseller for access.  As a test to see if Rocket is committed to good support they passed with flying colors in my opinion. Once they found there was a problem they worked to find a resolution right away.

Advertisements
Categories: Universe

Universe 10.2 does not like to move

October 22, 2009 1 comment

Recently I upgraded IBM Universe from 10.0 to 10.2 on an AIX box. The upgrade went fairly smooth; the only annoying part was the licensing. But once the upgrade was performed things went smooth. That was until I had to move things around on the SAN for performance and DR purposes.

Before the /adv partition Universe was installed on was in its own volume/lun on the NetApp filer. The two databases were also in their own volume/lun. This was problematic for multiple reasons. One reason is it provided only 1 r/w path for the databases. Second my snapshots were all separate on the filer. This could create a situation where the two databases were not perfectly in synch (which is a requirement of the ERP that utilizes these databases).  Below is an example of the previous layout.

 To overcome this one larger volume was created on the SAN, with four equal sized LUN’s inside. These LUN’s were presented to the AIX box. On AIX these 4 physical volumes were used to create one large Volume Group. Inside this volume group I created 3 Logical Volumes to house /adv and the two databases.  Below is a simple diagram of this:

As you can see all of the data is now in one volume on the SAN. This allows for a snapshot that guarantees the state of all 3 LV’s are snapped at the same instant. Now each LV also has 4 potential r/w paths to the SAN. This is important because DB1 gets used mostly during the day, and DB2 gets used at night. There has been noticeable IO performance since this change has been made.

So if that went smooth then what went wrong with Universe? I used tar to migrate data from the 3 old LV’s to the new LV’s. When the data was migrated I simply put my mount points where they needed to be full time and started Universe using uv.rc start.

At that point I got the error:

                Invalid .uvconfig

Before moving the data Universe had worked fine. Nothing had gone wrong during the upgrade. After calling our ERP vendor they came up with an answer. IBM in their infinite wisdom decided to change how Universe 10.2 is licensed.  Here is a snippit from the IBM article (I cannot find this online again so I’m just posting it):

‘Invalid .uvconfig’
This error occurs on UniVerse 10.2 because the authorization routine retrieves some inodes from the system, and uses them in the configuration and authorization keys. The inodes may change if UniVerse is copied to another system or an OS upgrade occurs. The list of inodes used is not available publicly. To resolve this error, UniVerse needs to be unauthorized and then reauthorized. The steps with uvregen would be:

1.) run ‘bin/uvregen -u #_users+1’ (changing a parameter, in this case user count, forces UV to become unauthorized). 
2.) run ‘bin/uvregen -u correct_#_of_users’ (change parameter to correct value)
3.) Take configuration code in output and generate authorization code from website
4.) run ‘bin/uvregen -A auth_key’
5.) stop universe, ‘bin/uv -admin -stop’ (uv segment may have been created in shared memory)
6.) start universe, ‘bin/uv -admin -start’

Alternatively, you can reauthorize UniVerse using one of the other methods, ie. Control panel, UniAdmin, or Sys Admin menu.

Since I had used TAR to move Universe from one LUN to another the inodes had obviously changed. This caused Universe to become “unauthorized”. I followed the procedure to reauthorize Universe. After that Universe came up with no problems. As a side note be sure you know how many users you are licensed for, its required for this procedure.

This has impacts beyond this simple migration I did here. It is possible that any AIX or Universe upgrade will cause this happen in the future. It is also likely that if we go into a DR scenario where we use Universe from our backup SAN will require reauthorization of Universe.

Categories: Universe, UNIX