Installation of Datastage 7.1

inter5566 · Post by **inter5566** » Tue Jun 15, 2004 8:53 am

@athorne
I ran into the same issue while upgrading from 5.2r5 to 7.1r1. If you followed the upgrade information to the tee, then you may have a problem with the lib_path entries made in the dsenv file. I'm running on an HP-UX 11.11 box and the install instructions suggested to add something like LD_PRELOAD (can't seem to find it now) and this was causing the problem.

HTH,
Steve

Athorne · Post by **Athorne** » Tue Jun 15, 2004 9:11 am

Well that figures! I'm on AIX 5.2, and in the documentation there is a section that talks about a LDR_CNTRL environment setting. The section specifically states this as a measure to put in place for out of memory issues. I didn't bother with this setting because we were having any memory issues.

I went ahead and modified the dsenv to include this variable then logged out of my shell and back in so I could invoke the dsenv again cleanly. Did my echo to verify the value was set, and now my daemon is starting but I'm still getting errors. At this point I'll pursue going back to the -d9 debug to see if I can get some better logging out of this.

Thanks for the suggestion,
Andy

ogmios · Post by **ogmios** » Tue Jun 15, 2004 10:21 am

For the sudo problem: I've also had it and I think DataStage checks whether you're really logged in as root account and not via another account: either by checking the name of the account or checking effective/real user ids.

I haven't figured it out completely but for some DataStage operations you need to be actual root, not a sudo-ed one. Haven't found a way around it.

Ogmios

kduke · Post by **kduke** » Tue Jun 15, 2004 10:52 am

Like I said I upgraded using sudo and it has worked fine for several weeks now. We are on 7.1 without any problems except for SAP. The SAP jobs lose their passwords after upgrading.

ogmios · Post by **ogmios** » Tue Jun 15, 2004 10:54 am

Try using uvregen with sudo e.g.

Ogmios

Athorne · Post by **Athorne** » Tue Jun 15, 2004 4:09 pm

I found the issue. It was related to my custom PS1 prompt for my shell. I set my PS1 in my profile like this.

export PS1='
($PWD)\
$ORACLE_SID':`hostname -s`'>'

Something in the daemon startup must be parsing the environment variables to pickup things like $ORACLE_SID and it's tripping up on this value in my env. I was under the impression that it was picking up these values from the dsenv. After turning my prompt into a simple $ I was able to start the daemon without any issues.

Looking more into the issue it appears it could be related to the : I have in my PS1 prompt to seperate the SID from the Hostname. I'll look more into this and report my final findings.

Thanks again to everyone who helped out on this.
Andy

Athorne · Post by **Athorne** » Wed Jun 16, 2004 9:46 am

It is certainly the PS1 prompt that is causing my issue of not being able to start the daemon with dsadm.

Does anyone have an example of a good prompt they use that doesn't have any issues starting the daemon? I have grown to rely on the $PWD in the prompt and would like to continue to have it, but you really need a two line prompt to keep from running off the shell when you get deep into a path.

I can certainly adjust since it appears to be the only thing keeping me from being able to administrate the daemon. I'm wondering if maybe an alias would be better for me. I'm thinking an alias to perform the daemon start, but setting the PS1 variable to something simple then setting it back after the start. Any ideas or suggestions are most welcome.

Thanks,
Andy