OK, the old high school algebra came in handy today.
I’m working with what in IBM z/Architecture land we call packed decimal (see the section labelled “Packed BCD”) fields. These are fields where 2 digits are stored in each byte, except for the last, where the sign is stored in the low-order nybble. (Yes, nybble.)
I was wondering how many comparisons I have to generate to create all cases with implied decimal points. So I started small by using 15 digits, which is the largest that fits in a doubleword (8 bytes). I used the formula for determining the sums of the first n positive integers – in this case, 16 (15.0 to 15.15 is 16) then subtracting one because the smallest has 2 possibilities (1.0, 1.1):
Σ k = n2 + n
which gives us (256 + 16) / 2 or 272 / 2 = 136, then subtract 1 for the non-existent case or 135.
From there we go to the number of combinations taken 2 at a time:
Ck = n!
k! (n - k)!
or 135! / 2! * 133!, and by simplification we get (135 * 134) / 2 or 18090 / 2 or 9045. Ouch. That’s a lot of data to analyze and look for patterns in generated fields.
But what’s that, I hear the zero of you who are also IBM mainframe programmers cry. The maximum length of a packed field is 16 bytes, so your test case really should be 31 digits. Yes, thank you very much, now go away. Because we now get…
(1024 + 32) / 2 or 1056 / 2 or 528, then again subtract 1 for 527. And now the combinations are 527! / 2! * 525!, or (527 * 526) / 2, or 277202 / 2 or 138601.
Ugh. Not only will it be a lot of work to generate the DEFINE TABLE, but generating the SQL calls…I’ll have to write a program generator to do it right. And I don’t think I want to take the time right now to code such a beast. Although it would be fun. But there’s other work stuff I should be doing