>[One issue I haven't seen addressed is Cobol picture data, which has a>numeric value in a numeric context and a string value in a string context.>Do you keep two copies, one copy and convert on demand, or what? -John]

No, although it is an interesting idea. But keeping two forms around
would double the amount of work required on operations on PIC() data. The
COBOL PIC() datatype and the PL/I PICTURE() datatype are very similar,
and, for our common back-end, the picture data is compiled into a separate
storage class (basically a structure), and at runtime, a finite-state
machine does the appropriate stuff. Some hardware/OS's have support for
PICTURE data, which a compiler could utilize, but many of the recent
architectures don't. Some of the semantics of PICTURE data for PL/I
conflict for COBOL PICTURE data, so the state machine gets a bit tricky to
deal with. Curiously enough, typical usage of the PICTURE() datatype in
PL/I seems to simply put digits into the variable, (effectively treating
it as BCD) but since the datatype permits blanks, decimal points, dollar
signs, and other miscellany, the performance isn't all that good.

---------------------------
On COBOL datatype transformation as an optimization: was "Is COBOL Boring?"