RE: SQL vs V5R1 and service woes

> >How often do you change your database?
>
> In a real environment? Sometimes more often than you would like
> to think. In
> a leasing firm I once worked at, the lease master file grew from 30 or 40
> fields to over 300 fields in the course of two years time.
> Business changes
> and new offerings drove this. We were using native I/O, so recompiles over
> the weekends were the standard fare for programmers. And, yes, I know that
> some of those fields did not really belong in that file, but that required
> more careful examination and analysis and design time than the users were
> willing to put up with at that time. It was not a small company.

This is an extreme case, and one that argues strongly for an encapsulated
server.  With a message-based server, your applications would have been
entirely isolated.  Not only that, when you decided to properly normalize
your database, you could have done it, again without changing the
applications.


> > How hard is it to then recompile the programs that use the
> >changed file?  To determine which programs use a given file, you can do a
> >DSPPGMREF to an outfile and use SQL to determine the programs to
> recompile
> >(this, by the way, is a really GOOD use of SQL, in my book!).
>
> See my previous statement. Are you kidding? 81,000 objects on the system,
> 5,000+ using this one file. 8 Million lines of code on-line, 1
> million lines
> of code active. How hard was it to recompile when only three new programs
> were going to use the field? (retorical)

This is another example of where encapsulated servers shine.  Only one
program actually accesses the data.  When the file changes, the server
program is modified to add a new message with the new fields.  Three
programs are modified to use the new message.  4997 programs remain
untouched.