Page 2 of 2

Posted: Wed Oct 12, 2011 8:03 am
by kinu008
Hi, Thanks a lot for reply.. Please see my answers in bold below:

[quote="PaulVL"]Look at your profile. - I did not setup anything in profile

Which user id are you loging in with via telnet? - My own user id.. I did an su to dsadm and executed sh -c date (from telnet) which shows correct time as well... Only director shows incorrect time

Is it the same user id that is executing datastage (dsadm) ?

Look at the profile of that ID. Are you setting your time zone?

How is the time on the server causing you an issue? we will use mainframe scheduler to run jobs

Are you relying upon the internal job scheduler to trigger jobs?

Are you extracting server time via a routine and using that to populate some of your date fields? - Yes, i am populating some database fields using a routine...

Posted: Wed Oct 12, 2011 9:41 am
by PaulVL
ok, but you still have not answered the question: What issue are you facing?

At my site we use Mainframe CA7 scheduler.

Mainframe has a different timezone than my Linux servers.

No issues.

So... what is your concern with having a Unix server in Denver timezone?

Your personal user id is not the ID that your jobs would run under right?
Your personal ID most likely has an entry in your ".profile" to set your default timezone.

next time you "su other_id" do this: "su - other_id". That will source the profile I believe.

Posted: Wed Oct 12, 2011 11:42 am
by kinu008
Hi Paul,
I think I did not do a good job of explaining the issue... Will try one more time...

Time Zone/Time on UNIX Server (from telnet) is accurate (EDT American/New York)...
Problem is that the Time Zone when viewed from Director/Administrator is correct whereas the actual time from Director/Administrator is advanced by 4 hrs... When I execute 'sh -c date' at director command prompt, it says EDT America/New York, which is fine, but it shows the time as 17:00 when the actual time is 13:00...

My UNIX admin just confirmed that both time zone and time on server are correct (from root profile)... but he has no clue why datastage has correct time zone (EDT America/New York) but incorrect time...

As I said, I am populating some database fields using routines so its kind of must for DataStage to fetch correct times...

Thanks a lot for your help,
Kiran

Posted: Wed Oct 12, 2011 12:27 pm
by BradMiller
You have appended your problem onto a posting created by Sreedhar. Did you try his solution in the post dated Mar 22, 2010 9:26 am? Sreedhar was our admin when he created this post and the solution he found fixed our issue which sounds just like the problem you are discribing. Of course, since you are in a different time zone, you wouldn't use the same setting; you would have to use the EDT setting.

Posted: Wed Oct 12, 2011 1:57 pm
by kinu008
Hi Brad.. I totally missed Sridhar's post... Thanks for pointing that out...

quick question.. where exactly should I add that text (export TZ=EST8EDT) with in dsenv file? at the beginning or middle or at end of the file?

Thank you, Kiran

Posted: Wed Oct 12, 2011 2:41 pm
by ray.wurlod
In general it does not matter where in dsenv the TZ environment variable is set, except to note that, if it occurs more than once, the last one will win.

Posted: Wed Oct 12, 2011 3:50 pm
by BradMiller
As Ray said, it doesn't really matter where in the dsenv file you set the variable. I don't know the different time zone settings very well, but I would think for US Eastern, you would use EST5EDT instead of EST8EDT.

Posted: Thu Oct 13, 2011 6:15 am
by kinu008
Thanks a lot Ray and Brad.. problem solved... time and time zone looks good now :) but I still don't understand why I had to manually add the parameter... we do have NLS enabled.. is it because of that?

Posted: Thu Oct 13, 2011 12:57 pm
by ray.wurlod
No. It's because TZ wasn't set in the environment of the user acting as the agent process of your client (probably dsapi_server or dsapi_slave).

Posted: Fri Oct 14, 2011 7:53 am
by kinu008
Thanks Ray...