Re: FILE TRIGGER

["Mark S. Waterbury" <mark.s.waterbury@xxxxxxxxxxxxx>]

Hi, Charles:

I stand corrected.  Taking my own advice, I compiled a small OPM RPG/400 
program that reads from a sequential program described file and writes 
to another program described file, until EOF, and compiled it with 
CRTRPGPGM ... GENOPT(*LIST), and after studying the resulting OPM MI 
generated code in the listing, I now see the code that blocks and 
unblocks records on input and output for sequential files.

The database is still invoked, but with a fixed number of records, so 
that it reads or writes an entire block of records "in one go"...

What happens is, at open time, the number of records is merged into the 
UFCB from the OVRDBF, so this is how the system can control blocking (or 
not), without having to recompile the program,

Also, as in the case of the CPF4028 message, the system (QDBOPEN) can 
then change the number of records per block (as specified in the IUFCB) 
to "1", so this in effect causes the generated code to think that it has 
a full block each time it reads or writes one record, and so, each 
record read or write results in a call to QDBGETSQ or QDBPUT, respectively.

Thanks for forcing me to re-visit this.  I had not looked at that OPM MI 
code generated by RPG/400 for quite a few years now, so my memory was a 
bit "fuzzy" about exactly how this works... So, it was good to get a 
"refresher" by studying that code once again.

All the best,

Mark

On 12/3/2010 4:42 PM, Charles Wilt wrote:
> My point is that if we consider the DBMS the part of the OS that
> handles triggers, referential integrity, constraints, and has ACID
> properties.  Then blocking via SEQONLY parameter and the BLOCK
> keywords must be done (or controlled) by RPG and/or the OS above the
> DBMS.
>
> If it was done by the DBMS, there would be no reason to disallow it,
> as evident by the the CPF4028 message, when a file has triggers,
> referential integrity and constraints.  Nor would we ever have the
> situation where a record was written by one program yet not seen by
> another.  Lastly, we would not need a FEOD(N) which forces "unwritten
> records in the block will be written out to the database"
>
> Charles