On 2 November 2012 04:05, Martin Truebner <[email protected]> wrote: > John, > >>> Dividing and taking the remainder to achieve a more-fewer mapping > is---by definition---division-method hashing; > > and I insist: the number of possible input values is 46656 and this is > the number of output values exact 46656 (not more-fewer but identical) > > - and > > (surprise surprise) 46656 is 36 ** 3
Regretably the code snippets posted at the start of this thread are just that, and there are at least three reasons (flow of control, mismatch of code and comments, and line numbering anomalies) to think that the code we see is not the code that runs successfully. For example, the GETMAIN appears to be done using a length that is 46656+46656, whereas the length of each map entry (whatever such may be) is unknown. If we infer from the code and comments on lines 9804 and 9904 that each map entry is just one byte long, and that the doubling of the GETMAIN value is an error (or for all I know of CICS, that its GETMAIN works in nybbles), then the range of input offsets is indeed 0 to 46655, and the code merely converts from notional base 256 to base 36, and then converts that to a handily printable scheme. I have trouble calling this hashing up to this point. But if the size of a map entry is greater than 1, the scheme wraps, and two (or more) addresses will produce identical outputs and therefor terminal IDs in an entirely predictable way. This could reasonably be called hashing, but the regularity of the input and absense of any sign of collision detection, makes it a bad configuration. Conceivably the "terminal prefix" in WSYSIDCR is used elsewhere in the code to manage more than 36**3 IDs. > If we all go back and look at the what the OP posted as code-snippet it > would be fun- If we argue about distribution and clusters (and > algorithms), I am out. Your analysis of my analysis could be useful, for those who are still listening... Tony H.
