Page 1 of 1

Datastage Director Scheduler issue

Posted: Fri Sep 25, 2015 1:33 am
by ninsekh
Since two weeks ago, we found that director datastage scheduler module doesn't work correctly.
All jobs scheduled to run only no longer work :?: .

Please help us to find solution for this issue :idea: .
Best regards

Posted: Fri Sep 25, 2015 1:46 am
by kandyshandy
Can you share more details? Are you getting any error message after the job triggers? OR The job/sequence not even getting triggered?

Report to your UNIX/DS admin as they can narrow down the root cause quickly.

Posted: Fri Sep 25, 2015 2:28 am
by ninsekh
Hi Kandyshandy,


unfortunately, we have no logs because any scheduling job doesn't run.

We don't understand.

Best regard !

Posted: Fri Sep 25, 2015 2:35 am
by ArndW
Since you are on UNIX, the scheduler will use cron. After scheduling a job with the director, have someone check the crontabs to see what is scheduled to start; and one can also check the cron logs to see what happened (or didn't, as the case may be).

Posted: Fri Sep 25, 2015 2:55 am
by ninsekh
Our datastage application is in Unix Solaris 8 environment.

I use command tail -f /var/adm/messages to see logs and i obtaint row below:

Sep 21 11:00:40 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 21 12:22:19 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 21 12:22:48 SRVLUM-DWH2 last message repeated 1 time
Sep 21 16:13:57 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 21 16:21:14 SRVLUM-DWH2 sshd[27328]: [ID 800047 auth.error] error: Could not get shadow information for NOUSER
Sep 21 16:27:40 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 22 04:51:04 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 22 10:04:21 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 22 10:19:07 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 22 10:23:34 SRVLUM-DWH2 last message repeated 2 times
Sep 23 02:04:11 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 24 01:13:19 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 24 09:25:07 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 24 09:27:00 SRVLUM-DWH2 last message repeated 1 time
Sep 25 01:15:19 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 25 07:39:44 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 25 07:59:38 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)
Sep 25 08:06:55 SRVLUM-DWH2 su: [ID 810491 auth.crit] 'su root' failed for dsadm on /dev/pts/1
Sep 25 08:52:26 SRVLUM-DWH2 ufs: [ID 879645 kern.notice] NOTICE: /u05: unexpected free inode 8459525, run fsck(1M)

Posted: Fri Sep 25, 2015 2:57 am
by ninsekh
SRVLUM-DWH2 is the hostname.

Best regards

Posted: Fri Sep 25, 2015 3:04 am
by ninsekh
/u05 is the Engine directory where we have stored different datastage designer jobs.

Best regard !!

Posted: Fri Sep 25, 2015 5:35 am
by qt_ky
Log into UNIX as the user who schedules the jobs and run command crontab -l to list the schedules, if any. Maybe they got deleted.

Also have a UNIX admin look into those errors you listed above. Maybe the disks lost data or got corrupted.

Posted: Fri Sep 25, 2015 9:44 am
by rkashyap
Check if Unix password of of user who has scheduled the jobs is expired.
Cron (in Solaris) utilizes PAM. If Unix password is expired, all cron jobs scheduled by the user are suspended. If this the case, then simply reset the password.

Posted: Fri Sep 25, 2015 3:36 pm
by ray.wurlod
Although unrelated, you should run fsck fairly soon.

Check that the user is recorded in both the cron.allow and at.allow files.