In the form you get from clicking Replace via Z39.50 in the basic editor or on a bib detail page, or by clicking Z39.50/SRU Search in the results of a search of the catalog, there's an input with the label "Dewey:". Awesome name, it's the name of my cat, but it's not what that input does. You can see a Dewey call number and an LC call number search by loading the Advanced editor, then the Advanced search dialog, and trying both "746.432043" and "TT174.3" in each. The first will work in the Dewey number input but not the LC call number input, the second the reverse. In cataloguing/z3950_search.tt, both will work in the Dewey input, because that's not the search it does.
Well, depends on your search target and how they've implemented what "Dewey" does, I guess. For OCLC, it's an any-call-number search, for LC it seems to be, rather comically, a not-dewey-call-number search. If your search is an LC call number, "Dewey" will return records where 050 matches it. If your search is a Dewey number, it will maybe return things with 641-5 in an LC call number for a search of 641.5, but not things where 082$a is exactly that.
Heh, and Library of Congress SRU treats it pretty much like OCLC, either an LC call number or a Dewey number in "Dewey" will work, though the shorter the Dewey number the more surprise matches you'll get.
Unassigning myself, as I don't understand all the nuances here - including what the labels mean and purpose of the fields. I think it may be a bit more complicated than just changing one form, as there are others that are similar and use the same labels: - Acquisitions: adding to a basket from an external source - SRU Search fields mapping: Administration > Additional parameters > Z39.50/SRU servers > edit LIBRARY OF CONGRESS SRU > Modify (for SRU Search fields mapping).
The advantage of SRU is that you can see what your searches are mapped to and change it. The disadvantage is that you can see.... The LC's SRU explain record at http://lx2.loc.gov:210/LCDB tells you what you can search by, not including any sort of call number search, so it's not mapped to anything, it's just a keyword search, and you get the same results whether you use either call number field in the search form or you use the keyword field. The LC's Z39.50 explain record at https://www.loc.gov/z3950/xml/lcdbz3950.xml tells you that you can search for Dewey call number and LC call number and in each case as a keyword or with right truncation or exact match or left-anchored with right truncation (which I think is a fancy way of saying starts with), and somewhere deep in the bowels of Koha we either choose one of those for the "LC call number" and "Dewey" fields for a Z39.50 search, or maybe we don't. Or maybe we choose one of the LC call number fields for both: today's 'test what you are actually getting' call number search for me is Perl, and if I do that as an LC call number search at LC Z39.50 I get no results, but if I do that as a "Dewey" search at LC Z39.50 I get two records, both of which have an 050 LC call number field which includes the string Perl. Do we actually do left-anchored with right truncation LC call number searches for the "LC call number" field, and keyword LC call number searches for the "Dewey" field? It would fit with the results I get. Or, do we specify the Dewey call number index and it is misconfigured in the LC server as LC call number? The results I get from the separately-implemented Z39.50 search in the advanced editor make me think this other one is doing something wrong, since in the advanced editor both the LC call number and the Dewey number searches give reasonable looking results from both OCLC and LC, finding whatever you search for in 050+09x local call number fields or 082+09x and not finding it in random spots or in the spot for the other flavor of call number. Personally, I'm looking for an exit strategy to get away from touching the Replace via Z39.50 search as quickly as I can while walking away backward so it doesn't sneak up and bite me on the back.
For Z39.50, what a search field does is determined in https://git.koha-community.org/Koha-community/Koha/src/commit/4801037abe0f8d294eb03503c2b5a275ed06f62a/C4/Breeding.pm#L243 So indeed, the thing with the label "LC call number" does an LC call number search left anchored with right truncation (plus attr 2=3 which is relationship: equal, attr 4=1 which is structure: phrase, attr 6=1 which is completeness: incomplete subfield, things other than the query term may appear in the same subfield), and the thing with the label "Dewey" does an LC call number keyword search, not a Dewey classification search.
Also fun, for SRU the thing with the label "Dewey" could be absolutely anything. Since in what we ship it's a fifth keyword search (Keyword (any), LC call number, Control number, Dewey, and the Publication year that for some reason you can't remap are all just keyword (any) searches) there's no reason why someone cunning wouldn't have mapped it to bath.lccn so they have a standard number search for the best way to find things published prior to the widespread use of ISBN. Be nice if SRU remapping also allowed label remapping.
Okay, I see the path out of here. Even though a feature that's been broken for 14 years without anyone filing a bug about it seems like a sign to just remove it, we should probably leave it in and fix it, so the hypothetical sales manager doesn't have to face the question from a public library about why we only have an LC call number search and no Dewey search in the Z39.50 form, with no idea what the answer is and an actual answer that wouldn't be understood by anyone but a cataloger. C'est la vie, it's well below the fold where you have to scroll down in the popup to ever see it, having it won't hurt anyone. So, search the catalog -> Z39.50 should map callnum to keyword, because no Z39.50 attribute exists to say "search this as an LC call number, a Dewey classification number, a NLM call number, a NAL call number, and a UDC classification number." It's a shame that bug 37167 exists and one term can clobber another when they are mapped to the same field, but not blocking because that already exists for title, author, and subject. And the Dewey search should search Dewey, not LC, for the first time in its life.
(In reply to Phil Ringnalda from comment #7) > It's a shame that bug 37167 exists and one term can > clobber another when they are mapped to the same field, but not blocking > because that already exists for title, author, and subject. It's a shame my clipboard failed me, that should have said bug 37224
(In reply to Phil Ringnalda from comment #1) > Well, depends on your search target and how they've implemented what "Dewey" > does, I guess. For OCLC, it's an any-call-number search Which puzzled me once I realized that it's actually doing an LC call number search, which OCLC supports. Once I looked at where my search term appeared, though, it's just because OCLC's database is big enough that you can get enough false-positive results that they look like results. People will stick a Dewey number in the LC call number fields 050 or 090 often enough that if you are only looking at where they also stuck it in 082 where it belongs, it looks like you got actual results.
Sigh. Let Dewey be Dewey depends on mapping callnum to Keyword, which depends on teaching z3950_search_args that someone might want to use Keyword, because currently catalogue/search.pl, the only thing that might, instead maps an explict search of "Keyword" to Title rather than Keyword (any).