Re: how to increase field size without increasing the field size

On 4/28/2014 12:03 PM, James H. H. Lampert wrote:

On 4/28/14 8:58 AM, Alan Campin wrote:

The funny thing about this to me is how people are always saying there
are
no costs to using file I/O and bringing the entire database into the
program. In other words, no database independence.

Just watching this one thread and you have the real costs. Billions spent
dealing with problems like this where we should just be able to increase
the field size and recompile the few programs that use the PO fields
which
is what anyone else using SQL on other systems is doing.

But recompiling things that aren't "core code" of a published product is
usually a trivial exercise.

I used to work for a software vendor, so I appreciate the ability to
recompile thousands of programs during the day. Now that I'm back to
being an in-house programmer, there is no way I can shut the business
down in order to recompile the programs comprising the core system.
That kind of work can only happen after hours or on holidays, and the
internet is increasingly making 'after hours' into an anachronism.

We have one LPAR on one physical machine, so the only alternative is to
make a full copy of the production libraries, set the appropriate
library list and compile in the 'mirror universe'. When all the
compiles are finished, I then do a save / restore to plop it all into
production - after hours, of course. Not a panacaea, as the machine has
to sort out cross library logicals (not my doing) and the like.

--buck