"Rick Rothstein" wrote...
....
I never used Lotus 123, so I was not familiar with the particulars of its
NSUM function; . . .

If I do nothing else than convince people who've never used 123 to
exercise just a little bit or reticence about responding to 123-to-
Excel posts, I'll have done something positive.

. . . does the Lotus 123 NSUM function actually wrap the areas as your
code does? By that I mean, for this formula...

=NSUM(1,3,B5:C15)

the cells that will be added are B6, B9, B12, C7, C10, C13... notice the
Column B cells are offset, row-wise, from the Column A cells. Of course this
will happen whenever the loop through the rows does not finish on the
column's last processed row. Not having any personal experience with the
actual NSUM function, this looks, at first blush, to be somewhat useless to
me... my gut feeling tells me it would be more practical to have the same
row processed in each column

Simple enough to test. In 123R8 I enter the following values in C3..D7

1 600000
20 7000000
300 80000000
4000 900000000
50000 0.5

The 123 formula @NSUM(1,3,C3..D7) returns 80050020, or, in order,
C4+C7+D5. I enter the same values in C3:D7 in Excel, and using my nsum
udf, the formula =nsum(1,3,C3:D7) also returns 80050020. This follows
123's default iteration order through C3:D7, namely, C3, C4, C5, C6,
C7, D3, D4, D5, D6, D7, so offsetting 1 and including every 3rd item
means including C4, C7, D5.

Whether this is useful or not is up to the user, but if the goal is
presumably giving the OP a udf that doesn't FUBAR any nontrivial
formula porting from 123 to Excel, then you have to live with the 123
specs whether or not they make sense to you. If you don't know the 123
specs and/or can't figure out how to find them using a web search, why
respond with a udf that (LIKELY!) wouldn't be robust?