Debugging RunProcess

Arc & Slice
1

Hi,

We have some TI master processes with “RunProcess” command scripted in,

Is there a way to “Step In” into the TIs run through the RunProcess command via Arc?

Thanks!
Andrew

2

Hi @AndrewW,

What version of Arc are you using? If it doesn’t work on the latest version (1.8) which has better support for debugging sub-processes I am guessing it isn’t possible.

3

Hi Tim,

We are running v 1.6.0 currently.

Do we need to upgrade or can this just be quickly tested from your end?

Thanks
Andrew

4

Hi @AndrewW,

You should upgrade anyway, there are lots of improvements including new subset/dimension editors and a cube viewer. You just need to replace the arc.exe.

If 1.8 doesn’t fix your issue create a ticket at: Issues · Cubewise CODE / Arc and Slice · GitLab

5

By definition RunProcess is executed on a separate thread. So I don’t see how this could ever be stepped into in the debugger! If you want to debug a sub-process that is called with RunProcess then wouldn’t it be better to change to ExecuteProcess for the purpose of debugging or just debug the sub-process independently with the same parameters as would have been passed from the calling process?

6

Thanks for the reply,

The reason why I wanted to debug the RunProcess and not ExecuteProcess is because for whatever reason, it seems to have overrun a previous process that was triggered via an ExecuteProcess function.

To put it simply, I have a master process that called 2 sub-processes. The first sub-process is run via the “ExecuteProcess” function. The second sub-process is run via the “RunProcess” function.

The second sub-process seems to have retrieved cube data that was supposed to be changed via the first sub-process, but this wasn’t the case.

If I change the second sub-process from RunProcess to ExecuteProcess then it works ok.

Cheers
Andrew

7

Hi @AndrewW,

I am not sure you will be able to do that as the processes (when using RunProcess) run on a different thread with a different transaction. The second process can’t see the results until the master process has completed and changes are committed. If you use ExecuteProcess it can see the changes because it is running on the same transaction and has access to the “shadow” copy of changes.

8

@tryan

That’s interesting what you said, because that logic supports what we are currently experiencing.

HOWEVER, I tried to replicate the situation using GO_Scorecards sample database, and create the same setup:

1 Master process to do:

  • ExecuteProcess sub-process 1 (cellputs)
  • RunProcess sub-process 2 (cellgets)

But i’m getting a different result. I’m retrieving the data that was changed from the first sub-process. So that contradicts that theory.

I’m not sure if it’s a cfg thing between the 2 TM1 services that may have caused this variance.

Cheers
Andrew

9

Hi @AndrewW,

It could just be a based on timing, i.e. ExecuteProcess sub-process 1 completes before RunProcess starts. Put a delay in there with a long while loop and see if you get the same results.

10

@AndrewW I don’t think that will make any difference. All sub-processes that are part of the same master process through a chain of ExecuteProcess are all part of the same transaction. Until the master process finishes its epilog and commits, any data changes made by processes within the transaction will be available only to other processes that are part of the transaction. From an external perspective no changes made during the transaction are available until the final commit. Any and process using RunProcess is not part of the same transaction. So the copy of the data it has available is the state of the data model BEFORE the commencement of the master process.

This is an important thing to understand about TM1’s commit model with respect to TI. It’s the reason why cube value based sepaphores are neigh on impossible to use and file based or ODBC based are better.