RE: trigger program: can I fool a program into reading some selec t fields from another file?

Thanks for the reply.  My actual situation is more complex; I was trying to
describe it in the simplest way.

My company has 20 divisions, each with a separate item master file (in a
common identical format).  The one item Heinz Apple Juice has 20 different
item numbers in the 20 different item master files (in 20 different
libraries), with 20 similar (but different) descriptions, 20 similar (but
different) package dimensions, etc.  We would like to bring the item
maintenance into one item file with one maintenance program.

But since 20 different people control the item description, division 1 calls
it item# 123 Heinz Apple Juice; division 2 calls it item # 456 Apple Juice
(Heinz), etc, etc.

One thought is to maintain a single corporate item master (with one item
record for Heinz Apple Juice), and propogate the descriptive info and
pricing out to each division's item master file.

This of course breaks the #1 rule of database design; that being dont store
the same data in more than one place.

I thought it would be a perfect use of trigger files if I could alter the
record format buffer during a read operation:  When division 2 reads item
#456, the trigger program could go out to the corporate item master file,
and find the corporate item info.  The trigger program could then return the
corporate info to the division's programs.  The division program would not
have to be modified, since the trigger would handle the additional file I/O.

But alas, it appears that this is not possible.

The logical file is a good idea, but I need to include logic in the trigger
program; ie it is not always read one corporate record for each divisional
record.  For example, pricing would require loads of logic to fetch prices
from a coporate file.

Any other ideas??

Thanks!



-----Original Message-----
From: Booth Martin [mailto:Booth@xxxxxxxxxxxx]
Sent: Monday, October 13, 2003 3:14 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: trigger program: can I fool a program into reading some
select fields from another file?


Yes you can. With a *BEFORE trigger. Chain to the new file, get the new
value, and change the output buffer of the record. 
 
However it will change the output buffer every time, even after it has
already been changed. I have the feeling I am missing something. Why not
just change the data in original file and be done with it?
 
 
 
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: Midrange Systems Technical Discussion
Date: Monday, October 13, 2003 2:45:40 PM
To: 'Midrange Systems Technical Discussion'
Subject: trigger program: can I fool a program into reading some select
fields from another file?
 
I have 1000+ programs reading a customer master file (the old cust file).
Can I add a trigger program which performs the following:
 
Whenever a program which reads a record from the old customer master file:
 
Read a different new customer file, get the customer's address from the new
file, and place the new address field into the address field in the old
customer record format.
 
Using this method, I could add a new file and not have to change any of the
many programs using the old customer master file.
 
If not a trigger program, is there any other method to accomplish this on
the Iseries?
 
I am aware of OVRDBF, but that will not allow me to grab select fields from
another file.
 
Also I am familiar with OPNQRYF, but that would require CL changes and would
limit the ease of implementation. Also, OPNQRYF would not support any logic
built into the record retrieval.
 
If I could use a trigger program, in theory, I could make a database change
which would require no changes to programs using the customer file.
 
Thanks!
_______________________________________________
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.