>And so you can enjoy this, my question is, why is it that OPT(0)=20 >overrides INITCHECK, but if I ask for Optimization (e.g, OPT(1))=20 >it works?
>Frankly, I do not want anyone using INITCHECK (IC) outside of=20 >OPT(0) which means NOOPT (except that you can't say that with=20 >COBOL 6.2). >Yes, INITCHECK is ONLY done by the Compiler during Parse/SCAN=20 >operations and not during code gen (as I read the manual). >But it takes more CPU for this to work, so why do that AND the=20 >CPU burn of Optimization for a compile where one is attempting to=20 >determine if fields are being referenced before they have had=20 >something put in them? INITCHECK needs to have the path analysis using the flow graphs created by the optimizer. it would not be very helpful if we did not analyze different paths to a statement, we would only find uninitialized data items that were NEVER set. INITCHECK can find data items that are initialized on smoe paths but not on others, and can be quite helpful. It does require the flow graphs that are only produced by the optimizer, (and take memory and CPU to create) so we can only provide INITHECK capability when OPT(1) or OPT(2) in effect. 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
