Re: Are level checks still useful?

Hi Scott,

In general what you write is very accurate and well-informed, but this
time you're wrong on two points:

If the record size changed, then you'll get an error when reading -- and

therefore will be in the same exact situation you were with
LVLCHK(*YES)... no benefit from using your technique in that case.

Not true; if the actual record length is less than what you specified in
the F-spec, you get message CPF4011 in the job log, warning you that the
remainder of your buffer entry is filled with blanks.

But there are cases where there's additional functionality available
when RPG knows about each key in a composite keylist separately gfrom
the others. For example, you can READE on a partial key with an
externally-defined F-spec, just by specifying the first key in the
keylist. You can't do that in a program described scenario, you always
have to specify the entire keylist. Also, what happens if a key is
defined where part of the key is ASCEND and part is DESCEND? Or
something like absolute value on a key?

Not true; it's perfectly possible to READE on partial keys, either using a
single field or a data structure.

But this probably the only area of RPG where I am more experienced than
you :-) In my company we have been using program described files (i.e. in
RPG; the files themselves are defined through DDS or DDL) since the
inception of the AS/400.

Joep Beckeringh

Scott Klement

hi Nathan,

The difference between using SQL with a program-defined data structure
and your suggestion of using an externally-defined DS with a
program-described read is rather important, I think.

With SQL, it reads the data one field at a time, and copies it to the
RPG field. IF the database definition is changed, an attempt is made to

convert the field from the database style to the program's definition.
For example, if the field has been enlarged from 9 digits to 11 digits,
the SQL would do the equivalent of an "eval", converting the field to
the 9-digit size because that's what the program has.

If the SQL technique uses an ext-def DS, then when the program is
recompiled, it'll automatically adjust the field to the new size. But
in the mean-time it did the best it could -- it converted the field back

to the original size on-the-fly

Compare that to your program-described READ technique with the ext-def
DS. In your case, if the field size changed from 9 to 11, it won't be
detected (unless the total record size has also changed, in which case
you'll get an error.) So if the field size got larger, but the record
size is the same (due to changes in other fields) your technique will
result in part of the DB field being loaded in to one program variable,
and another part being loaded into an unrelated variable. Try it!

If the record size changed, then you'll get an error when reading -- and

therefore will be in the same exact situation you were with
LVLCHK(*YES)... no benefit from using your technique in that case.

And the difference between using a DS for a keylist and using an actual
keylist is that RPG knows it's a keylist. In your case with the DS, the

raw bytes of the combined fields are used as a key... which works in
most cases, I guess.

But there are cases where there's additional functionality available
when RPG knows about each key in a composite keylist separately gfrom
the others. For example, you can READE on a partial key with an
externally-defined F-spec, just by specifying the first key in the
keylist. You can't do that in a program described scenario, you always
have to specify the entire keylist. Also, what happens if a key is
defined where part of the key is ASCEND and part is DESCEND? Or
something like absolute value on a key?

Plus, if your goal is simply to turn off level checking... why not just
specify LVLCHK(*NO)? Wouldn't that make it easier for the next guy to
see what you're up to?