Hello Phil,
I would like to give you some personal opinions on this ... see below
Am 18.02.2014 20:08, schrieb Phil Smith:
A while ago, there was a somewhat contentious thread about packed decimal: whether it had to
include the sign nybble or could just be all "significant" nybbles, and like that. I
don't intend to revisit what the formal definition of "packed decimal" is or should be,
but rather would like to understand real-world usage:
1) Do people use the "all significant" variant (e.g., a value of decimal
1234 stored in a halfword, x'1234', as opposed to 3 bytes, x'01234C')?
yes we have it at our site, in an old mainframe based application system
dating from the 70s, operative until today
2) What languages do they use the "all significant" format from, if so?
in the beginning only ASSEMBLER, but then we started with PL/1,
and so we had to add functions to PL/1, so that PL/1 can handle this
data format, too
3) How often do you use the "unsigned" nybble format (x'01234F' for "unsigned
1234")?
it occurs in short time periods after decimal zoned data is packed;
then by the use of the PACK instruction, you have F sign nibbles.
But after doing some arithmetic to the packed fields, the sign is
changed to C or D.
4) Which databases (DB2, yes; ADABAS, IMS, IDMS?) support packed decimal, and is it the
"all significant" format, or just the "sign nybble" format?
DB2 supports DECIMAL data, and uses packed decimal without sign nibble
for the internal representation of DATE, TIME and TIMESTAMP (DATE is 4
Bytes, TIME 3, and TIMESTAMP 10 bytes)
One of the meta-questions I'm trying to grok is why you would use packed
decimal for things like SSNs. Sure, it's more compact than character; I get
that (and we used to care about that, and maybe still do). But in either packed
format, an SSN takes 5 bytes, but would fit in a fullword as binary. And you're
not likely to be doing assembler EDIT/EDMK/ZAP/things like that on SSNs, so
there's no benefit there. Is it that x'123456789C' is easier to read in memory
or a dump when looking for SSN 123456789? Geographic prefix analysis (though I
kind of thought only the SSA cared about that)? Something else?
IMO packed decimal without sign nibble is very rarely used;
if it is used by applications like in our case, they must be very old
and special.
It is used (see above) by DB2, but only internal use.
Packed decimal with sign is widely used by COBOL and PL/1,
but only in commercial applications. All technical applications
and all system related applications in my experience always use
only binary data.
I guess the reason for using packed decimal is, that converting
to zoned decimal (external representation) is easier, that you
can read the values better in hexadecimal dumps, and that decimal
arithmetic supports scaled values (123.45) without rounding problems,
different from floating point values.
Furthermore I believe that much of the stability of mainframe applications
(in COBOL etc.) comes from the fact that the bit representation of
packed decimal values have much redundancy. A random bit pattern
of a packed decimal field of length - say - 6 bytes has a very low
probability to look like a valid packed decimal value. So you have a
good chance that the use of uninitialized variables will be detected
- you get a 0C7 abend when doing computations with that variable.
The same is NOT true for binary variables.
The same applies in spades to credit card numbers, which you're even less likely to be
doing math on, though I suppose there's a bit more prefix analysis or IINs and the like,
so maybe x'04000123456789123' for CCN 4000123456789123 might be a bit easier to process.
Does COBOL make packed easier to work with? Yes, COBOL isn't my strongest language -
"You say that like it's a negative thing", as Woody Allen would put it :)
Thanks in advance for any wisdom!
--
...phsiii
Phil Smith III
----------------------------------------------------------------------
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
