Can anyone suggest a reason why RITA would report all times as zero
for a very long running pipeline?
For example:
CPU Utilization by Pipeline Specification 10 Aug 2009 14:48:01
0.000 ( 0.000) ms in pipeline "NoName001" (1 invocation)
0.000 ( 0.000) ms in pipeline "NoName00
Just guessing... Any chance there was an ACCOUNT [ALL] CLOSE executed while
the pipeline was running? Might have caused - CPU to be
negative.
Marty
> -Original Message-
> From: CMSTSO Pipelines Discussion List
> [mailto:cms-pipeli...@vm.marist.e
Doesn't look like it, CP IND USER shows this afterward:
CPU 00: CTIME=56:57 VTIME=444:39 TTIME=474:57 IO=209395
RDR=99 PRT=001197 PCH=068606 TYPE=CP
Doesn't look like the usage counters got reset.
--
bc
On Mon, Aug 10, 2009 at 3:06 PM, Marty Zimelis wrote:
> Just guessing... Any chance th
On Mon, Aug 10, 2009 at 8:53 PM, Bob Cronin wrote:
> Can anyone suggest a reason why RITA would report all times as zero
> for a very long running pipeline?
Will be fixed in 110B0021
For the time being you may be able to get away with an older version from 2008.
Rob
some 31 bit integer counters overflowing someplace?
Bob Cronin wrote:
Can anyone suggest a reason why RITA would report all times as zero
for a very long running pipeline?
For example:
CPU Utilization by Pipeline Specification 10 Aug 2009 14:48:01
0.000 ( 0.000) ms in pipe
Ok, so its a known problem with 110B0020, then. Thanks.
--
bc
On Mon, Aug 10, 2009 at 4:12 PM, Rob van der Heij wrote:
> On Mon, Aug 10, 2009 at 8:53 PM, Bob Cronin wrote:
>> Can anyone suggest a reason why RITA would report all times as zero
>> for a very long running pipeline?
>
> Will be fixed
I have a pipe that builds and issues some commands. It is necessary to have a
single response in the stack for each command that is issued. The scheme that I
came up with is:
'PIPE (end \) ... build commands ... | f: fanout | spec /response/ 1 | stack \
f: | command | cons'
This should work,
"Schuh, Richard" wrote:
> 'PIPE (end \) ... build commands ... | f: fanout | spec /response/ 1 | stack
> \ f: | command | cons'
> if the command fails and crashes the pipe, the worst that can happen
> after the crash is one unrecognized command.
How about when one command fails to read its resp
Not a problem. All of the responses are the same, "END". The next one will read
the first queued response and then clear the stack.
Regards,
Richard Schuh
> -Original Message-
> From: CMSTSO Pipelines Discussion List
> [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Glenn Knicker
