× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Tim,

I wrote a generic trigger program which uses a compile-time array at the
bottom of the trigger program source, with the following layout:

1-10: File
11-15: Field start position in buffer (as a signed numeric)
15-20: Field start position in buffer (as a signed numeric)
21-21: Field type
22-31: Field name
32-71: Field text

so the array looks something like the following for file MYFILE which has
two fields:

ORDVAL 5,2 Packed
USRPRF 10 Character

** CTDATA
...
MYFILE 0000100003PORDVAL Order code
MYFILE 0000400010AUSRPRF Order user profile
...

Then in the code, I have something like the following (pseudo-code) to check
each field on each file and see if it's changed.

for x = 1 to %elem( Array );
if Array.File(x) = TriggerFile;
if %subst( oldrecord : Array.BufPos(x) : Array.BufLen(x) ) <>
%subst( newrecord : Array.BufPos(x) : Array.BufLen(x) );
writediff( Array.Text(x) : %subst( oldrecord : Array.BufPos(x) :
Array.BufLen(x) ) );
endif;
endif;
endfor;

Add in some code to convert numeric values to character values for display
(which you can determine from the field type byte in the array) and there
you go - 8 lines of code. You just add records to the array for every
file/field...

Of course, you could replace the CT array with a lookup file - there's
probably one of the system files out there (related to SYSTABLES, perhaps),
which has this information, but might be a performance hit to read it. An
even better solution would be to read the lookup file (either your own or a
system file) into an array defined in the program the first time the program
is called, and then read that array on each subsequent access. That has the
benfit of good performance and, if you use a system table, you'll know it's
always up to date. Maybe load the array into a user space (accessed via a
pointer) and you could load it asynchronously after each IPL or file change,
but that's getting fancy. Lots of options.......

Mind you, as I was writing this email, it sounds like you're going the
journal route anyway :-)

HTH,

Rory

On Wed, Aug 27, 2008 at 5:34 PM, tim <tim2006@xxxxxxxxxxx> wrote:

I have a trigger program to log any changes in a file. Here is snippit:





D OldRecord E DS ExtName(filea)

D Prefix(O_)

D Based(OldRecPtr)



D NewRecord E DS ExtName(filea)

D Prefix(N_)

D Based(NewRecPtr)





if n_name <> o_name;

writediff('name':o_name);

endif;

if n_salut <> o_SALUT ;

writediff('Salutation' : o_SALUT );

endif;



I repeat this logic for each field in the file. If I have a file with many
fields, it can be quite tedious.



I was wondering if this could be done a different way so that as I add more
files to this logging process, all I would have to do is change a file name
or something. I was thinking it would have something to do with pointer
logic, but not sure where to start.



Thanks.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.