Installation of Datastage 7.1

ririr · Post by **ririr** » Wed May 26, 2004 5:40 pm

I have installed DS 7.1 on a solaris test box as non-root. I ran the services and impersonsation files to create the rpc service and give the DS adminstrator user the previleges to stop and start DS.

This works fine.

I installed the same as an user that can sudo to root on another solaris box(QA BOX).

I was able install by submitting the following command
"install.sh -admin dsadm" as specified in the DS installation instructions guide

dsadm is another acoount on the box.

I was able to log into the DS server from the DS client after bringing up the services by submitting the following command:

"$DSHOME/bin/uv -admin -start"
Also, the ORACLE_HOME and $ORACLE_HOME(9i) (lib) PATH (LD_LIBRARY_PATH) are defined in the dsenv file.

But , from designer the when I try to connect using OCI9 and DRS stage types, I am getting the following error:

"unable to initialize plug in:"

I made sure that the dsenv file has all the required PATH (libraries)variables defined and even compared with an dsenv file on test box that has DS running.

The only difference between the two installs are

1) Installation done as sudo to root account on QA box

2) dsadm on QA box is defined as sudo user (sudoers file )

I have uninstalled and reinstalled the DS, it didn't helped and has become more worse, that, i can't even create a project during installation.

Any advise or help is appreciated..

Thanks

kduke · Post by **kduke** » Wed May 26, 2004 8:00 pm

We used sudo as well. It worked fine but we had to stop and start DataStage to get it cleaned up. We had similar issues. Some jobs worked fine and some would not connect.

Amos.Rosmarin · Post by **Amos.Rosmarin** » Thu May 27, 2004 3:19 am

Try to look at the env variables in the directors' log and see if the ORA envs are correct.
When you stop the ds server make sure no one is connected and that you have no zombies by running ps -ef | grep uv

HTH
Amos

ogmios · Post by **ogmios** » Thu May 27, 2004 5:13 am

I have been able to install DataStage as non-root, but sofar have never been able to completely get it to work. Reinstall it as root and it works as a charm.

Ogmios

kduke · Post by **kduke** » Thu May 27, 2004 8:13 am

The sudo command will sort of make you root for one command at a time. I worked for me. The Oracle variables in dsenv were double sourced and it confused Oracle. We shutdown DataStage and restarted it and it worked fine.

ririr · Post by **ririr** » Thu May 27, 2004 4:29 pm

Thanks for everyones input.

I was able to resolve the issue with help from Ascential

I had DS 7.1 running on Solaris and Oracle 9i. The $ORACLE_HOME/lib needs to point to 32 bit in dsenv file under DSHOME. This is a prereq. when using DRS and OCI9I stagetypes

Athorne · Post by **Athorne** » Mon Jun 14, 2004 8:25 am

I'm having issues with my install and have also used a sudo solution. My install was done as root and everything went fine except for the fact that the dsadm ID can run $DSHOME/bin/uv -admin -stop, but -start does nothing. I had assumed I would need to run the command as root since root can start it with no issues. I had a sudo command setup and tested it with -info, -stop, but still -start does nothing. No display on the screen and no dsrpc daemon comes up. Anyone else have this issue or know what I'm doing wrong?

Thanks,
Andy

chulett · Post by **chulett** » Mon Jun 14, 2004 8:37 am

Andy, you might want to check out this thread on setting the debug option on 'dsrpcd', it may help you figure out what's going on when it doesn't start.

Sreenivasulu · Post by **Sreenivasulu** » Mon Jun 14, 2004 10:42 pm

A workaround:

We had a similar problem. OCI9i stage was not working. Hence we
reverted to OCI8 box pointing to Oracle 9i database

Regards

chulett · Post by **chulett** » Mon Jun 14, 2004 11:11 pm

They were stating that the dsrpc deamon would not even start. Your OCI problem is a different animal.

On a 64-bit UNIX server, perhaps? You may have run into the issue where the OCI9 stage does not support 64-bit libraries, you must include $ORACLE_HOME/lib32 (not just simply 'lib') in your Shared Library Path in the dsenv file for the OCI9 Stage to work. If you are on a pure 64-bit O/S like Tru64 then you are out of luck (for the time being I assume) and must use the OCI8 stage.

Athorne · Post by **Athorne** » Tue Jun 15, 2004 7:16 am

My issue is a strange one in that the root id itself can start the daemon no problem. My dsadm ID using a sudo command can't start the daemon. When root starts the daemon everything is fine and works like a charm, but not so when I use the sudo command. I'm looking at it today with an SA, hopefully we'll uncover the issue.

Thanks,
Andy

chulett · Post by **chulett** » Tue Jun 15, 2004 8:30 am

Andy, if you check the posting I linked to earlier, it will show you how to set the debug option for dsrpc - and then it will tell you why it can't start.

Athorne · Post by **Athorne** » Tue Jun 15, 2004 8:41 am

I'm sorry, I forgot to post my findings on that. I started the dsrpcd process with the -d9 flag and it created a log that had no conclusive data in it. This was the log entry.

RPCPID=979180 - 09:48:44 - uvrpc_debugflag=9 (Debugging level)
RPCPID=979180 - 09:48:44 - In rpc_init()

chulett · Post by **chulett** » Tue Jun 15, 2004 8:44 am

That's it?

Bummer...

When I needed to use it, it told us exactly what was wrong and it took my SA about two shakes to correct the issue after that.

Good luck! Let us know what you find.

Athorne · Post by **Athorne** » Tue Jun 15, 2004 8:51 am

Not the first time I've had incomplete debugging data, or the ever so wonderful specifically non-descriptive error logging that most software products produce.

At one point I was getting an error generated in the $DSHOME/dsenv.errs.xxxxx file that suggested it couldn't figure out my Oracle_sid variable. That is no longer occuring, and to further confuse the issue the $ORACLE_SID value it was showing was actually my hostname, yet when I would echo $ORACLE_SID it was the correct oracle sid that came up. All this was done in the same shell with the same dsenv being invoked and as the same user.

I've currently got PeopleSoft support pursing the issue, aswell as the SA's at my location to tell me why root can do something but a sudo command can't do the same. My understanding of sudo is that you do not become root, root runs a command on your behalf. If that is true, then there is no reason to believe why root can do something that a sudo command can't do. If I think about this anymore my head may explode.

I'll post what I find good or bad.

Thanks again for all the suggestions,
Andy