Piping the output of a DO loop.

May 20, 2008
10,670
83
Syracuse, NY, USA
I have a BTM that was working fine in both v24 and v25. It produces output like this.
Code:
v:\> timecheck.btm
                        LOCAL
HOST                    OFFSET  STRATUM RTT
0.ubuntu.pool.ntp.org   -0.007     2    21
2.us.pool.ntp.org       -0.007     2    84
ntp0.cornell.edu        -0.006     2    32
3.ubuntu.pool.ntp.org   -0.004     2    92
1.us.pool.ntp.org       -0.003     2    16
1.ubuntu.pool.ntp.org   -0.002     3    90
time.windows.com        +0.001     3    96
0.us.pool.ntp.org       +0.005     2    43

8 hosts responding
adjusted average: -0.004 (22:00:39 Thu 2019-10-10)

As of build 21, I get this from v25.
Code:
v:\> timecheck.btm
                        LOCAL
HOST                    OFFSET  STRATUM RTT

9 hosts responding
adjusted average: -0.006 (22:03:52 Thu 2019-10-10)

A DO loop is obviously still OK because the summary information is correct. So I figure what must be failing is this construction.
Code:
do host in @%0:%list | d:\gnu\sort -g -k 2
:: query the time server with @EXECARRAY
:: pick out the desired fields
:: echo a line for that host
:: do some statistical stuff
enddo

That construction may not be kosher (we have talked about this before). If it's not supported (and won't be changed), how can I do the same thing without resorting to CALLing another BTM?

Thanks.
 
Apr 13, 2010
298
7
60
The Hague
Is there anything in particular about that loop that you are attached too?

Very general: higher granularity of your code makes it much easier to spot the point of failure.

Is the time between each server call relevant to your results?

Is it server info, in that response file you are looping over? If so, is the reason you are reading it from a file that it is dynamically created? If not, use string constants.

DO HostInfo in /Q "server1;p1;p2;p3" "server2;p1;p2;p3" "server3;p1;p2;p3"
...
ENDDO

Will be faster too.

Again, having to guess at timing particulars here, I would dump received data un-interpreted in a simple structure while querying. Post-processing is a separate concern. Reporting yet another.
 
May 20, 2008
10,670
83
Syracuse, NY, USA
I'm attached to the fact that I don't have to loop over a long list of constants ... all the hostnames are kept in a file (NTFS stream). That file, the one I'm looping over is simple.
Code:
v:\> type timecheck.btm:nonnist.txt
ntp0.cornell.edu
time.windows.com
0.ubuntu.pool.ntp.org
1.ubuntu.pool.ntp.org
2.ubuntu.pool.ntp.org
3.ubuntu.pool.ntp.org
0.us.pool.ntp.org
1.us.pool.ntp.org
2.us.pool.ntp.org
3.us.pool.ntp.org

The loop and the collection and processing of the returned data work fine. What doesn't work is the piping of DO's output to SORT.
 
May 20, 2008
10,670
83
Syracuse, NY, USA
I thought I had a simple workaround. Instead of echoing the results (with DO's output piped to sort) I echo it >> tmpfile and when the DO is finished, sort tmpfile to stdout. See it work:
Code:
v:\> timecheck.btm
                        LOCAL
HOST                    OFFSET  STRATUM RTT
2.ubuntu.pool.ntp.org   +0.005     1    51
ntp0.cornell.edu        +0.007     2    27
0.ubuntu.pool.ntp.org   +0.008     2    39
0.us.pool.ntp.org       +0.008     2    32
1.ubuntu.pool.ntp.org   +0.008     2    89
2.us.pool.ntp.org       +0.009     2    42
3.us.pool.ntp.org       +0.011     2    17
1.us.pool.ntp.org       +0.012     3    33
3.ubuntu.pool.ntp.org   +0.013     2    45
time.windows.com        +0.015     3    94

10 hosts responding
adjusted average: +0.009 (10:13:54 Fri 2019-10-11)

But now, I can't use %@EXECSTR[CALL...] on that BTM (whereas I used to be able to do it).

Code:
v:\> type calltc.btm
echo %@execstr[call timecheck.btm | ffind /vkme"average"]

v:\> calltc.btm
d:\gnu\sort: fflush failed: standard output: Invalid argument
d:\gnu\sort: write error
ECHO is OFF
 
May 20, 2008
10,670
83
Syracuse, NY, USA
The construction "DO ... | ..." is still intact.
Code:
v:\simplified> type dopipe.btm
do i=5 to 1 by -1 | sort
        echo %i
enddo

v:\simplified> dopipe.btm
1
2
3
4
5
See the new thread where the problem is simplified.