Tom Marchant wrote:
<begin snippet>
BLSUXTOD is an IPCS exit service routine that seems to pass back
mm/dd/yyyy hh:mm:ss.ffffff
Not something I'd want to do arithmetic with.
</end snippet>
He is right on both counts. This is the formatted character-string output that
BLSUXTOD produces, and it is wholly unsuitable for arithmetic.
I have now reviewed this entire thread looking for clues as to how I and others
could have gone so wrong: We thought Micheal Butz was trying to work with STCK
values, and he was not.
Exactly what he was/is doing is still not entirely clear, but it seems most
likely that he was using the 'ffffff' portions of pairs of these values for his
arithmetic. Now he was not of course actually doing arithmetic with them.
zArchitecture does not permit such arithmetic. Implicitly---as with COBOL
display values, on which it is possible to appear to be doing arithmetic---or
explicitly they must be converted at least into packed-decimal values before
arithmetic can be done on them.
The discrepancies that troubled him are an obvious outgrowth of his use of only
these 'ffffff' values, in a way that several of us explained to him, but his
reactions remain puzzling.
He does not appear really to have understood these explanations. Moreover,
while he is concerned about the [trivial] path lengths of the arithmetic
operations on STCK values proper that Edward Jaffe outlined for him, he is not
concerned about---does not even appear to be aware of---the hundreds of times
greater overheads of all these conversions. He appears to be thinking
magically: What he writes incurs overheads; what he uses does not.
What is most interesting about all of this is not Mr. Butz's problem or the
time we wasted on it. It is our failure to find out sooner what he was doing
(if we have indeed done so).
Without discouraging people from presenting problems---and certainly without
making rules or otherwise bureaucratizing the process---we need to be more
insistent that they set out their problems fully and coherently, and we need to
question them until they do.
This is a hard balance to strike, but not perhaps an impossible one.
John Gilmore Ashland, MA 01721-1817 USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
