Dear Sir, :)

Thank you for your reply.

>> For those still reading here _and_ interested here the whole PIPE:

> I tried, but I got lost. Possibly because I have a rather complicated pipe in
> pieces on my desk...

It only looks complicated, there are just 4 main parts:

a) two "sniffer stations" for HPIL over IP (aka virtual HPIL). It just look
different than a client-server connection, it's a loop:

>>  '!a:tcplisten' p.in,                 /* get client connected         */
>>  '! take',                            /* one only                     */
>>  '!b:tcpdata linger 1200',            /* read in from the loop        */
>>  '! fblock 2',                        /* make single frames           */
>>  '!c:fanout',                         /* make some copies             */
>>  '!d:tcpclient' exIP p.ex,            /* send it out to the loop      */

There are two of such 'stations', the second with different labels, output to
the rest of the pipeline by FANOUT.

b) for all TCP... stages in both 'stations' the errors are collected here:

>>  '?a:',                               /* errors from TCPLISTEN        */
>>  '!e:faninany',                       /* collect more errors          */
>>  '! pipestop',                        /* in case of error give up     */
>>  '! sort uniq',                       /* if others tell the same      */
>>  '!f:chop after blank',                     /* get leading return code ...  
>> */
>>  '! aggrc',                           /* ... and set RC of this PIPE  */
>> ...
>>  '?f:',                               /* from CHOP                    */
>>  '! term',                            /* send to CRT                  */
and several short-through to e:

c) the side by side output on the terminal:

>>  '?c:',                               /* frames from the loop         */
>>  '! dcf',                             /* decode frame                 */
>>  '!g:fanout',                         /* to COMBINE                   */
>>  '!h:spec STOP ANYEOF',               /* quit whatever stream ends    */
>>    '*-* 1.19 /:/ nw',                 /* frame from first station...  */
>>    'select 1 *-* nw',                 /* ... and from second station  */
>>  '! term',                            /* present to user              */

d) the "delta colorizer", just to highlight the differences:
>>  '?g:',                               /* from FANOUT                  */
>>  '!i:combine x',                      /* spot the difference          */
>>  '! xlate *-* 01-ff 2 00 0',          /* colorize delta               */
>>  '! insert /vsc writ cms 0 24 0 (color /',            /* combine CMDs */
>>  '! insert /;PSC REF/ after',         /* show it immediately          */
>>  '! split ;',                         /* one CMD one line             */
>>  '! cms',                             /* execute the CMDs             */

This is for Fullscreen CMS and looks nice with OTTOSCR what makes
it scroll like an ASCII-Terminal.

So far nothing complicated. The problem is now the "power-up", where
several 'frames' that pass sniffer station 1 may not make their way.
So the question is how to identify when the loop is 'in sync'.

> Reading your problem description, could you not inject an additional null
> record into the pipeline to mark (t2). If you're concerned about timing within
> the pipe, you could mark the records with a TOD clock and use a 'merge' to
> get them in the right order. And juxtapose would then combine the entry
> from both sides, one being either the actual data or the timeout, whichever
> came first?

Thank you for this hint. To mark the records with a TOD tag is a good idea. I 
will try that.

Ciao.....Mike

________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be 
privileged. If you are not a named recipient, please notify the sender 
immediately and do not disclose the contents to another person, use it for any 
purpose or store or copy the information in any medium.

Reply via email to