Error when trying to move jobs!

rkashyap · Post by **rkashyap** » Mon Feb 24, 2014 9:30 am

During post installation testing of a new DataStage 9.1.2 install ... we are trying to move a set of jobs from one folder to another. This is being done via drag/drop in Designer.

This is working ok for new jobs created in DataStage 9.1.2.

For jobs imported from 8.7:

When the move is attempted under an individual userid ... the operation is successful and Designer repository refreshes after the move.

However when the move is attempted as dsadm ... first job moves and then the operation fails with message given below. Designer repository refresh does not occur.

Error message: An error occurred when executing the operation: Error calling subroutine: DSR_EXECJOB (Action=30); check DataStage is set up correctly in project ENTDATA1_DEV

Exception type: ReposAccessException
Exception message: Error calling subroutine: DSR_EXECJOB (Action=30); check DataStage is set up correctly in project ENTDATA1_DEV
Exception source: IBM.DataStage.RepositoryAccess
Exception stack trace:
IBM.DataStage.RepositoryAccess.ReposAccessException: Error calling subroutine: DSR_EXECJOB (Action=30); check DataStage is set up correctly in project ENTDATA1_DEV
at IBM.DataStage.RepositoryAccess.ReposManager.MoveReposObject(ReposObject thisObject, ReposObject targetFolder)
at IBM.DataStage.RepositoryView.ReposTreeView.treeViewEx_DragDrop(Object sender, DragEventArgs e)
Inner exception IBM.DataStage.RepositoryAccess.ReposException: Error calling subroutine: DSR_EXECJOB (Action=30); check DataStage is set up correctly in project ENTDATA1_DEV

Please note that the above operations were attempted on same client machine. Move operation on both one as well as multiple jobs was attempted.

Please advise.

ray.wurlod · Post by **ray.wurlod** » Mon Feb 24, 2014 5:18 pm

I'm certainly surprised to see a message from DSR_EXECJOB. Did you accidentally request that the selected job(s) be run? For example (unlikely, I know) might you accidentally have pressed Ctrl+F5 ?

IBM Analytics Champion 2009 - 2020 · Post by **asorrell** » Mon Feb 24, 2014 8:07 pm

The first thing I'd recommend is trying syncproject.sh to make sure the project isn't corrupted in some way. I've also seen similar problems when dsadm's PATH is not set correctly. You might want to compare library paths and command paths between the users and dsadm and see if there are any differences.

rkashyap · Post by **rkashyap** » Tue Feb 25, 2014 7:22 pm

Ray and Andy ... Thanks.

We were only trying to move jobs. Jobs were not executed.

On running syncproject.sh ... we found that project was corrupted. On investigating some the corrupted jobs, we found the root cause.

DataStage is using OS Authentication (IMPERSONATION=1 in uvconfig), so project files etc are getting created under individual ids and not DSADM with permission 775.
Default group of some of the users was not same as that of DSADM, consequently the user (and others in same group) who had imported the job was able to move them, but DSADM was not!!!
To make it more interesting ... first job that was getting moved by DSADM was getting corrupted

In order to fix this issue following steps were followed:
1. Default group of all developers was changed to same as DSADM.
2. Group of all the files in project directory was changed to default group of DSADM.
3. Indexes were rebuilt. See link
4. Using SyncProject.sh, most of the corrupted jobs were deleted. See link

Project is mostly in good health now.

Still outstanding ... few of the jobs are appearing in Director but not in Designer. These are not getting fixed by rebuilding index, SyncProject is not identifying these either.
Any attempt to delete these in Director is giving error "Unable to Load RID -".

Please advise.

IBM Analytics Champion 2009 - 2020 · Post by **asorrell** » Wed Feb 26, 2014 8:58 am

If syncproject can't fix it then you'll have to call your service provider. At that point it sounds like some sort of permissions issue in the XMETA database.

If you get desperate, you could try to dump all the jobs, delete them, and reload / recompile them.

rkashyap · Post by **rkashyap** » Wed Feb 26, 2014 1:57 pm

