Thanks Tom! For HGPR, don't you mean the reverse of what you said? PRESERVE would always be save because COBOL preserves and restores the high-halves of the registers, right? Safer, but not as efficient?
As for NUMPROC, thanks for the info. Seems to me the documentation could be made clearer, though I don't know exactly all. In the end I can't imagine doing what you suggest, even though "it's the only way to be sure". So we'll probably, unfortunately, just go with NOPFD. But thanks a lot for the info!! Question about one additional option. We use TRUNC(STD) right now. What would be have to be aware of if we wanted to switch to TRUNC(OPT) (where I assume OPT = "optimize")? Is OPT fully compliant with COBOL standard truncation rules? Thanks! Frank FirstBank ________________________________ From: Tom Ross <tmr...@stlvm20.vnet.ibm.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, September 25, 2014 11:32 AM Subject: COBOL 5 compile options >AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floati= >ng-point, so perhaps it doesn't even matter what option we choose. COBOLV 5 will use floating-point registers for fixed point math at higher ARCH levels. in some cases we convert DISPLAY numeric data item to DFP (Decimal Floating Poiint) rather than packed decimal to do the math. On the other hand, we think NOVOLATILE is mostly safe. >DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes di= >splays of negative signed fields easier to read. I agree, DISPLAY output is for humans >HGPR: NOPRESERVE, since we're almost entirely "COBOL calls COBOL", except = >for a few "COBOL calls assembler" routines. Is there anything I should loo= >k at in the latter case to make sure NOPRESERVE doesn't cause any issues? This one needs more research. For example, EXEC SQL calls DB2, which could thhen switch to AMODE 64 and change the regs. On the other hand, I did a service search and found a case where DB2 was fixed when it inadvertantly changed the upper halves of some regs. We know for sure that NOPRESERVE is safe, and PRESERVE should be safe, but we need more data! >Other than NUMPROC, discussed in my previous post, I think these are the on= >ly ones I'm concerned about. In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more about signed data to signed data. If you get nonpreferred signs as input data then you need to run with NUMPROC(NOPFD) to make sure you get correct results. I gave a presentation at SHARE about one way to check if you can use NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance. The relevant parts are here: NUMPROC(NOPFD) - NUMPROC(PFD) is faster Performance considerations using NUMPROC: - On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 21% faster to equivalent. Investigate your signed data in External Decimal and Packed-decimal - How can you do that? It is not easy, but if you really want to: If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD 1 Create a sniffer program from existing programs to access all of the data 2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs 3 If 100% NUMERIC, change to NUMPROC(PFD)! *> Compile sniffer with NUMPROC(PFD) EXEC SQL SELECT Ext-Dec Packed-Dec INTO :X, :Y END-EXEC If X NUMERIC and Y NUMERIC Then Display Use NUMPROC(PFD)! Move 2 To Return-Code Else Display Sorry, use NUMPROC(NOPFD)! Move 16 To Return-Code *> Or call CEE3ABD Stop Run End-If Cheers, TomR >> COBOL is the Language of the Future! << ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN