On 4/24/2013 12:43 PM, John Gilmore wrote:
zMan accuses me of 'pissiness'. In fact I posted a neutral technical
exposition of the two packed-decimal formats. Mr Comstock responded
with, "No, <inaccurate text>".
Now he and others are free use words as they please. There is august
precedent for doing so. As Lewis Carroll wrote in TtLG,
"When I use a word," Humpty Dumpty said, in a rather scornful tone,
"it means just what I choose it to mean—neither more nor less."
Still, this forum is [mostly] about zArchitecture machines, and for
them there are two packed-decimal formats.
My own view of the packed-decimal data type was never enthusiastic and
is now very negative.
Awww.
Storage-to-storage arithmetic was always obscene, but there was a sort
of rationale for its use in some business applications: HFP and BFP
can yield rounding results that surprise the uninitiated. Mike
Cowlishaw's DFP has now dealt definitively with these problems, and
any rationale for doing even business arithmetic in anything but DFP
has now also been removed.
Well, unless you need to work with numeric entities
that already exist in non-DFP format, or data that
is accessed from programs written in languages that
don't [yet] support the DFP format. Of course, those
objections are trivial to you, so we'll pass them by.
The question how many people use DFP in assembly language is one that
I do not really know the answer to. I should guess not many, but that
is only a guess, and I myself use it routinely. (It is rather easier
to use in assembly language than HFP, and both it and BFP make
available conversion instructions the absence of which was the chief
obstacle to the use of HFP in assembly language.)
Ah, see, now we are talking about something we can focus on
objectively, and I'm sure I can learn from you.
So, you use DFP routinely. Let me ask, in your code where
you use DFP, what format is your data in initially? Does
it come to your program in zoned decimal, [classic] packed
decimal, binary, HFP, BFP? Or do you only deal with data
that is either stored in DFP or data your program defines
internally?
The way I read the Pops (if you prefer to 'POO'), to get
data into DFP, if it is not already in that format, you
have to convert from one of these formats:
a signed binary integer (fullword or doubleword in a GPR)
an unsigned binary integer (fullword or doubleword in a GPR)
an eight byte [classic] packed decimal string (in a GPR)
a 16 byte [classic] packed decimal string (in a pair of GPRs)
an eight byte 'unsigned packed decimal' value (in a a GPR)
a 16 byte 'unsigned packed decimal' value (in a pair of GPRs)
of course, none of these source formats is available from standard
data entry sources (i.e.: keyboards, scanners); ultimately, user
data gets into the system by keying or scanning which usually
results in character strings in some encoding (most typically
EBCDIC). To go from character string to a format that can then
be converted to DFP requires, at the least, a PACK instruction.
The result there is classic packed decimal, which you could then
load into a GPR and thence convert to DFP. Is that the approach
you take, then, in your code?
Just curious.
If there is any significant feeling that I should withdraw from this
list too, I am quite willing to do so. It can survive handily without
me and I without it.
Now now, you're not going to let others dictate your actions
are you? Are you a man or a mouse, John? (of course, that may
depend on your definitions, as you reference above.)
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
--
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
