|
If you use triggers, a program in essence is launched every time your selected data base files are updated. It does not matter if the user is doing so via your regular ERP software, or some utility like DFU, a dangerous language like interactive SQL, or clicking on your AS/400 file through a PC utility like Windows Explorer. The trigger captures an image of all records being altered before the proposed changes & after the proposed changes & the trigger program has access to both & to the information in the job that is doing this. Your trigger program could permit the action to take place, but compare field for field before/after to determine what got changed & produce report or audit trail showing: Which customers got changed, both key & whosis, what fields got changed - before / after, user-id doing it when, program or utility tool they did it with, work station address they did it from. If you put this in an audit trail file, you can then sort to find out who was the last person to change a particular field. To implement this, you need to study up the relevant manuals on UDB on what you need to do to have the file be monitored by a trigger program, and write the trigger program to capture whatever audit trail you desire. Unfortunately, the business need is often such that we are not always interested in tracking everything that is done to some file. The reality might be: This customer order price is missing. We would like to know if it was NEVER entered, or if someone blanked it out. We want to impose some tentative business rules on some files, but not make them official. Instead, we want to get informational error messages when programs cause data to violate our rules, so that we can then debug those programs. This item's cost master has a negative 0.00002 in the previous level. That field should never be negative. We would like to see a report on all programs that have touched this record so as to identify which action made it violate our business rules. There is a cost that can best be described as absurd. We find it, we zero it out, let the system do its thing & everything seems Ok for a while, then an item cost goes absurd (think of filling the field with all 9's then subtracting 0.00002). We do not know what is causing this. Our ERP is incredibly complex with hundreds of programs touching the file & scores of users of it every day. The total in this General Ledger Account does not seem to us to be correct, but everything adds up right. We want to run a trace on all the data that contributed to this balance in the past 2 months to assure ourselves that there is no embezzlement going on here & that the programs involved are doing the math right. There is a bogus vendor payable in the system for something we never purchased. We would like to know if this was entered by the folks whose job it is to normally enter payables, or if some other person entered it. We have done modifications in the past to assign a field to contain the name of the last person to update some record. This helped immensely in the cases of too many cooks ... several people working from different documents to try to update some customer requirement, where in fact the customer had messed up & provided us with contradictory documents, but the 2 users were outraged that someone was messing up their input, until the interactive screen adjusted to identify the last person who updated this record (normally it should be YOU) highlighted with the name is other than current user. Management has since reduced this kind of risk by designating which humans are in charge of all updating for which accounts. We have histories of various kinds, in which audit trail information goes into a file which users can access via a variety of means. We have modified data flowing into those histories to be sure of capturing user involved in making the transactions, and we have added to the conditions that put stuff into histories. Someone supplied the union with a list of data that has put our labor management negotiators in a very difficult position. We would like to see a list of everyone whose security permits them to print out that kind of data. Mark's situation may be different than ours. But these are some examples of why we might want more tools in our box of diagnostic alternatives, and some of the ways we try to deal with these issues. Al Macintyre ©¿© MIS Manager Green Screen Programmer & Computer Janitor of BPCS 405 CD Rel-02 running on AS/400 V4R3 http://www.cen-elec.com Central Industries of Indiana--->Quality manufacturer of wire harnesses and electrical sub-assemblies From: Oliver.Cherryman@mynd-uk.com (Cherryman, Oliver) Please explain why do you need to know what was read in the first instance ? What's the business practice ? Are your files already journalled ? If so do your applications use commitment control ? Have you considered reading the file in update mode and doing a (dummy) update immediately afterwards to create a journal entry, or trigger a trigger program ? Regards Oliver From: markallen@kellyskids.com (Mark Allen) Thanks but I need to know what record was read (i.e. Customer Master Key=1234567, etc.) Mark Allen IS Manager Kelly's Kids markallen@kellyskids.com -----Original Message----- On Behalf Of Rob Dixon Mark If you journal with OMTJRNE(*NONE) , then your joiurnal will record will record any opens and closes of journalled files. However, it does not tell you which records in a file were read only those which were changed. > Since this has come up here and I have been trying to find a "simple" way > (i.e. like journaling, no program changes) to find out who has "read" a file > and since Simon brought it up in his reply, does anyone have an idea of how > to in essence "journal" read op's??? +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.