I may be incorrect, but my recollection is that...
. the database *FILE QADSPOBJ would be shipped in the
QSYSV5R3M0 library if & because it had changed
. during the TGTRLS(V5R3M0) compile, the compiler issues an
effective CHGSYSLIBL QSYSV5R3M0 in addition to invoking the V5R3M0
version of the compiler
. the DCLF having used the [defaulted] *LIBL [or even
explicitly QSYS as I recall], the above change to the system library
should affect the compile, such that the *PRV version of the file
[record format] will appear [with the qualified name appearing as
from the *PRV library] in the DSPPGMREF output for the program
. the database *FILE object QADSPOBJ ships with LVLCHK(*NO)
Thus for a program that is compiled to V5R3M0 which is then both
restored to and run on a V5R3M0 system, the compiled object should
reflect the format level identifier of the V5R3M0 object and thus
not generally level check [excepting perhaps crossing between DBCS &
SBCS languages]; given level check is even active for the model
database file, and thus for the output file generated by the program.
If the program /bombs/ with a level check error, ensure a copy of
the database *FILE QADSPOBJ exists in the QSYSV5R3M0 library, and if
not, or that the record format of the file matches the V5R4M0 copy,
and verify that file in QSYS has LVLCHK(*NO). If not, for any of
those, then investigate why. Issue a CHKPRDOPT OPTION(9) if the
file is missing from the *PRV library.
If indeed the file was different between releases, then of course
the same program object could not run without level check on both
releases, except by using OVRDBF LVLCHK(*NO) or CHGPF LVLCHK(*NO) on
at least one of the releases. That is, when level check is active,
then a copy of the program compiled to run at TGTRLS(*CURRENT) would
be used on the current release, and the program compiled to run at
TGTRLS(V5R3M0) would be restored to and used on V5R3, not on V5R4.
Tommy Holden wrote:
when you compile to *PRV, it *only* changes the way the program
is compiled, not the file structure it's compiled against. the
APIs will protect you from these types of issues. so you have 3
choices, either write your own DSPOBJD to the "old" format,
recompile/modify the programs to use the changed format or fix it
for good by rewriting to use the APIs. should you choose option 1
or 2 be forewarned that should the file change again in future
releases you'll have to go through the same headache again.
Jack Kingsley wrote:
Outside of converting it to using API's is there an alternative
solution, I didn't want to have to rewrite it, if not then I
will research the api route.
Yes, stop using DSPOBJD to an output file. Use apis like
- List Objects <<SNIP>>
Multiple version support is one of the first reasons I first
started using APIs.
Jack Kingsley wrote:
Is there a workaround for a cl program that is creating a
file under V5R4 (dspobjd to an outfile) where the field
lengths are different. I have compiled a program to run
*PRV but when I run the program on the V5R3 machine it