On 4/24/2013 10:19 AM, Joel C. Ewing wrote:
Like Steve my first reaction was also that the hardware only knew about signed
packed decimal and that unsigned packed was just a software convention; but I
looked at z10 Principles of Op, and it explicitly defines both signed and
unsigned packed decimal as zArchitecture data formats. In addition to the
ancient Move With Offset, which POp mentions as user of unsigned packed,
apparently some of the newer Decimal Floating Point instructions (Convert
To/From Unsigned Packed) also work with unsigned packed decimal values. Since
MVO never really cared about nibble content at all, it seems a stretch to say it
represents support for packed decimal, signed or unsigned; but the newer DFP
instructions, which actually force/require valid decimal nibbles, are clearly
true hardware support for unsigned packed decimal.
OK, fair enough. I went back to the POO and re-read.
Kind of a travesty, in my mind. I consider so-called
"unsigned packed decimal" to be just a convention; as
you say, it's support by MVO is really no more than
the support MVO has for any arbitrary bit string; and
as an operand for the instructions to convert between
decimal floating point and packed decimal, the result
of CUDTR and CUXTR instructions is found in a register,
not in storage.
So-called "unsigned packed-decimal" data is mis-leading
at best because it cannot be used in any packed decimal
arithmetic or compare operations. It's just a string of
hex digits each of which are between x'0' and x'9'.
Not related at all to the OP, at any rate.
Joel C Ewing
On 04/24/2013 10:34 AM, Steve Comstock wrote:
On 4/24/2013 9:19 AM, John Gilmore wrote:
My understanding of the difference between unsigned and signed packed
decimal values is that the rightmost sign nibble in a signed packed
value is occupied by a digit in an unsigned value.
Consider a four-byte value. The hardware interprets a signed value as
|d|d|d|d|d|d|d|s|, a precision of 7 decimal digits.
and an unsigned one as
|d|d|d|d|d|d|d|d|, a precision of 8 decimal digits.
No. The hardward does not recognize any such animal as an unsigned
packed decimal digit. All packed decimal data carries a sign in
the rightmost hex digit; x'A', x'C', x'E', and x'F' are considered
to be positive, x'B', x'D' are considered to be negative, x'0'=x'9'
are considered invalid and will abend you if you try to use such
data in any packed decimal operation.
They are thus easy to distinguish: the decimal digits are in the
sequence 0000, 0001, . . . 1001; and the signs are the [logically]
larger four-bit values.
Vide pp. 9-2ff of the PrOp.
I do not recommend mixing them.
The OP is not considering mixing them but is considering the
vagaries of converting between packed and character numeric strings.
John Gilmore, Ashland, MA 01721 - USA
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
