Can't run compile save or create a job
Moderators: chulett, rschirm, roy
Can't run compile save or create a job
Hi
We have created two user accounts on our DS 8.1 servers
dsadm - which is the main admin account. and
bchusr - which is the batch user account which is used by most of our scheduled jobs. individual developers use this account to login to DS and view logs, run/create jobs etc.
See the group membership of the two accounts below -
uid=210(dsadm) gid=15(dsadm) groups=1(staff),206(dsusr)
uid=266(bchusr) gid=15(dsadm) groups=1(staff),206(dsusr)
We have this setup working in other servers just fine. But something has happened on this new server that i am setting up where i am not able to run compile save or create any jobs with the id bchusr.
If i use dsadm - everything works.
But, If i try to compile with bchusr account i get the following three error messages -
Error calling subroutine: DSR_RECORD (Action=2); check DataStage is set up correctly in project PrepBatchUT
(Subroutine failed to complete successfully (30107))
Error calling subroutine: DSR_JOB (Action=5); check DataStage is set up correctly in project PrepBatchUT
(Subroutine failed to complete successfully (30107))
(40503) A call to an OLE server has failed, or a runtime error occurred with the OLE server itself.
if i try to save a copy of an existing job using bchusr account, i am getting this error -
Error creating job CopyOfFTPSPD010OUT into which to copy
Error while creating job CopyOfFTPSPD010OUT
Error on CREATE.FILE command (WRITE attempt on read-only file. Unable to write item "RT_CONFIG1130". *** Processing cannot continue. *** )
I have read all the previous posts on DSR_JOB(Action=5 or 2). But nothing has worked. I have rebooted the server, checked the umask - 002 in ds.rc and have rebuilt indexes etc ...
Any help would be greatly appreciated.
We have created two user accounts on our DS 8.1 servers
dsadm - which is the main admin account. and
bchusr - which is the batch user account which is used by most of our scheduled jobs. individual developers use this account to login to DS and view logs, run/create jobs etc.
See the group membership of the two accounts below -
uid=210(dsadm) gid=15(dsadm) groups=1(staff),206(dsusr)
uid=266(bchusr) gid=15(dsadm) groups=1(staff),206(dsusr)
We have this setup working in other servers just fine. But something has happened on this new server that i am setting up where i am not able to run compile save or create any jobs with the id bchusr.
If i use dsadm - everything works.
But, If i try to compile with bchusr account i get the following three error messages -
Error calling subroutine: DSR_RECORD (Action=2); check DataStage is set up correctly in project PrepBatchUT
(Subroutine failed to complete successfully (30107))
Error calling subroutine: DSR_JOB (Action=5); check DataStage is set up correctly in project PrepBatchUT
(Subroutine failed to complete successfully (30107))
(40503) A call to an OLE server has failed, or a runtime error occurred with the OLE server itself.
if i try to save a copy of an existing job using bchusr account, i am getting this error -
Error creating job CopyOfFTPSPD010OUT into which to copy
Error while creating job CopyOfFTPSPD010OUT
Error on CREATE.FILE command (WRITE attempt on read-only file. Unable to write item "RT_CONFIG1130". *** Processing cannot continue. *** )
I have read all the previous posts on DSR_JOB(Action=5 or 2). But nothing has worked. I have rebooted the server, checked the umask - 002 in ds.rc and have rebuilt indexes etc ...
Any help would be greatly appreciated.
vishal
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Hi Ray
Thanks for coming to my rescue.
The permissions on the project directory were rwxrwxr_x. Both dsadm and bchusr accounts are member of the same groups.
I changed it to rwxrwxrwx just the same.
The permissions on the DSEngine directory are the same -
drwxrwxr-x 37 dsadm dsadm 8192 May 16 02:44 DSEngine
Here is something else that i tried.
I created a new TEST project and logged into it using the bchusr credentials. I can create, compile, run save jobs without any problems into the new project.
So it seems like something has gone wrong with the project itself. It would be great if i could fix whatever has gone wrong because this project is being used by the testing team and they have strict deadlines. For now they are running everything in it with dsadm account.
I guess, if push comes to shove, i can create a new project, export import and compile all jobs into it but this usually takes 4-5 days - we have lots of jobs and i'd rather not do it.
Thanks for coming to my rescue.
The permissions on the project directory were rwxrwxr_x. Both dsadm and bchusr accounts are member of the same groups.
I changed it to rwxrwxrwx just the same.
The permissions on the DSEngine directory are the same -
drwxrwxr-x 37 dsadm dsadm 8192 May 16 02:44 DSEngine
Here is something else that i tried.
I created a new TEST project and logged into it using the bchusr credentials. I can create, compile, run save jobs without any problems into the new project.
So it seems like something has gone wrong with the project itself. It would be great if i could fix whatever has gone wrong because this project is being used by the testing team and they have strict deadlines. For now they are running everything in it with dsadm account.
I guess, if push comes to shove, i can create a new project, export import and compile all jobs into it but this usually takes 4-5 days - we have lots of jobs and i'd rather not do it.
vishal
Did you create the project under a different path (different than default location)?
Also, make sure that your "HOME" directory specifies the "dsadm" user id otherwise your SSH keys may be messed up. If you are still failing add to your project the HOME path and set it to the same path as the home for dsadm. If you are GRID or use SSH to connect to Compute Nodes, this is an issue.
Also, make sure that your "HOME" directory specifies the "dsadm" user id otherwise your SSH keys may be messed up. If you are still failing add to your project the HOME path and set it to the same path as the home for dsadm. If you are GRID or use SSH to connect to Compute Nodes, this is an issue.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
What is the group associated with objects in DSEngine and the 'bad' project? In particular, what are the owner and group of the dssh executable in $DSHOME/bin ?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
group is dsadm (gid = 15)
$DSHOME/bin and objects in it are owned by dsadm:dsadm
I imported the DSX into the nonworking project as dsadm and bulk compiled them with dsadm.
So all the objects under the project directory are also owned by dsadm:dsadm.
However i have similar setup in all other places and bchusr is able to add/modify/run/compile jobs in it.
$DSHOME/bin and objects in it are owned by dsadm:dsadm
I imported the DSX into the nonworking project as dsadm and bulk compiled them with dsadm.
So all the objects under the project directory are also owned by dsadm:dsadm.
However i have similar setup in all other places and bchusr is able to add/modify/run/compile jobs in it.
vishal
chulette i dugged and dugged and could find nothing wrong ...which is why i am here seeking guidance from the all knowing gods of Datastage like you and Ray
I have looked at the file permissions in project directory. They are all at 775 as they should be ...
Where else should i look ?
All this used to work and i know that we didn't change any file permissions or group memberships or anything major.
I have looked at the file permissions in project directory. They are all at 775 as they should be ...
Where else should i look ?
All this used to work and i know that we didn't change any file permissions or group memberships or anything major.
vishal
Unfortunately, there are some things remote people can't always do, like somehow know what exactly is wrong. Is this case, that's going to take someone there, someone with eyes on the problem. All we can do is suggest what kind of things to look for.
If this project "used to work" and now suddenly doesn't, then something changed and you need to see if you can find out what did. However, bottom line is when you are seeing errors like "WRITE attempt on read-only file" you need to determine why that is happening and where the permission problem exists.
If this project "used to work" and now suddenly doesn't, then something changed and you need to see if you can find out what did. However, bottom line is when you are seeing errors like "WRITE attempt on read-only file" you need to determine why that is happening and where the permission problem exists.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
I have created a new project and everything is working just fine in it.
I imported the DSX into this new project while logged in as "dsadm" and then i logged in as "bchusr" and am able to do everything that i was not able to do in the old project. So the testing team is happily working now.
But i couldn't just let it go because from our side there was no difference in how we created the non working bad project and the new working project.
So why is one of them working and one not ?
I tried to chmod -R 775 the entire bad project directory and this is what i have found. It may or may not be relevent -
There are a bunch of RT_SCnnnn directories in the project directory. The directories are owned by dsadm. A few of them are owned by bchusr and the permissions on these directories as well their content, most notably the OshExecuter.sh and OshScript.osh files - is set to RWXR_XR_X or 755.
Which means group and others do not have write permissions
In the new working project these RT_SC directories have a permisison of RWXRWXR_X (775) and the files inside also have write permission for the group - as below -
-rwxrwxr-- 1 dsadm dsadm 844 May 17 23:28 OshExecuter.sh
-rw-rw-r-- 1 dsadm dsadm 4964 May 17 23:28 OshScript.osh
-rwxrwxr-x 1 dsadm dsadm 993 May 17 23:28 V0S481_SOCFileFooter_Transformer_481.trx
-rwxrwxr-x 1 dsadm dsadm 617 May 17 23:28 V0S481_SOCFileFooter_Transformer_481.trx.osh
-rwxrwxr-x 1 dsadm dsadm 996 May 17 23:28 V0S483_SOCFileFooter_Transformer_483.trx
-rwxrwxr-x 1 dsadm dsadm 618 May 17 23:28 V0S483_SOCFileFooter_Transformer_483.trx.osh
Is this relevant ? Why this discrepancy ? What might have caused this ?
I imported the DSX into this new project while logged in as "dsadm" and then i logged in as "bchusr" and am able to do everything that i was not able to do in the old project. So the testing team is happily working now.
But i couldn't just let it go because from our side there was no difference in how we created the non working bad project and the new working project.
So why is one of them working and one not ?
I tried to chmod -R 775 the entire bad project directory and this is what i have found. It may or may not be relevent -
There are a bunch of RT_SCnnnn directories in the project directory. The directories are owned by dsadm. A few of them are owned by bchusr and the permissions on these directories as well their content, most notably the OshExecuter.sh and OshScript.osh files - is set to RWXR_XR_X or 755.
Which means group and others do not have write permissions
In the new working project these RT_SC directories have a permisison of RWXRWXR_X (775) and the files inside also have write permission for the group - as below -
-rwxrwxr-- 1 dsadm dsadm 844 May 17 23:28 OshExecuter.sh
-rw-rw-r-- 1 dsadm dsadm 4964 May 17 23:28 OshScript.osh
-rwxrwxr-x 1 dsadm dsadm 993 May 17 23:28 V0S481_SOCFileFooter_Transformer_481.trx
-rwxrwxr-x 1 dsadm dsadm 617 May 17 23:28 V0S481_SOCFileFooter_Transformer_481.trx.osh
-rwxrwxr-x 1 dsadm dsadm 996 May 17 23:28 V0S483_SOCFileFooter_Transformer_483.trx
-rwxrwxr-x 1 dsadm dsadm 618 May 17 23:28 V0S483_SOCFileFooter_Transformer_483.trx.osh
Is this relevant ? Why this discrepancy ? What might have caused this ?
vishal