On Thu, 30 Nov 2006 02:30:47 +0000, john gilmore <[EMAIL PROTECTED]> wrote:
>Kirk Talman writes: > >>Why would anyone ever want to use a 64 K(i?)B translate table that has to >>be on a page boundary (in some cases) unless one is compressing data or >>converting Kanji and its first cousins to SBCS? What could it ever gain >>one? What am I missing? > >.... It does, however, turn out to be useful to >do so in many situations; but one example must suffice here. > >For historical reasons the American insurance industry is regulated chiefly >by the individual states rather than the federal government. An apparently >standard, vanilla automobile or life insurance policy has detailed >provisions that differ significantly from state to state. (Some states even >specify, differently, how the penny-breakage problem is to be dealt with, >how in detail calculated dollar amounts are to be rounded off to the >'nearest' cent.) > >In the upshot a single applications program used in this industry---most of >them are written in COBOL---often contains not just one but several-[--The >maximum I have ever myself found is 21---sets of nested if-then-else-if >figures of the form > >if state-code = 'AK' then . . . >else if state-code = 'AL' then . . . >else if state-code = 'AR' then . . . >else if state-code = 'AZ' then . . . >. . . >else if state-code = 'WV' then . . . >else if state-code = 'WY' then . . . >else . . . <error sink>. > >(Newer versions of COBOL of course support an analogue of the PL/I select or >C switch statement of the form > >evaluate state-code > when ‘AK’ . . . > when ‘AL’ . . . > when ‘AR’ . . . > when ‘AZ’ . . . > when . . . > when ‘WV’ . . . > when ‘WY’ . . . > when other . . . >end-evaluate > >which is certainly neater, but it is also something of a shell game. The >code produced for EVALUATEs by even the most recent releases of the z/OS >Enterprise COBOL compilers is no better than that that they produce for >nested ifs. One must write C or PL/I (which share optimizing machinery) to >get translate-based code (which is of course limited to a single byte for >the C switch statement)). > >Maintaining/replacing ad hoc code of this sort is a nightmarish job. >Replacing all of it with a single reentrant assembly-language subroutine >(and, usually, several different 64-kibibyte tables because different >'lines' may do business in different states) makes this job tractable; and >it speeds up the execution of these applications enormously, often by a >factor of more than 10k (sic). > I seriously doubt that TRTO is faster than 50 compares on a modern superscalar processor. I hope you mean faster by a factor of 10x, not by a factor of 10k. The latter is absurd, the former unlikely. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
