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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html