Performance-critical Statements (with extra generated Code by Compiler) should be flagged

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - COBOL Compilers

For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - COBOL Compilers

This RFE has been delivered in Enterprise COBOL, V5.2

This item has been put into plan for a future compiler release.

Hello Tom,

of course it is ok to flag all all instances of poor code not only in loops.
Your bad Perform-Varying-Example would also be flagged (multiple, i think).

To decide if the statement is called only once or multiple (by loop or any other construct) a normal programmer should be able to know.

miss-aligned Variables could also be a candidate.
So when extra code is used to bring them to 4-byte-margins and an simple "sync" in sourcecode would be sufficent.

This is a valid feature request. This request may not be delivered within the release currently under development, but the theme is aligned with the current multi-year strategy.

With that comments there are coming a few ideas . . . ;-))

Hi, (cobol-)folks all over in Germany and the world: Think about that also and comment your ideas!!!


What about numerical operations where conversions have to be done?
Example 1: Compute bin = packed * display + packed + bin - display ;-))
Example 2: perform varying display from 1 by 1 until bin (or the other way round)

Or: perform varying display (why don't use bin-field?)


See also RFE 34824.
and: please flag binary fields which aren't "correctly" defined as halfword / fullword / double. bin-field pic s9(1) binary isn't well (shall I open a RFE for that?)


How clever is the compiler for interpreting string, unstring, inspect? You can handle "easy" using of that commands inline (available in V5.1 I hope). Where this is not possible it could be flagged with an information when you can it handle inline. Perhaps the programmer can change the code a little bit. ;-)


I'm thinking about how it's possible - with low expense - to eliminate the option TRUNC(BIN) from our applications. Any ideas?

Hello,
INITIALIZE statement seems also to be worth looking at the output ASM instructions.
When intializing a large table with field mix between PIC X, PIC 9, X, 9and so on, sometimes refined with some redefines-Entries,
the runtime is quite long.
Maybe only the first line should be initialized and then moved (with overlapping move?) to the Rest of the whole table.

Also i think about COMPUTE-Statement and fields with different length or sign-Attributes (or binary vs. packed), which results in number reformatting before (and maybe after) doing the arithmetic.

I am sure there are existing more situations than mentioned by me. Maybe the community can put in more ideas, too.

Guenter

Hi Gunter,

Thank you for the request.

For clarification, are there any other particular situations (other than the ones you listed) you have in mind that would also need to be flagged?

Also, this type of flagging capability would have to be controlled via an extra option.