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

[CRPence <CRPbottle@xxxxxxxxx>]

  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.