×
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.
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
midrange.com
