Multiple versions of Information server

kishore2456 · Post by **kishore2456** » Tue Jul 17, 2012 4:33 am

Hi,

We have two linux boxes having different version of Infomration server, 8.5 and 8.1. We need to move 8.1 from the existing box to the box where 8.5 is installed. We haven't configured iTAG while installing 8.5

Can you let me know what should be the best approach?

jwiles · Post by **jwiles** » Tue Jul 17, 2012 8:41 am

Questions to be answered:

1) Which tiers of IS 8.1 will you be installing onto the target box?
2) Is the operating system version of the target box supported by IS 8.1?
3) Does the target box have the resources to properly run all of the IS 8.1 and 8.5 tiers which will be installed on it, the number of users who will be logged in, as well as any jobs which will run on it?
4) Why not migrate the existing 8.1 jobs to 8.5 instead?

Regards,

PaulVL · Post by **PaulVL** » Tue Jul 17, 2012 9:34 am

I agree with point #4. Migrate your 8.1 code to 8.5.

You will have less support costs in the long run.

Less patching, less confusion, 8.5 is faster than 8.1 (compressed datasets for example).

kishore2456 · Post by **kishore2456** » Tue Jul 17, 2012 11:13 am

Hi Jwiles.

1) Which tiers of IS 8.1 will you be installing onto the target box?
Engine tier and services (DataStage only)
2) Is the operating system version of the target box supported by IS 8.1?
Yes
3) Does the target box have the resources to properly run all of the IS 8.1 and 8.5 tiers which will be installed on it, the number of users who will be logged in, as well as any jobs which will run on it?
The server has more than 100G of RAM. Should be enough
4) Why not migrate the existing 8.1 jobs to 8.5 instead?
The business doesn't want to chance any risk involved in migrating at the moment.

jwiles · Post by **jwiles** » Tue Jul 17, 2012 1:34 pm

This would be a migration of a sort anyway as you will not be able to simply pick up and "move" the 8.1 installation to the target server.

Issues I see are:

1) Will need to install Services tier using different (non-default) ports
2) Will need to install Engine tier using ITAG and non-default ports
3) Both tiers should be installed within a separate mount point from the existing 8.5 installation
4) You will likely not be able to read parallel datasets created by 8.5 jobs with 8.1 jobs.
5) You will need to be very careful about sharing userids for DataStage between the two versions...you don't want to accidentally run $DSHOME/dsenv for 8.1 when you need to access 8.5, or vice versa.
6) You need to verify that any third-party software used by DataStage, such as database clients, are either compatible with both IS versions OR that you can install two versions of the software.
7) Export and Import your jobs from the existing 8.1 environment into the new 8.1 environment.

If the business is insistent upon not migrating the jobs to 8.5 (which I would recommend instead of the above), I suggest contacting your official support provider for more detail on what will need to be done. It's possible, but will take planning and as I indicated it's pretty much a migration itself.

Regards,

PaulVL · Post by **PaulVL** » Tue Jul 17, 2012 2:38 pm

James, doesn't some of the underlying scripts in the engine read /.dshome ?

Two different versions of Websphere running on the box! ouch.

Kishore2456... I would not want to tackle that.

If you are going to tackle it and you are on an AIX box, separate it into it's own LPRA and it would look like it's own server and hostname. I would not double up under one hostname.

ray.wurlod · Post by **ray.wurlod** » Tue Jul 17, 2012 6:39 pm

I believe that, if environment variable DSHOME is set, the scripts prefer that value to anything specified in /.dshome.

That said, I also believe that IBM explicitly forbids any other 8.x version being installed alongside 8.5.

jwiles · Post by **jwiles** » Wed Jul 18, 2012 10:28 am

Paul, I don't recall if any of the as-installed scripts read /.dshome directly. However it is a quite common practice to initialize the value of $DSHOME using export DSHOME=`cat /.dshome` when creating/modifying scripts after installation. That being said, I think I'll go check one of my installs to make certain my foot is where it belongs...

CORRECTION: dsenv as-installed does indeed read /.dshome directly to set $DSHOME Removing foot to proper location.

Regards,