>>Maybe IBM can publish the info or an II apar to document the >>application coding techniques causing the problem. >> >If move-with-truncation is a conventional COBOL operation, >the resolution should not be, "Don't do that!"
I agree. >I detest quiet truncation. It's hardly better if it takes an inordinately long time. I agree. >Another possible resolution, with its own performance consequence, is for the compiler-generated code to test (every time) whether overflow is about to occur and handle it as a special case. It might be better just to abandon the use of DFP. Well, that was what Cobol up to V4 did: Not making use of modern, fast, cache protecting instructions. Cobol V5 change this, to the benefit in general, I would assume. It is only that truncation may cause pain. BTW, it is not only with DFP instructions, it is also with other decimal instructions such as SRP. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
