Re: Fw: Are level checks still useful?

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