Hi! Richard,

On 07 Jun 09 18:57, you wrote to all:

 RW> Any ideas welcome on how to streamline this.  OF course,
 RW> we're backing up our input data before we do this until
 RW> we're sure we've found all the bugs.

It ain't broken, is it Richard?  I've pinched a copy for my archive.  One
day, when I take the time to understand how fgrep386 and sed actually do
their stuff, I might understand it more fully.

My only comments are these: you might consider replacing the use of
"rem" statements with double colons, because Command.Com is still
looking at those lines and trying to make some sense out of them; and, you
could think about dropping the double errorlevel tests "if errorlevel
0 if not errorlevel 1 goto postit" completely, since at that point
anything there will be in a fall-through condition - just leave "goto
postit" there instead.  (Remember that with "if errorlevel
X" checking, Command.Com is comparing the "X" value -and-
greater.  Since you've already checked for X+1 previously then another
check is superfluous.)

Besides that, the only other thing that might shave off another nanosecond
would be to do the 'number of lines in the file' test on a single line,
essentially looking for a value that cannot be in the file.  That is,
instead of:

[ ... ]
echo * >> lognum.sem
type lognum.sem | find "*" /i /c >> lognum.txt
nset lognum=$1  * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

SEEN-BY: 633/260 267 640/384 954 1674 712/0 313 848 800/445

@PATH: 640/384 954 712/848 633/267