RunProcess, parameters and NOW bug

[PavoGa]

Have found what I consider a bug when passing parameters to a subprocess called by RunProcess. If one is passing a variable initialized by NOW or passing NOW directly to the parameter (see below for an example), the value used in the subprocess is a number, but is not the actual value of NOW in the calling process.

Code: Select all

tStart = NOW;
#... 
# Do something in other process code
#...

tEnd = NOW;
RunProcess('ProcessCaptureStats',
     'pnStart', tStart,
     'pnEnd', tEnd);
     
# OR

RunProcess('ProcessCaptureStats',
     'pnStart', tStart,
     'pnEnd', NOW);

In these two example, no matter what the interval is between the start and end, pnStart and pnEnd will be identical and also about 20 minutes in the past if converted to display time. And if you think that is weird, let's say the master process is executed at, say 10:35 am, so the pnStart/pnEnd in the process evaluate to 10:15 am. For the rest of the day, no matter how many times the master process is executed, pnStart/pnEnd will evaluate to 10:15 am.

Now, this is easy enough to work around; just wondered if anyone else has seen this or similar issues with other functions and RunProcess. We have not seen any other parameter processing issues, but have only tested RAND. We also tested multiplying NOW by one which led to a time about 1.5 hours in the future. Multiplying NOW by two resulted in the process reporting that it completed about 20 years ago. So, armed with this knowledge, we can provide finance departments with the ability to complete their work years ago.

We did a good bit of testing. For now, just going to convert the NOW results to a string and pass that to the sub.

[gtonkin]

Could be precision - have you tried multiplying by 1,000,000 then dividing on the other side?

[PavoGa]

Has nothing to do with precision. The test was a simple SLEEP(variable.ms.seconds) before the ending time call to NOW. I failed to mention that substitute ExecuteProcess for RunProcess and the values are passed with no problem. Multiplying the variables and/or NOW simply resulted in a ripping of the space/time continuum.

I posted this because of potential concerns passing values as a result of assigning function results to variables and/or directly to parameters. If bizarre behavior with RunProcess is observed, this could be the problem.

[declanr]

It's an interesting one and I thought that gtonkin was on the right path so I did a test myself with below processes:

Parent:

Code: Select all

cProcChild = 'Child';
nNow = Now;

AsciiOutput ( 'c:\Parent.txt', NumberToString ( nNow ) );
nNowMega = nNow * 1000000;
RunProcess ( cProcChild, 'pnNow', nNow , 'pnNowMega', nNowMega, 'psNow', NumberToString ( nNow ), 'pnNumber', 21958.840405093 );

Child:

Code: Select all

nValue = 21958.840405093;

AsciiOutput ( 'c:\Child.txt', NumberToString ( pnNow ), NumberToString ( pnNowMega \ 1000000 ), psNow, NumberToString ( pnNumber ), NumberToString ( nValue ) );

Results:

Code: Select all

"21958.8","21958.8","21958.847002315","21958.8","21958.840405093"

1/ Simple pass of numeric now = everything truncated after first decimal of precision
2/ Multiply numeric now by million in parent; divide in child process = everything truncated after first decimal (I also did this with out the division in the child process and ended up with the truncated date still)
3/ Convert the Now to String before passing in string parameter = THIS WORKS!
4/ Directly passed a numeric value that was hardcoded in parent process = still truncates everything after first decimal
5/ Directly output a numeric value in child process (not from parameter) = THIS WORKS!


So as far as I can see its a definite bug. Very odd.

[declanr]

I've edited the above post a few times already as I keep thinking of extra steps to test.

If I pass 1.2344567778 * 1000000 from the parent process it gets truncated in the child's asciioutput.
So its as if the runprocess seems to back trace any numeric value to its starting point and assess whether that has decimals - instead of looking at whether the end result has decimals.

I'm a bit worried as I've been using RunProcess a lot and haven't noticed this... really just crossing my fingers that I haven't been passing numeric parameters anywhere!

[PavoGa]

...
3/ Convert the Now to String before passing in string parameter = THIS WORKS!
4/ Directly passed a numeric value that was hardcoded in parent process = still truncates everything after first decimal
...

So as far as I can see its a definite bug - it doesn't impact passing of most numeric values; just ones derived from a NOW function. Very odd.

3/ is the solution I implemented.
4/ This is what I was concerned about, just had not run into it as so far, any parameters being passed have been strings or integers to our subprocess using RunProcess.

It does not seem to affect all numeric decimal values as RAND seems to work just fine, at least in my testing.

[PavoGa]

I've edited the above post a few times already as I keep thinking of extra steps to test.

If I pass 1.2344567778 * 1000000 from the parent process it gets truncated in the child's asciioutput.
So its as if the runprocess seems to back trace any numeric value to its starting point and assess whether that has decimals - instead of looking at whether the end result has decimals.

I'm a bit worried as I've been using RunProcess a lot and haven't noticed this... really just crossing my fingers that I haven't been passing numeric parameters anywhere!

If you think that is odd, try multiplying NOW by two and passing that to the process. It is not just truncating, it goes back 20 years. I used FormatDate to test the values and got that result.