A Final Thought About Memory And Competitiveness - IBM 170 Servers Manual

One thing easily misunderstood is variable length characters. At first, one would think every character
field should be variable length, especially if one codes in Java, where variable length data is the norm.
However, when one considers the internals of data base, a field ought to be ten to twenty bytes long
before variable length is even considered. The reason is, there is a cost of about ten bytes per record for
the first variable length field. Obviously, this should not be introduced to "save" a few bytes of data.
Likewise, the "ALLOCATE" value should be understood (in OS/400 SQL, "ALLOCATE" represents the
minimum amount of a variable record always present). Getting this right can improve performance.
Getting it wrong simply wastes space. If in doubt, do not specify it at all.

A Final Thought About Memory and Competitiveness

The currency storage reduction example remains a good one -- just at the wrong level of granularity.
Avoiding a SQL join that produces N squared records would be an example where the 2 times N
alternative, if available, saves great amounts of storage.
But, more critically, deploying the least amount of Order(N) storage in actual implementation is a
competitive advantage for your enterprise, large or small. Reducing the size of each N in main storage (or
even on disk) eventually means more "things" in the same unit of storage. That is more competitive
whether the cost of main storage falls by half tomorrow or not. More "things" per byte is always an
advantage. It will always be cheaper. Your competitor, after all, will have access to the same costs. The
question becomes: Who uses it better?
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 20 - General Tips and Techniques 320