Re: OO in Batch (Was: Program ID)

In article <217e491a.0406251250.67ada577@posting.google.com>,
riplin@Azonic.co.nz (Richard) wrote:

> There are other ways of doing this too.  For example database 'views'
> or not using '*' in the selects but specifying every field that is
> needed.  Of course if the change is something that the program needs
> to deal with then it will be recompiled because it has changed.


I'm a product of my mainframe environment.  When I think of changing a
table, or converting a table to a view it fills me with horror.  Not
only do I need to need to recompile everything (because separate binds
are dangerous, so sayth the DBAs), but it also involved getting buy-in
from 1 to a dozen DBAs.

My PC history makes me rebel against the tight control of tables by
another department.  Their goals never seem to be the same as the
application developers.

Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:

>In article <217e491a.0406251250.67ada577@posting.google.com>,
> riplin@Azonic.co.nz (Richard) wrote:
> 
>
>
>I'm a product of my mainframe environment.  When I think of changing a
>table, or converting a table to a view it fills me with horror.  Not
>only do I need to need to recompile everything (because separate binds
>are dangerous, so sayth the DBAs), but it also involved getting buy-in
>from 1 to a dozen DBAs.

Dynamic binding is the norm in Unix, Windows and IBM, according to IBM
literature. Sounds like your DBAs are applying lessons learned 20+ years ago
.

>My PC history makes me rebel against the tight control of tables by
>another department.  Their goals never seem to be the same as the
>application developers.

You're right. They seem to take delight in obstructing progress.

In my world, programmers develop Views and Triggers in their own schema in a
sandbox. When it's time to promote the package through change management (CM
) ,
they create a script to build the objects in higher levels (in production
schemas) and insert those files into CM along with source programs. DBAs may
 or
may not review them, but they can't sit on them indefinately.

The key to success is to treat database changes the same as source code chan
ges.
Don't let DBAs make them something 'special' that avoids deadlines and
management oversight. They should have Good Reason to block a change. 'I did
n't
get around to it' doesn't make the grade.