Troubleshooting
Problem
This document describes several ways OPNQRYF can be involved in MCH0601 failures. It also recommends methods to prevent the message from occurring.
Resolving The Problem
The following APARs document reasons and circumventions available for OPNQRYF statements that fail with message MCH0601 when processed by the subsequent HLL program.
APAR SA23024 - Using CL Variables in an OPNQRYF Statement
Error Description: An RPG program has a program-described file with record length specified as 4096 characters. This file is overridden and opened by the OPNQRYF command. The actual record length of the file is 170 characters. This terminates with message MCH0601. Accessing the file without the OPNQRYF command works fine.
Comments: The RPG program DAVID was compiled using a file with a record length of 4096 bytes. Before CLP program ASTRA calls DAVID, it overrides the file REORG to ORG. This file has a record length of 175 bytes. Message MCH0601 occurs because the RPG program assumes it is pointing to a 4096-byte record length file; however, it is only 175. In addition, in the job log is message CPF4123 with reason code 6 that indicates the file was opened with a different record length.
APAR MT05080
Error Description: An RPG program is run that uses QCAEXEC to override a database file with the following command:
OVRDBF FILE(FILE) TOFILE(MDHFCP1.MDPROD)
Then the command QCAEXEC OPNQRYF FILE(MDHFCP1) KEYFLD((FACCOD) (ARPSYR)(ARPSMO)) is run. The RPG program then opens the file called FILE and receives message CPF4123 from QDBSOPEN followed by message MCH0601.
Comments: The user has an RPG program that is compiled against file X. The user then overrides file X to file Y and opens file Y with an OPNQRYF. The RPG program then performs a shared open of file Y, and a message MCH0601 is received by the program when trying to access the records through the shared open. The problem occurs because the record length for file X is larger than the record length for file Y, and the buffers allocated by the original open are not large enough to be used by the second open. A warning message is sent during the second open (CPF4123, TYPE 6), which indicates that the record length for the second open is greater than the original open for the file. The documentation on Page 4-139 of the CPF Programmer's Guide does not apply to shared ODPs. This documentation only applies to the first full open of a file. This is why the user's other program works when not trying to use the shared open of the OPNQRYF.
Circumvention: Following the OPNQRYF command, run the CPYFRMQRYF command to create a new file, then override this file to the RPG program that has the program-described file length. This prevents message MCH0601 because the RPG program will be performing the first full open of the file.
APAR SA26813
Error Description: An RPG application, designed as a generic file handler, uses a programmed-described file with record length 2000. An implicit open of the programmed-described file shares an open data path created by OPNQRYF that has a record length considerably shorter than the programmed-described file. At run time, the job receives message MCH0601 at a specific record number. The application does not fail for all files. The failure depends on the record length of the first open and the number of records in the file.
The RPG User's Guide V2 R2.0, under the heading Sharing an Open Data Path, documents that an error is signaled if the program sharing an open data path for a program-described file specifies a record length that exceeds the length established by the first open; however, after conferring with the development team, it does not appear that this restriction should be valid, and that the user's application should not receive the error.
Comment: The file GENERIC has a record length of 63 bytes. OVRDBF is specified for the file with SHARE(*YES). The file is then opened using OPNQRYF. The IBM RPG/400 program MZL999 is called. It defines file GENERIC as program-described with a record length of 2050 character. The RPG program fails after processing 52 records with message MCH0601. The message is received by the RPG program because while inputting record 53 from the data buffer created by data base, it tries to access data beyond the end of the buffer. A simplistic picture of the scenario would look like this:
Data base requests X number of bytes (the amount based on a calculation using the record length and blocking factor) of space for its data buffer from storage management.
Storage Management assigns database a block of storage, in page size increments; the amount is usually greater than what the data base requests depending on what is available on the system.
|<-----------Buffer assigned to Data Base---------------->|
|<------amount used by Data Base-------->|
_________________________________________________________
| | | | R1 | R2 | R3 | R4 | R5 | R6 | R7 | | |
|________________________________________|________________|
|<-->| Record length of physical file |<--------->| Record
length of file defined in RPG program
|<--------->| READ record 1
|<--------->| READ record 2
READ records 3 to 6
|<--------->| READ record 7
No error, data was not accessed beyond buffer assigned to DB
|<---------------------------->| Record length of file
defined in RPG program
|<---------------------------->| READ record 1
|<---------------------------->| READ record 2
READ records 3 to 6
READ record 7 |<---------------------------->|
|
|
error
Error: Data was accessed beyond buffer assigned to DB
Referring to the above example, the number of bytes from the end of R7 and the end of the buffer assigned to data base is unpredictable and varies depending on record length and blocking factor. What it equates to is if the record length of the file being processed plus the number of unused bytes following the last record in the buffer is less than the record length defined in the RPG program, then an error will occur. The reason that these programs, which worked previous to V2R2, are now failing on V2R2 is because the number of bytes beyond the end of the last record has changed. As can be imagined from the above example, there will be a whole new set of record lengths that work and that do not work. It is possible that in future releases these numbers could change again.
The RPG/400 compiler is working as designed.
Circumvention: One possible work-around for this user is to use FIELD RECORD RELATION indicators to condition the input fields. This depends on how many different record length files are processed by this one RPG program. The record length can be determined by the INFDS or by using Record Identification Code entries.
Historical Number
6514424
Was this topic helpful?
Document Information
Modified date:
18 December 2019
UID
nas8N1010674