Re[2]: Integrity help?

[Srinivas.Rao@xxxxxxxxxx (by way of David Gibbs <david@xxxxxxxxxxxx>)]

     Tim,

     You rightly said it..trigger will be a better solution. But I have a
     question.. How can we find out, within the trigger program, which
     program is triggering the change ? Is there anyway we can retreive
     that value ?

     srini


______________________________ Reply Separator
_________________________________
Subject: RE: Integrity help?
Author:  midrange.com!midrange-l-owner@mcs.com at INTERNET
Date:    1/8/98 10:34 PM


Tim,

Despite what my distinguished colleagues may have said (oh, and welcome
barb) I would use a trigger in this case.

A client of mine had an identical problem (create dates being updated at
change time) and we used a trigger to identify the offending program. The
biggest problem with the journaling approach is that it may not tell you
what program is corrupting the database; the journal records the program
doing the update, not the program supplying the data. For example, if you
have 10 programs that all call a common program to update your record,
passing the new data values as parameters, the 1 common program will show up
in the journal, you need to see the entire call stack to solve your program.
Also, should you be using embedded SQL to update the database the journal
will show the SQL update program not the RPG (or Cobol) program using it.

Having said that, I would create a trigger program that checked for the
change in the field, and when the change occurs I would record everything I
can. At a minimum I would do a dspjoblog output(*print) and a dspjob
output(*print). You may even want to consider checking if the current job is
an interactive job and if so, pop up a window and ask the user to enter a
brief (unlike this email) description of what they are doing. The dspjob will
show you the entire call stack, and the dspjoblog is always nice to have.

Now, before everyone flames me on the performance impact of all these DSPxxx
commands remember that Tim is trying to find a program that is CORRUPTING
his database, and once found, and fixed, all this trigger stuff goes away.
IMHO, a little performance hit to find a program corrupting my database is
performance well spent.

-Walden

> -----Original Message-----
> From: mcsnet!midrange.com!midrange-l-owner@Mcs.Net
> [mailto:mcsnet!midrange.com!midrange-l-owner@Mcs.Net]On Behalf Of Tim
> Truax
> Sent: Tuesday, January 06, 1998 8:33 PM
> To: ML - Midrange-L
> Subject: Integrity help?
>
>
> Hello all,
> I would like some advice.  I am working with some software that is
> terrible (alot of atrocious hardcoding) and in this particular instance
> -- there are many, many jobs that are affecting 1 field in 1 file and I
> have to identify what program is making a specific change.  (eg)
> File-CUSTMAST  Field-CSCDE9, one program of many is changing this field
> from an 'F' to an 'E', I gotta identify the program and maintain my
> sanity in hardcode village.
> Should I consider a database trigger program?  Any assistance on doing
> this appreciated
> --
> :-) Tim & Dana Truax (-:

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
uucp


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---