We have raised a PMR for this. Once this issue is resolved, we will post updates.

Is there a way to backup project without having to manually select all "good" jobs. All export attempts at project level are failing due to corrupted jobs.

rkashyap · Post by **rkashyap** » Tue Mar 04, 2014 3:30 pm

IBM has indicated ... DataStage jobs exist in two locations
1. in the repository - this is used to construct the tree displayed by the Designer client and can be queried directly via DStageWrapper -query
2. in the project DS_JOBS file - the indexes on this file are used to construct the tree visible in the Director client.
So the implication is that the the job existed in the project DS_JOBS file but didn't have objects in the repository.

As per there advise bad jobs were manually deleted as per following technote http://www-01.ibm.com/support/docview.w ... wg27021077

Latest situation ... bad jobs are no longer visible in either Designer or Director, but export is still failing with "Object variable or With block variable not set".

************** Exception Text **************
System.Runtime.InteropServices.COMException (0x800A005B): Object variable or With block variable not set
at IBM.DataStage.InteropServices.LateBoundInvoker._InvokeN(String name, Object[] args, Boolean[] byRef)
at VMDataStage._CExporterAPI.Run(String& sOutputPath)
at IBM.DataStage.ComponentExport.ComponentExportClass.DoExport()
at IBM.DataStage.ComponentExport.ComponentExportForm.btnExport_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

ray.wurlod · Post by **ray.wurlod** » Tue Mar 04, 2014 7:44 pm

Do you have any strategy for identifying the corrupted jobs, and how they may have become corrupted?

rkashyap · Post by **rkashyap** » Thu Mar 06, 2014 2:29 pm

Ray,

We had initially tried using SyncProject.sh but it did not identify any issue, subsequently we had visually compared the Director vs Designer job tree and identified mismatches between the two as the corrupted jobs.

We suspect that these may have been corrupted due to permission issue as described below:
1. DataStage is using OS Authentication.
2. Default group of some of the users was not same as that of DSADM.
3. When jobs were imported, the RT_* files/directories were created under individual's id and default group (with permission 775) which was different than DSADM's group.
4. When DSADM was trying to move these to a different folder, the first job (of multiple jobs selected) moved in Designer but changes to RT_* failed due to permissions.
5. Other jobs (of multiple selected jobs) did not move in Designer either. "First job" mentioned above is the one appearing in Director but not in Designer so probably corrupted.

6. As mentioned earlier, the corrupted jobs were manually deleted as per the technote . The corrupted jobs are no longer visible in either Designer or Director, but export is still failing with "Object variable or With block variable not set".

As per communication from IBM, received couple of days back, this PMR has been sent to engineering. We are waiting to hear back from them. I will share the resolution this forum. Thanks.

IBM Analytics Champion 2009 - 2020 · Post by **asorrell** » Fri Mar 07, 2014 4:37 pm

If synchproject didn't find the problem then that also needs to be reported to IBM and resolved, as that is the bigger issue.

As a last resort I've been known to back everything up, delete the project, create a new one and restore everything. That would be a last resort obviously, and is not a decision to take lightly.

rkashyap · Post by **rkashyap** » Fri Mar 14, 2014 2:43 pm

Received update from engineering that they have not seen this form of corruption before and SyncProject can't address this kind of issue - that tool assumes the repository content is valid and ensures that the project directory is consistent with the repository content. In this case the repository content was damaged.

In order to fix it ...
1. Bad jobs were identified using

Code: Select all

./DStageWrapper.sh -domain localhost -user isadmin -password xxxxxxxx -query "select rid(x),x.ParentRID, x.ClassName, x.ProjectNameSpace from x in DSItem where x.ParentRID = null"

2. These were manually deleted.

Everything seems to be in good state.

One surprising thing we saw was ... while investigating this issue, Designer was invoked thru command line (on Windows 7 box) after setting "USE_RMI=TRUE", everything worked fine (i.e. all jobs were visible in Designer and export worked ok), so it was suspected that REST API code isn't correctly handling that content.