>Thanks Tom! >For HGPR, don't you mean the reverse of what you said? PRESERVE would alwa= >ys be save because COBOL preserves and restores the high-halves of the regi= >sters, right? Safer, but not as efficient?
Ooops, at least I was 100% wrong :-) Yes, PRESERVE is safer, although NOPRESERVE might be safe for most as well. >As for NUMPROC, thanks for the info. Seems to me the documentation could b= >e made clearer, though I don't know exactly all. In the end I can't imagin= >e doing what you suggest, even though "it's the only way to be sure". So w= >e'll probably, unfortunately, just go with NOPFD. But thanks a lot for the= > info!! Yes, I was aware that my idea was kind of crazy, and eve asked at SHARE if anyone could ever do such a thing. On the other hand, if you did not find out if your data has preferred signed and chose PFD, you could get silent death ;-) >Question about one additional option. We use TRUNC(STD) right now. What w= >ould be have to be aware of if we wanted to switch to TRUNC(OPT) (where I a= >ssume OPT =3D "optimize")? Is OPT fully compliant with COBOL standard trun= >cation rules? TRUNC(OPT) does not result in any code generated to truncate. it is NOT COBOL Standard conforming and neither is TRUNC(BIN). You could get more accurate results with TRUNC(OPT) (along with much better performance) but I know that for many customers 'more accurate' = 'different' = BAD :-) Cheers, TomR >> COBOL is the Language of the Future! << ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
