Re: Fw: Are level checks still useful?

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

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