Tommy, How do you handle data that needs "fixed" in production systems? Let's say someone in the accounting office started a batch of AP invoices and used a date of 03/10/2009 instead of 03/10/2008 and then entered 100 invoices under that batch which replicated the batch date into each invoice record and tagged 100 Pos as being paid. The head of AP comes to you asking you to fix the date. The alternative being to delete all 100 invoices and untag the Pos the delete the batch and start all over, which would put them a day behind schedule and the president of the company wanted someone paid TODAY!!!!. Do you just say sorry, can't do that, not my problem? (Of course the head of AP is going to report that IT was unwilling to help them.) With the proper documentation from the proper people we would use DFU/WRKDBF/STRSQL to fix this type of problem in just a few minutes knowing that journaling is there to provide an electronic audit trail and we have the documentation to back it up.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent: Monday, March 10, 2008 11:28 AM
To: Midrange Systems Technical Discussion
Subject: Re: Which of the SYSIBM tables/views show the row count for
FWIW...first thing i try to get rid of is DFU in any shop. (and DBU,etc.
*dons flame-resistant apparel*) any info i need about a file and it's
attributes and data can be retrieved in less *dangerous* ways.
unfortunately some people *still* insist on using DFU, etc in production
environments (if you want to use 'em do it on a dev/test box. production
machines IMO should never have these tools installed. even if you only
have one machine there are methods available that don't allow you to
tamper with production data directly bypassing the applications.
Thanks,
Tommy Holden
From:
rob@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
03/10/2008 10:20 AM
Subject:
Re: Which of the SYSIBM tables/views show the row count for
Tommy,
I feel the final checking, the last gate to pass, should be the
constraints. If I can put stuff in there using UPDDTA that I couldn't by
using the application, then something is wrong.
Now, error checking in your applications is a matter of style. Yes, you
could check the status on writes or updates, and perhaps evaluate that
further (maybe even down into the joblog) and evaluate the errors thrown
by the constraints and triggers. And that would be 100% effective (or at
least better be). And, you should probably have this logic in there
anyway in case a new constraint is added. I'll agree with you, it's a
PITA.
I can understand if you want to duplicate this checking in your
application. Makes it easier to highlight fields in error, etc.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/10/2008 11:10 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
while i don't mind constraints, etc...if the checking and validation ISN'T
done in the application, you'll have stuff crapping out and never making
it into the database and troubleshooting is a PITB...so moral of my lil
story, force your programmers to do the checking first and ensure they are
following the process or you'll be sorry...
Thanks,
Tommy Holden
From:
rob@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
03/10/2008 10:00 AM
Subject:
Re: Which of the SYSIBM tables/views show the row count for
Why does it drive you bonkers to put any constraints and triggers on the
database? Why do you insist it be ONLY in the application (or some
database wrapper)?
In that case, why use externally defined files? After all, you can put
all the column descriptions in your applications. People did this for
years on the S/34 and S/36. And punched cards before that. If you are
truly using only application programming to access the database, or
wrappers, why would you need the external definitions? I've worked with
vendor applications in which the column, and table, text were pretty much
limited to "Copyright".
And it would be glorious if applications never had an error,
If no one ever hacked into data for malicious purposes,
And if no one ever made a keying error when using a database utility
And if no one ever had a need, or use, for UPDDTA, WRKDBF, or such
utilities.
But everyone joining hands and singing "Kumbaya" is not going to make it
so.
Therefore journalling, constraints and other tools should be used.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/10/2008 10:36 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
rob@xxxxxxxxx wrote:
Joe,
System crashes do happen on the System i. Not very often, but they're
still there.
Can we agree to modify it to say "rarely" happen?
Based on rarely, (if ever, to coddle some), then I say the primary
reason
for these features is not for a system crash. But to prevent things
like:
- Orphaned children (items whose item class is not on file sort of
stuff).
- data auditing
- data recovery from program errors or 'hand' maintenance.
- data protection from hand maintenance.
If, you crash once every five years, is it necessary to add additional
system complexity? Or is going to yesterday's backup tape good enough?
It's a business decision.
Yes, RI is required. Even if your applications are "written correctly".
Because as much as we'd like to force every one to use our stored
procedures to access data, but reserve the right for ourselves to access
the data directly, the other developers won't follow that double
standard.
They have business needs, such as mergers and acquisitions, that may
not
fit so well into the model. I'll grant you that last statement may be a
little conjecture.
We've hashed this out over and over. If you have programmers going at
your database and screwing it up, you need new programmers. The real
concern is unfettered ODBC access. If you allow updates via ODBC, you
probably need all of the above: RI, constraints, and so on, as well as
exit programs and audits and logs and every other darned thing, because
your database is an accident waiting to happen.
I'd also seriously look at check constraints. I see dates that pass
conversion into true date fields. However I fail to believe that we
have
any active employees that have a birth date back in the 1600's.
So why didn't your maintenance program pick this up?
This also is opinion so it's time for me to get out. If in your shop
you have developers who regularly screw up the production database, then
perhaps you need all those things. To me, it's another business
decision. I know shops where programmers aren't allowed to touch the
production database and there's no outside access, so it really is only
the application program. It's all a matter of your corporate philosophy.
Joe
--
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.
--
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
