Difference in Server and Datastage Director Time

kinu008 · Post by **kinu008** » Wed Oct 12, 2011 8:03 am

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...

PaulVL · Post by **PaulVL** » Wed Oct 12, 2011 9:41 am

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.

kinu008 · Post by **kinu008** » Wed Oct 12, 2011 11:42 am

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

BradMiller · Post by **BradMiller** » Wed Oct 12, 2011 12:27 pm

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.

kinu008 · Post by **kinu008** » Wed Oct 12, 2011 1:57 pm

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

ray.wurlod · Post by **ray.wurlod** » Wed Oct 12, 2011 2:41 pm

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.

BradMiller · Post by **BradMiller** » Wed Oct 12, 2011 3:50 pm

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.

kinu008 · Post by **kinu008** » Thu Oct 13, 2011 6:15 am

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?

ray.wurlod · Post by **ray.wurlod** » Thu Oct 13, 2011 12:57 pm

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).

kinu008 · Post by **kinu008** » Fri Oct 14, 2011 7:53 am

Thanks Ray...