Re: What would you do without RPG?

On 31-Jul-2014 08:20 -0500, Steve Stevens wrote:

<<SNIP>>

Those of us with memories going back far enough to remember the
AS/400 as the Silverlake/38 will remember that it was originally
marketed as not needing the type of systems staff that was required
for mainframes. And this is largely true, however I have had to
reorganize tables (which rebuilds indexes) and other system tasks
over the years. And yes, I have added logical files (indexes) at the
suggestion of the query optimizer. Almost like a DBA would. <<SNIP>>

With the DB2 for i, as an integrated database, the roles that might typically be described as the system operator and system administrator often will handle a lot of the messy stuff that a typical DBA of another RDBMS will have to muck with. And much of that extra work being done on the other RDBMS is not entirely offloaded from the work remaining for those other parties; i.e. those other /system/ duties are still being done on the other OSes, with the same kinds\amount of work irrespective _extra work_ the DBA may be doing, such that there is a net increase in resources required. Instead of creating tablespaces and databases and doing effective backups within a world-view that is purely the RDBMS, the DB2 for i has all of that stuff integrated, thus the administration\operation of the /system/ eliminates all of that worthless grunt-work of the DBA. If a DBA is not tasked with all kinds of that busy-work, then either they can accomplish more worthwhile tasks as that same resource, or the reduced amount of overall work required can be picked-up by other resources serving-as\assigned-to different roles; e.g. programmers and sys admins might just serve in place of a separate DBA resource.

So without the separation of DB-is-distinct-world-view that exists with a typical RDBMS atop an OS, the DB-is-the-system-world-view with the DB2 for i can have much of the work to deal with the DB being done outside of the DB, at the system-level. With the OS install, the DB is installed; whatever space is configured for the system is implicitly available to the DB. With a full system save there is not only a save of the database(s) but saves of the individual SQL /objects/ and logs from which specific data can be restored.

There are advantages to be found, either way things are done [integrated or not], but given a consolidated [system] view, instead of having to learn a bunch of the similar-but-different work required of the RDBMS separate from the system, that allows for the possibility that the work of the effective DBA resource does not require entirely new\separate learning; much of what is learned about non-database applied directly and often exactly the same to the database. IMO, getting someone who already has learned about the IBM i to perform some DBA-like tasks is much simpler than getting someone who has learned about the Win OS to learn how to do the DBA tasks of DB2 LUW.

BTW, the reorganize of physical data is a separate topic from the activity of _reorganizing indexes_ in other databases; some other databases have effectively the same feature to reorganize the data, and at the same time rebuild the indexes. And whereas a keyed Access Path of the DB2 for i can be rebuilt [e.g. with CHGLF requesting Force Rebuild Of Access Path (FRCRBDAP) or changing the Maintenance (MAINT)], there is almost never any requirement to do so as part of regular /maintenance/ in order to ensure proper performance. Reorganizing indexes on other databases may be done periodically [as part of routine maintenance performed] by the DBA, supposedly to ensure good performance from those indexes. If someone were to routinely forcibly rebuild keyed access paths of their database files on the DB2 for i, they would rightfully be labeled as crazy\mad :-) The DB2 for i was even enhanced long ago in a manner that allows avoiding the index rebuilds as part of the reorganize of the physical data.