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?
This is an understandable, even appropriate, first reaction. Who wants to
use a[n enormous] 16-page table? 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).
Note also that the current z/Architecture Principles of Operation specifies
that:
The translation table is treated as being on a doubleword boundary for
TRANSLATE ONE TO ONE and TRANSLATE ONE TO TWO. For TRANSLATE TWO TO ONE and
TRANSLATE TWO TO TWO, the translation table is treated as follows:
When the ETF2-enhancement facility is not installed, the translation
table is treated as being on a 4K-byte boundary.
When the ETF2-enhancement facility is installed, the translation table is
treated as being on a doubleword boundary.
Only doubleword table alignment is anymore usually required.
Not just Kirk, but many other experienced programmers are likely to react
badly to the notion of using a 64 kibibyte table. They need to rethink
these initial reactions: There are many situations in which they should do
just that.
John Gilmore
Ashland, MA 01721-1817
USA
_________________________________________________________________
View Athletes Collections with Live Search
http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01
----------------------------------------------------------------------
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
