>MOVE "BUBBA" to WS-DESC. How about this example instead:
MOVE "Version 6.3.2. Copyright 2014 BUBBA Coders Inc. Licensed to GUMP Inc." to WS-DESC. With the stipulation that this second example may not be brilliant, should the optimizer remove that "unreachable" "watermarking" literal? Keep in mind also that optimizers have their own performance characteristics to respect. If you're spending $10 to save $0.01, that's (also) a waste of resources. Much like compression algorithms, optimizers ought not do everything possible. They should only do what's "prudent," "wise," and "reasonable" to do -- no more. There's also some non-zero risk that if an optimizer takes low comparative reward action it could do so improperly -- that there's an optimizer bug, in other words. Bugs can be expensive, too. A new optimizer is about the present and future. Today's COBOL compiler is no longer tasked with optimizing for System/370 machines. It's a fair generalization that reducing compiled code size by X bytes is much, much less important in 2014 than it was in 1982 where X is constant, ceteris paribus. It's also a fair assumption that it will get even less important over time. And you've also got to consider that everything gets rounded up to 4 KB, 1 MB, or 2 GB page sizes anyway (and minimum storage block sizes, relatedly) with the smaller page sizes progressively falling by the wayside over time. Bytes as bytes "don't matter" to a first, second, and probably third order approximation. (Maybe the optimizer only takes action if the next page increment is approached, and then only enough to remain within the lowest reasonably achievable page count but no more?) To net it out, for at least a few reasons I don't think this example demonstrates that an optimizer isn't properly doing its job. In fact, if the optimizer were *always* taking preemptive action here you might have discovered a poor optimizer! The run-time world is nuanced, complicated, and certainly not static. A sensible optimizer knows when *not* to take action just as much as when, and this one might be such an example. "Minimize the compiled code's memory footprint, in bytes" isn't actually a sensible priority objective for a (modern) optimizer with the possible exception of an optimizer targeting a comparatively memory constrained environment, e.g. an embedded "smart card" processor. Maybe I'm too often the lonely voice constantly reminding IBM-MAINers that we no longer live in a "kilobytes world," but it really is true. Yes, on mainframes, too. These are good *instincts* to have -- performance and scalability are achieved/achievable through efficiency, yes -- but one shouldn't get too crazy about this stuff lest one lose the plot entirely. The boundary between "crazy" and "not crazy" keeps shifting practically every week -- yes, on mainframes, too -- and so should we. Yes, I think it's "crazy" that a typical downloaded smartphone application occupies more flash storage than the capacity of the entire hard disk I purchased in 1984 for US$699 -- a bargain! -- had. How wasteful! How profligate! But it's 30 years later, and no, it really isn't, today. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
