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
