Don't you think some of these issues are also due to how long databases on DB2/400 have been inexistence and have not been forced to unload/reload into a new structure either due to a major change in the database engine or a major change in hardware. To go back to a large database that was designed using tools available in the 80's and has hundreds of applications using it and bring it up to date using current tools and functionality is a very time consuming process and sometimes adds nothing to the businesses bottom line. If it does make some process faster or more efficient then it should be done. Yes, dates should be stored in date type fields but 8.0 numeric fields also work and spending your organizations money just to change from one to the other can't be justified on that alone. I do think any new tables (files), columns (fields) should be created using the newest tools available and I do not see any reason not to journal just about every table, old or new.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, March 10, 2008 8:12 AM
To: Midrange Systems Technical Discussion
Subject: Re: Which of the SYSIBM tables/views show the row count for
I have to agree that many of these features are in there and yet, it takes
a severe beating to get people to actually use them.
I argued for a long time that we should be doing journalling. Could only
get them to implement it on a limited table by table basis and only after
the horse got out of the barn.
- How can we find out who's been monkeying around with this data?
- I suspect this one batch EDI job has been hosing this data. How can I
tell?
- Crap. I forgot the where clause on my DELETE statement. How can I get
this data back?
Looking at receivers can tell you this information. And, in the case of
the errant delete statement, retrieve all the data right back.
Finally, when we implemented a H/A solution (Mimix), did we finally have
journalling on all data.
Date fields. My Lord! They are still using numeric dates on new tables.
Constraints. They still have to occasionally go through and delete the
duplicate records out of files. I can't even get them to use a primary
key constraint. Let alone check constraints or referential constraints.
Granted, it's not just DB2 on the System i where I see this. I once moved
a system from Access to DB2. Lots of corruption there also. No
constraints, etc.
Then again, the gent who set that up came from an AS/400 background.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
"Lukas Beeler" <lukas.beeler@xxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/09/2008 10:00 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc
Subject
Re: Which of the SYSIBM tables/views show the row count for
On Sun, Mar 9, 2008 at 8:39 AM, BirgittaHauser <Hauser@xxxxxxxxxxxxxxx>
wrote:
May be other DBAs fell being redundant on the iSeries, because the
system
makes a lot of work for them.
i5/OS takes care of a lot of little details, but a DBA hates dealing
with those details anyway.
The real, important work is still there, but many shops running i5/OS
are still stuck in their AS/400 mindset:
* No transactions
* No referantial integrity
* No Journalling
* No proper DB backup procedures (SWA, Journal Backups)
* No proper DB API using stored procedures (e.G. RLA directly from the
App or SQL directly from the App)
* No SQL Indexes
With many i5/OS databases stuck in the early eighties, there is not
much need for a database administrator.
Of course, this is alone the fault of these shops, and not i5/OS, IBM
or anyone else. Of course i could wildly construct an argument that
IBM's excellent backward compatibility is at fault here, but i'm not
going to do this.
There is one important RDBMS capability that i found missing in i5/OS
DB2, and that was full text search. It is included in V6R1, though.
--
Read my blog at
http://projectdream.org
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
