Date   : Mon, 03 Aug 2009 17:52:12 +0100
From   : jgh@... (Jonathan Graham Harston)
Subject: Counting Directory Entries in L3 File Server

Rob wrote:
> The page I linked to seems to indicate that you can call it for any
> arbitary number of filenames at a time, and that it also returns the
> number not yet read .. Now that reads to me that you can add one
 
Yes, the number not read from the number you asked for. So, if you
ask for 4 entries, and get 1 returned, the 'number not read' will
be returned as 3. 4 asked for minus 3 not read equals 1 returned.
 
"Ian Wolstenholme" wrote:
> I've had a go, but you can only transfer about 20 filenames at a time or
> you get the No reply error.  If you try to transfer more than 115 files
> then you get F.S. Error 4E.
> 
> Each call doesn't take too long though, so it's acceptable to set up a loop
> to increment the "first file asked for" in the entry control block by 20
each
 
**NO** **NO** **NO** **NO** **NO** **NO** **NO** It is ***NOT***
acceptable to increment the index.
 
The returned index is ****NOT!!!!!****** an incrementing number, it
is an opaque value whose only defined values are zero and "value to
pass to next call".
 
You must *****NEVER!!!!**** take the returned value and impose any
interpretation on it such as doing arithmetic to is. 
 
How does: "Note that the directory index is an opaque value with
only the value zero defined. You cannot and ''must'' not assume
that it follows any particular sequence, for instance incrementing
by one after each call. The ''only'' thing you can do with a
nonzero value is pass it to another OSGBPB call." get translated to
"you can impose an interpretetaion of your own making on the
directory index" ?
 
Use the supplied code at the Wiki. What's the point of writing and
distributing working code if people completely ignore it and write
their own broken code?
 
Twenty eight years and people are STILL doing index=index+1 when
all the documentation says so utterly clearly that the ONLY thing
you do with the returned value is pass it back to another call.
 
> However, I can use the call starting at a high number of entries (say the
 
To find the index for a high number of entries, you have to step
through that high number of entries to discover what the index will
be for that high number of entries. You can't just make index=99
and assume that a result of 3 entries not read means 102 entries.
You have absolutely no ability to tell if the index have gone 0, 5,
10, 22, 99, 101, 105, 104, 155, 73, 24, 30, 49, 6, 9, 91, 92, 98.
The index is a completely opaque value with sole values of zero and
value_to_pass_to_next_call.
 
-- 
J.G.Harston - jgh@...                - mdfs.net/User/JGH
BBC BASIC for Windows and Internationalisation
  See http://mdfs.net/Software/BBCBasic/Windows/ProgTips