>> It happens that I needed to generate a diagnostic today for an SRU
>> server that couldn't handle a query simply because the query was
>> too darned long
>
> If I recall correctly, it was deprecated because it wasn't believed
> to be useful compared to the more explicit diagnostics 38 and 23.

(Which, for those who don't want to go and look them up, are "Too many
boolean operators in query" and "Too many characters in term". I
don't see these as "more explicit", as in that they describe subsets
of the condition described by 12; they are related but distinct.)

> The server must have an arbitrary low limit on the number of
> characters in a term which is somehow unrelated to the number of
> search clauses or the number of characters in a term.

Yes, precisely.

> Such a query is hard for me to imagine unless the server has a limit
> in the region of 100s of characters due to running on a machine with
> 640k of memory (the most you'll ever need) :)
>
> Could you describe this particular situation, and why 23 or 38
> aren't appropriate?

Well, this a bit airing-of-dirty-laundry, but ... Zebra supports CQL
by translating it into YAZ-style prefix query format, which it then
compiles into the Type-1 query that it actually executes. The
rendering into PQF is done into a buffer which is allocated at to some
specific size rather than realloc()d as we go along. If we reach the
end if that buffer, we need to diagnose this fact. As you can see, 38
and 23 are both misleading, since
a or b or c or d or e or f or g or h
and
supercalifragilisticexpialidocious
might both be OK, but
apatosaurus or brachiosaurus or camarasaurus or diplodocus
might not.

 _/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "The Harry Potter books are literature, period. They'll be
read long after Salman Rushdie has turned to dust" -- Richard
Sherbaniuk.