OVRDBF only half way supported in compiling for V6R1

IBM made a small error when adding the new EXTDESC support in V6R1. That
is the OVRDBF support previously used is a little flaky. They opened APAR
SE36380 to resolve it. Here's some details below:

I have two files with the same name. One is in library GDIDIVF and one is
in library ERPLX832F. ERPLX832F is in my library list. They have
different formats, in other words, when you do a DSPFFD they will not
match. Before I compile this program I do an OVRDBF of AVML02B to
GDIDIVF. And the compiler list "HALF" way does it. Here's the definition
of half way:

The compiler tells you this:
* RPG name External name
* File name. . . . . . . . . : AVML02B GDIDIVF/AVML02
* Record format(s) . . . . . : CDAVM IPA100VM

However the generated I specs match the DSPFFD of file AVML02 from
ERPLX832F.
242=ICDAVM


*--------------------------------------------------------------------------------------------*

* RPG record format . . . . : CDAVM
*
* External format . . . . . : IPA100VM : GDIDIVF/AVML02 *

*--------------------------------------------------------------------------------------------*

243=I A 1 1 VNSTAT
Vendor Status
244=I A 2 3 VMID
Record ID (VM/VZ)
245=I P 4 8 0VENDOR
Vendor Number
246=I A 9 58 VNDNAM
Vendor Name
247=I A 59 108 VNDAD1
Address Line 1

DSPFFD ERPLX832F/AVML02
Data Field Buffer Buffer
Field Type Length Length Position
VNSTAT CHAR 1 1 1
VMID CHAR 2 2 2
VENDOR PACKED 8 0 5 4
VNDNAM Open 50 50 9
VNDAD1 Open 50 50 59
...


DSPFFD GDIDIVF/AVML02
Data Field Buffer Buffer
Field Type Length Length Position
VNSTAT CHAR 1 1 1
VMID CHAR 2 2 2
VENDOR PACKED 5 0 3 4
VNDNAM CHAR 30 30 7
VNDAD1 CHAR 30 30 37
...

We noticed that if you stop using
Target release . . . . . . . . . : *CURRENT
and use *PRV instead it will work.

We are not using the new V6R1 stuff (EXTDESC) because of *PRV for some of
our other machines.

Business application:
SSA/Infor/BPCS (put name-of-the-day here)
Posting data from old version into new version.

Rob Berendt