Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

V5R3 vs. V5R1 and OVRDBF SHARE(*YES)

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    V5R3 vs. V5R1 and OVRDBF SHARE(*YES)

    jdaly150 wrote: > We have recently encountered a CL program error that is related to > differences in OS/400 V5R1 vs. V5R3. CL programs that were created on > a V5R3 system failed on a V5R1 system, and failed on a V5R2 system. > Both failures occurred when overriding the database file QADSPOBJ. Can't you recompile the CL on the prior release systems? Bill
    Tags: None
  • #2
    V5R3 vs. V5R1 and OVRDBF SHARE(*YES)

    Is QADSPOBJ different in V5R3? In V5R2 it has 104 fields and a record length of 620. The V5R3 Memo To Users does not list changed system outfiles, but does warn of them.

    Comment

    • #3
      V5R3 vs. V5R1 and OVRDBF SHARE(*YES)

      Did you try re-compiling programs specifying the Version Release. That way the program will compile over the right version of the file?

      Comment

      • #4
        V5R3 vs. V5R1 and OVRDBF SHARE(*YES)

        Yes, re-compiling resolves this issue. This program was a release-installer, delivered on CD to our customers. It failed at sites with the older Op Sys's. Eventually, we used a v5r1 and a v5r2 system to create new objects, copied those to our CD, and included logic in the installation program that would check the target system's release level, and use the appropriate edition of the utility. To avoid this in the future, we kept searching, and realized that the SHARE(*YES) parameter was the difference between programs that failed, and those that did not fail. (We did not try the LVLCHK setting, but some of our installation utilities succeeded with the SHARE setting. And, we did not get a level-check error.) So, I am back to Square One: SHARE settings are related to open data paths. Why would sharing that path prevent an I/O buffer size error? Since we have solved this problem, we have no crisis. We just wish the error message had given us more guidance. A level-check error, or a share-path error would have steered us straight. This buffer error did not.

        Comment

        • #5
          V5R3 vs. V5R1 and OVRDBF SHARE(*YES)

          We have recently encountered a CL program error that is related to differences in OS/400 V5R1 vs. V5R3. CL programs that were created on a V5R3 system failed on a V5R1 system, and failed on a V5R2 system. Both failures occurred when overriding the database file QADSPOBJ. Failing programs contained OVRDBF commands without the SHARE(*YES) parameter. Identical programs with the SHARE(*YES) parameter value specification did not fail. The error message that was received was CPF0859: Message ID . . : CPF0859 Severity . . . : 40 Message . : File override caused I/O buffer size to be exceeded. Cause . . : The compile-time file was overridden with a run-time file with a maximum record length smaller than the maximum record length of the compile-time file. Recovery : Remove the override for the file, or ensure that the maximum record length of the run-time file is not smaller than that of the compile-time file. While we can live with the usage of SHARE(*YES) to prevent this error, we do not understand the relationship between open data paths and I/O buffers, or whatever issues are raised by this program failure. Do you?

          Comment

          Previous template Next
          Working...
          X