Troubleshooting
Problem
There are many situations that can cause message MCH3601 or MCH0601. This document lists the most common causes of the message.
Resolving The Problem
There are many situations that can cause message MCH3601. Following is a list of the most common causes.
IBM high-level languages (RPG, COBOL, etc), whether ILE or OPM, pass parameters by reference. When a parameter is passed to another program, only the address to the information is passed rather than the information itself. There is no communication between programs on what size the parameters should be. Therefore, if there is a parameter mismatch between the calling program and the called program, the HLL compiler has no way of determining or verifying this. The problem is not evident unless either program attempts to use the storage that has been corrupted, or tries to write past the space currently allocated for your job.
This parameter size mismatch is very common. The errors are shown in the following ways:
The information in message MCH3601 or MCH0601 is normally useless in finding the cause of this type of problem. Message MCH3601 happens as a result of storage corruption that might have happened in a previous program CALL. Message MCH0601 occurs when you attempt to write data past the space allocated for your job.
The only way to debug this type of problem is to look at where the failure occurs. Then, backtrack starting with all parameters on any CALL, CALLB, CALLP, or EVALs that work with addresses in subprocedures. Review the lengths of the parameters in the called and calling program and any CALLs in these programs. Compile listings are a good place to start. If using subprocedures, review any EVAL statement that is assigning an address.
When these failures start happening, also consider any recent changes in the full application landscape(code changes, data changes, API changes, etc). As again, the application that is showing the message may not be the root cause of the issue. For example:
An upstream application creates a malformed message, that when passed downstream, to an unchanged application starts, failing with MCH messages because the downstream application was not designed to handle the malformed message.
For calls to IBM APIs, ensure that any 'length' or 'bytes provided' fields that are used as input to the API have the correct values per the API doc.
Make sure that fields are the correct size that the API documentation requires. For example, if an API requires Binary(4), make sure that your variable in whatever language you are using is 4 bytes long.
In RPGLE, people often use a 4B thinking it will be a 4 byte binary, however in RPG, 1B - 4B use 2 bytes, and 5B - 9B use 4 bytes, so using 4B does not equate to a Binary(4). You should use 9b or preferably 10i which is a 4 byte integer.
Another common mistake in RPGLE deals with the use of optional parameters. If you have a procedure with optional parameters, the procedure must make sure that if the parameters are not passed, it does not attempt to access them.
Another common mistake deals with the use of API parameters that are documented as "omissible". These are not optional parameters. "Omissible" means that it is valid to pass a null pointer instead of a parameter. Your programming language may allow you to pass *OMIT as a parameter in this case. If you neglect to pass an omissible parameter, the API may refer to the location where the parameter should have been, and it may find a valid pointer from some earlier call which may be completely unrelated to your application. If the API then updates that parameter, it will cause storage corruption in whatever storage that pointer happens to be pointing to. The most common error is failing to pass the "feedback" parameter to CEE APIs. A symptom of this error is that storage will be corrupted with a value beginning with "CEE".
2: Another common cause that can lead to this type of issue, is failure to initialize the bytes provided of an error code parameter on an API call:
https://www.ibm.com/support/pages/node/667555
**Expert Labs can be engaged if in depth assistance is required in debugging the issue.**
IBM high-level languages (RPG, COBOL, etc), whether ILE or OPM, pass parameters by reference. When a parameter is passed to another program, only the address to the information is passed rather than the information itself. There is no communication between programs on what size the parameters should be. Therefore, if there is a parameter mismatch between the calling program and the called program, the HLL compiler has no way of determining or verifying this. The problem is not evident unless either program attempts to use the storage that has been corrupted, or tries to write past the space currently allocated for your job.
This parameter size mismatch is very common. The errors are shown in the following ways:
| o | Message MCH3601 is issued. |
| o | Data is overlaid. Your program receives message RPG0907 or MCH1202 or a user will complain about bad data coming up somewhere. |
| o | Message MCH0601 results if the data is accessed or moved outside the space assigned to the program. |
The information in message MCH3601 or MCH0601 is normally useless in finding the cause of this type of problem. Message MCH3601 happens as a result of storage corruption that might have happened in a previous program CALL. Message MCH0601 occurs when you attempt to write data past the space allocated for your job.
The only way to debug this type of problem is to look at where the failure occurs. Then, backtrack starting with all parameters on any CALL, CALLB, CALLP, or EVALs that work with addresses in subprocedures. Review the lengths of the parameters in the called and calling program and any CALLs in these programs. Compile listings are a good place to start. If using subprocedures, review any EVAL statement that is assigning an address.
When these failures start happening, also consider any recent changes in the full application landscape(code changes, data changes, API changes, etc). As again, the application that is showing the message may not be the root cause of the issue. For example:
An upstream application creates a malformed message, that when passed downstream, to an unchanged application starts, failing with MCH messages because the downstream application was not designed to handle the malformed message.
For calls to IBM APIs, ensure that any 'length' or 'bytes provided' fields that are used as input to the API have the correct values per the API doc.
Make sure that fields are the correct size that the API documentation requires. For example, if an API requires Binary(4), make sure that your variable in whatever language you are using is 4 bytes long.
In RPGLE, people often use a 4B thinking it will be a 4 byte binary, however in RPG, 1B - 4B use 2 bytes, and 5B - 9B use 4 bytes, so using 4B does not equate to a Binary(4). You should use 9b or preferably 10i which is a 4 byte integer.
Another common mistake in RPGLE deals with the use of optional parameters. If you have a procedure with optional parameters, the procedure must make sure that if the parameters are not passed, it does not attempt to access them.
Another common mistake deals with the use of API parameters that are documented as "omissible". These are not optional parameters. "Omissible" means that it is valid to pass a null pointer instead of a parameter. Your programming language may allow you to pass *OMIT as a parameter in this case. If you neglect to pass an omissible parameter, the API may refer to the location where the parameter should have been, and it may find a valid pointer from some earlier call which may be completely unrelated to your application. If the API then updates that parameter, it will cause storage corruption in whatever storage that pointer happens to be pointing to. The most common error is failing to pass the "feedback" parameter to CEE APIs. A symptom of this error is that storage will be corrupted with a value beginning with "CEE".
An addendum on this topic.
1: Using a file which is setup for SHARE(*YES) an MCH3601 will occur when the following is done:
Program 1 opens the file for input and update, and Program 2 opens the file for output and then tries to write to the file.
The error occurs because there is no output buffer for the file.
Program 1 opens the file for input and update, and Program 2 opens the file for output and then tries to write to the file.
The error occurs because there is no output buffer for the file.
In the job log there will be a warning message CPF4123 saying that the open options for the file were ignored.
This is because the file was setup for SHARE(*YES) and then opened in Program 1 for input and update.
The system ignores that Program 2 now wants to open the file for output and issues the warning message.
The same errors will occur if you reverse the opens, opening the file first for output and then for input.
This is documented in the Database Database Programming guide, under the sections Sharing Files in the Same Job and Open Considerations for Files Shared in a Job.
This is documented in the Database Database Programming guide, under the sections Sharing Files in the Same Job and Open Considerations for Files Shared in a Job.
2: Another common cause that can lead to this type of issue, is failure to initialize the bytes provided of an error code parameter on an API call:
https://www.ibm.com/support/pages/node/667555
**Expert Labs can be engaged if in depth assistance is required in debugging the issue.**
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHtAAM","label":"Programming ILE Languages"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
326127886
Was this topic helpful?
Document Information
Modified date:
20 October 2025
UID
nas8N1019244