The "packed decimal without sign nibble" format that I mentioned in my last
post is in fact a database format - it was of course not a relational
database, but a home grown hierarchical database that predated DB2 and
IMS -
and it was used in the 70s to save space,
because for values that are known to be always positive,
it is not necessary to store the sign,
and space was of concern in those days.
To work with those fields, the sign was added after input, and the
arithmetic was done using the normal decimal arithmetic instructions.
Although this is not the same situation as of the OP's question, I think
that
the same procedure could well be appropriate to the OP's problem.
BTW: the database exists until today, but today it is implemented on top
of DB2.
The database records are LONG VARCHARs of DB2, only the keys are translated
to DB2 fields and indexes. It was not possible to do a "real" conversion
to DB2 -
too expensive. Only from time to time some parts of the database are
migrated
to "real" DB2 - step by step. The application last year had its 40th
anniversary -
still supporting the business.
Kind regards
Bernd
Am 24.04.2013 21:56, schrieb John Gilmore:
The notion that input data are not in an internal floating-point
format, be it BFP, DFP, or HFP, is unarguable. This is also true of
binary integers. Indeed there is our at least should always be a
distinction between external. displayable|printable values and
internal, coimputationally convenient.
Some of the input data I work with are in classical engineering notation, e.g.,
+1.414213256237309504880e+000,
Some are external fixed-point, e.g.,
+1.414213256237309504880,
some are external integers, e.g.,
-5,
and some are pairs (a,b) of one of these that represent the complex
number a + bi.
They are all converted into the appropriate internal format, readily,
and stored as such in files or RDBs. Conversions occur only at input
and output, display or report preparation.
Thus
<begin extract>
To go from character string to a format that can then be converted to
DFP requires, at the least, a PACK instruction.
</end extract>
is almost aways an entirely correct but unproblematic truism. (There
is an ancient model of a computer system that is said to 1) read in
an integer augend, 2) add anoither integer added to it, and 3) output
the resulting sum; and for such 'systems' many conversions may be
intolerably burdensome; but such systems are not really of much
interest.)
I, and I am not alone in this, find the idea of doing arithmetic on
display values absurd. COBOL notionally permits this, but only by
sleight of hand. The to-and-fro conversions are hidden away in
library subroutines.
John Gilmore, Ashland, MA 01721 - USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
