>Do you actually have a billion numbers in your data? If not, my thought would >be to only generate as many mapped keys as you have unique live keys. That's >what the pseudo code meant to say. Don't generate a key until you need one. >You could even do this using VSAM as the data store. Or, even simplier since >you don't need the mapped key to stay uniquely mapped to the same live key, >generate them in an AMODE(31) table. PIC S9(9) could be stored in 5 bytes. A >full billion, 5 byte, packed numbers would require 5 billion bytes of storage >(5 Gb), or about 2^23 bytes. If you wanted to, you could run a program and >save this in a VSAM Linear dataset. You could then use this dataset as your >permanent map and access it as a DIV (Data In Virtual) file, using very >efficient memory mapping. Or create it as an ESDS and access it in RBA mode. >Or perhaps even an VSAM RRDS. Generating the file may take a while, especially >to guarantee the uniqueness of the random map. The biggest problem mig! h! t be finding a random number generator which can actually generate uniformly random values in the range [0..5,000,000,000]. Do it over a weekend. Or in a low priority batch job. The dataset should fit on 3 volumes of 3390-3 space.
John, I will certainly do as you suggest if I strike out on finding an algorithm that is purely arithmetic. If I do resort to this, I would be doing it off platform using VB.Net and SQL Server. So a billion row table may even be feasible, after all my workstation has a terabyte HD. Another idea could be to have two indexes: one for the first five digits, and the other for the last four. If you break it up like this, the combined result is still unique, deterministic, and impossible to reverse engineer unless you have access to the translation index. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
