We have this "technique" as well. Interestingly, at least the last time I checked, it still works (causes the S0C7) if the packed decimal field is signed (PIC S9), but not if its unsigned (PIC 9).
What is the fix? When was it released? -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Pieter Wiid Sent: Wednesday, May 10, 2017 1:59 PM To: [email protected] Subject: Re: Performance of Decimal Floating Point Instruction Interesting side effect: A previous employer's programmers used to force a dump by adding 1 to a character field (redefined as packed). Comes Cobol 5, and no more S0C7 abends, and MANY transactions that did half their updates, and did NOT get rolled back. They nagged IBM into providing a fix (maybe it should be called a patch in this case) to get back the old operation. Apparently there were in excess of 10K programs using this "technique". -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Peter Hunkeler Sent: 10 May 2017 20:57 To: [email protected] Subject: AW: Re: Performance of Decimal Floating Point Instruction >Only the back-end optimization routine can tell you that for sure, and >it isn't talking. Remember though, that back end is reportedly shared with the Java JIT back end, and is supposed to be "very knowledgeable" about the fastest way to run code on a given architecture level. I'm not doubting the knowledge, I'm merely surprised to see their heavy use. Your point regarding register versus storage operations and cache protection makes much sense. >Trust but verify. Run 5-10 production-volume batch tests of pre-COBOL >V5 and COBOL V5 versions of your program, measuring both CPU and elapsed time, and then average the results. If there are real savings there, why do we care how it is done? (Except when we have to debug that abend at oh-dark-thirty, of course.) It's not oh-dark-thirty, but I'm wandering in the dark :-) We've got a program that gets into a loop we cannot explain yet. In an MA-Tune measurement, 99.9% of the samples show the program being active in always the same CZXT instruction. Did not make any sense. Next time the job was looping, we took an SVCDUMP and surprise, surperise, the program seems to be in a recovery loop. That's how I got aware of the heavy floating point usage and got curious. Not that I expect this to help me solve the problem. As said, It is pure curiosity. -- Peter Hunkeler --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
