No, I do not believe that adding CL compiler support for the previous
releases will give you the desired file layouts. Just previous command
Suggest work arounds include, but are not limited to:
- Do not use RPG RLA methods of reading the data. Read it using SQL
instead. Select only the columns you need and avoid "SELECT * from..."
like the plague.
- Build a LF over the temporary table that only selects the desired
- Stop using outfiles and use APIs instead. (My personal favorite.)
List Objects (QUSLOBJ) API
Open List of Objects (QGYOLOBJ) API
- Upgrade your OS to a current version and use something like
Apparently when you go to a "smaller" output file (typical in an earlier
release) you cannot fix that by specifying LVLCHK(*NO) or you will get the
error you are receiving. And you're still crossing your fingers that IBM
didn't change the attributes of an older column instead of just adding new
columns on the end. If it was only new columns on the end, and you were
going to a higher release, then LVLCHK(*NO) would help.
As a software vendor you should avoid output files created by the OS.
ESPECIALLY if you are supporting multiple levels of the operating system.
There's not a Memo To Users out there which does not include these lines:
Output file(OUTFILE) changes
Release to release Output file(OUTFILE) considerations
Applications using LVLCHK(*YES) might be affected by changes to
IBM-supplied system output files in
this release. IBM commands and APIs that generate database output files
might add new fields to the end
of record formats, or use all or part of existing reserved fields for
additional information returned each
release. Adding new fields to the record format, even to the end of the
record, changes the level check
value for the file. This might cause an application with LVLCHK(*YES) to
fail with a level check error. If
a level check error does occur, review the application to determine which
system file it uses. New fields
have been added to IBM-supplied database files in each release of IBM i.