On 01 Mar 2013 12:53, Stone, Joel wrote:
Have you considered the obvious - OVRDBF FILE() LVLCHK(*NO) ?
If it's a QTEMP file it should be pretty safe.
Ignoring level check is not any safer just because the file is being
created into library QTEMP. Hardly an _obvious_ choice IMO. Ignoring
level checks should not be the first option. And perhaps keeping level
checking active *is even more important* for the use of a dynamically
created file [into QTEMP], than compared with other programs that might
more easily be maintained by direct reference to production files; i.e.
querying DSPPGMREF to find impacts might tend to miss dynamic files
which are _generated from_ production files rather than being as
conspicuous as the production files themselves.
The following example for consideration:
Setup:
create table prod_lib/prod_file
( prod_user char(10), prod_col1 int, prod_col2 char(20) )
;
create procedure copy_prod_file () language sql
begin
create table qtemp/my_copy as
( select prod_col1, prod_col2
from prod_lib/prod_file
where prod_user = current user ) with data ;
end
;
crtclpgm my_clp /* from source with: DCLF QTEMP/MY_COPY */
Eventually [after setup]:
The program MY_CLP depends on the layout of the columns in the file
QTEMP/MY_COPY, as a non-SQL program. That program would best depend on
LVLCHK(*YES) just as with a file in any other library, to ensure changes
to the record format of that file are notified to the program when that
program runs.
If the production file is updated with the following statement, then
the program ignoring level check would get very poor results after
calling the COPY_PROD_FILE routine:
alter table prod_lib/prod_file
alter column prod_col1 set data type decimal(13)
After that ALTER, when using LVLCHK(*NO) for a CALL MY_CLP, that
would be a classic GIGO scenario. However...
If the program that was compiled against the original definition of
the file MY_COPY had been a SQL program instead of RLA, then that
program has the same ability as the ALTER did to effect the cast between
the new DECIMAL type and the old INTEGER type [for any values that do
not exceed the bounds of an INTEGER]. But more importantly, there is no
residual decimal data being interpreted as the first three bytes of the
prod_col2 character data like would occur for having ignored level check.
midrange.com
