DSXchange

Hi,

I have a very strange problem. After change uvtemp parameter in uvconfig, the datastage service is recycled, then, I found out I was not able to log in to datastage (director, manager etc.) with my original account.

The message I got is like
'Failed to connect to host: fosentsvr02, proect PROD_GAMING [Internal Error (39202))

Any suggestions?

Carol

Any change to your uvconfig must be followed by a regeneration of DataStage.

Possible reasons for connection problems are:
1.) Change in dsenv
2.) DataStage not restarted
3.) DataStage was not brought down properly - maybe some hanging zombie process.

Bring DataStage down. Check 'netstat -na | grep 31538'. This must not return anything. If it does, something is still holding the port.

You can search for other posts on how to perform this.

Hi -

What parameters did you change ?

Don't know if the following applies for DS 6 on Unix.
On DS 7.5 on Windows you have this bug -
If you change RLTABSZ to a value greater then 180 then you will see a behaviour similar to the one you describe. Uvconfig will get completely corrupted and it cannot be changed back with uvregen. Only way I could get DataStage back again was to
- either uninstall and reinstall DataStage
- make a new identical DS installation and use the new uvconfig file

Regards
Peter

Hi again -

"What parameters did you change ? " - Forget this question - you wrote it clearly in your mail - sorry.

Regards
Peter

Did you shutdown the Engine when there were still active connections?
Doing a netstat -a | grep dsrpc will verify this. If so, then on HP-UX 11.11 the only remedy was an OS re-boot.

If you change uvconfig then as indicated already you need to regen as follows:

cd $DSHOME
. ./dsenv
bin/uv -admin -stop
bin/uv -admin -regen
bin/uv -admin -start

Did you start DataStage as root or as dsadm? If the problem persists, try the other one. Also make sure that dsrpcd starts.

Hi All,
I just had the same error :
Failed to connect to host: hosname, project: projectname
(Internal Error (39202))

This happened for no aparant reason.
users were working sysadmins were already off so they were not meesing with anything AFAIK.
and for some reason every client dissconnected and any new connection atempts gave the above error.

I brought the dsrpcd down (since no new connections were available and issueing uv gave wiered messages to contact sysadmin.
eventually I found an on duty sysadmin who killed all dsapi hung processes and netstat was finally cleard
to allow me to bring dsrpcd back up, now it seems to work.

My main concern now is what caused this or what may cause this again???

any ideas???

One simple reason is people leaving things on for a long time. Next one is not doing periodic maintenance and bouncing DS system to clear any unwanted process.

Are you sure you have write permission to the new uvtemp directory?

Hi,
in my case bouncing the dsrpcd solved the issue, hence nothing in terms of permitions,changed configuration, ... should have caused this simply since I didn't change anything ot get it working again.