Re: Are level checks still useful?

Thanks for the reply, Scott. I understand that if you change the length of a table column and don't recompile the program, you'll end up with a data overlay problem. I would just recompile the program and not make a fuss about it. I'm not sure that sql select into :rec is much of an improvement, however. That program should probably be recompiled too. However, this technique allows extensions to tables without requiring extra work on lazy programmers.

I do see similarities between altering an "f" spec and setting LVLCHK(*NO), but I also see some differences. An "f" spec affects one program. LVLCHK(*NO) affects all programs. It could come down to preference. When you recompile a program that uses a file that was changed, the length mismatch error between the "f" and "d" specs may remind you to add code to properly initialize the new columns.

It's kind of appealing to pair a file name and a data structure name, not only between an "f" spec and a "d" spec, but also pairing the factors on READ, WRITE, CHAIN, and UPDATE operations. That's kind of an appealing convention. Otherwise one programmer may use a file name for factor 2 while another may use a record format name.

I would think that one could used a partial data structure for a partial key list. I should test that.

-Nathan





----- Original Message -----
From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Cc:
Sent: Wednesday, November 7, 2012 1:07 PM
Subject: Re: Are level checks still useful?

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?