Re: DSPOJBD (field length changes) V5R3 to V5R4 help needed

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.

Regards, Chuck

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.

Rob wrote:

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
bombs.