Re: Fw: Are level checks still useful? -- RPG400-L

I would agree with what you are saying except the part about the system
dynamically determine the position every time. I believe only occurs when
the access plan is recalculated which only occurs if the table has changed
or some statistic like the number of records in the table has increased by
some amount.

Now if you were doing this from a PC it would occur when you did the
PREPARE and would not occur again in that session. If you always used
EXECUTE IMMEDIATE it would be every time (People acactually do that).

I, slso, don't believe there is anything at runtime that checks to see if
the data fits. It is a strict move and if it doesn't fit it blows up. The
compiler may or may not check.

On Thu, Nov 1, 2012 at 4:57 PM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

All:

Native RPG and COBOL I/O uses "record level access" (RLA), similar to
using the C Record I/O routines (_ROpen, _RRead, _RWrite, _RClose, etc.).

Record level access is by definition "record at a time". A record
implies that you read or write the entire record, as a unit. Thus, you
must know the "record layout" -- that is, the mapping or data structure
to describe the fields within the record buffer. This is determined at
compile-time. Thus, a compiled program using record level access, in any
compiled language, is bound to the record layout definition at the time
the program is compiled. This is also true of "program described" files.

Level checks were invented to help prevent the typical errors that can
happen when a file layout is changed, but programs are not recompiled,
and so, the programs still have the old record layout definition "hard
coded" in the generated code. The level-check is a "check-sum" over the
record, taking into account the number of fields, their types, lengths
and decimal places. No consideration is given to field names, headings,
etc.

When the program is compiled over a file with LVLCHK(*YES) specified,
the program incorporates a copy of the Record Format Level ID for each
record format in the file. Then, when the file is opened, a setting in
the UFCB (User File Control Block) controls whether the data management
open routine checks to verify that the record format level IDs in the
program match those in the current file to be opened... if not, the data
management open routine sends CPF4131 as an *ESCAPE message to the
caller (your program), generating an exception. If you issue OVRDBF ...
LVLCHK(*NO) prior to opening the file, or the program was compiled for a
file with LVLCHK(*NO) specified, then this check is not performed, so
you will not get this exception issued by the data management open routine.

So, to summarize, record level access implies your program must "know"
(at compile time and at runtime) the layout of the file records.

On the other hand, let's consider how SQL works.

With SQL, even though there are records with a "layout", when accessing
a table or view via SQL, you are concerned only with the table name (or
view name) and the column names (field names) you want to access.
Thus, you no longer have a direct dependency on the layout of each
record in your program. Of course, you still must ensure that your
"host variables" are of the right data type and length to containe the
values returned from the row(s) fetched, or you will get an SQL runtime
error returned in SQLCODE and/or SQLSTATE.

So, for example, if a column size has been increased, since you created
your program, and so your host variable (local variable field) may no
longer be large enough to contain the new size of the column, this is
not necessarily an error -- unless you happen to FETCH a row (record)
that contains a value that is in fact larger than will "fit" into your
host variable.

So, this is why SQL access normally does not check the "level ID" of the
record format(s), because SQL only considers it an error if the actual
value in the current row fetched with a cursor will not fit into your
host variable.

SUMMARY
=========
Record Level Access = binds the record layout at compile-time;
Level-checking ensures at runtime that this binding is still valid

SQL access is by table / view name and column name -- all that matters
is that the actual data value for a column in a given row will fit iinto
the corresponding host variable at runtime. This is a "row at a time"
error, rather than an error for the entire table, and so is not checked
at open time, but rather, on each fetch.

This summary should also give you some idea why record level access is
normally faster than SQL, because SQL must dynamically determine the
position of each column in the record at runtime, and must ensure that
each value will "fit" into each host variable, row by row, also at runtime.

Hope that helps give some perspective on the "pros and cons" of SQL
versus RLA ... and helps you choose when to use which tools to best
advantage.

All the best,

Mark S. Waterbury
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.