Question & Answer
Question
What leads to Message MCH4429 reason code 2?
Cause
Message ID . . . . . . . . . : MCH4429
Message file . . . . . . . . : QCPFMSG
Library . . . . . . . . . : QSYS
Message . . . . : Automatic storage overflow.
Cause . . . . . : One of the automatic storage stacks &1 for the thread has overflowed or a storage access beyond the maximum size of a teraspace automatic storage stack was attempted. Further program execution within the thread is not possible. Automatic storage stack values and their meanings follow:
1 -- System stack in single level storage.
2 -- User stack in single level storage.
3 -- System stack in teraspace.
4 -- User stack in teraspace.
Technical description . . . . . . . . : Attempt to reduce the automatic storage used by programs running in the thread.
Message file . . . . . . . . : QCPFMSG
Library . . . . . . . . . : QSYS
Message . . . . : Automatic storage overflow.
Cause . . . . . : One of the automatic storage stacks &1 for the thread has overflowed or a storage access beyond the maximum size of a teraspace automatic storage stack was attempted. Further program execution within the thread is not possible. Automatic storage stack values and their meanings follow:
1 -- System stack in single level storage.
2 -- User stack in single level storage.
3 -- System stack in teraspace.
4 -- User stack in teraspace.
Technical description . . . . . . . . : Attempt to reduce the automatic storage used by programs running in the thread.
Answer
Message MCH4429 RC2 indicates your application has used up all of the user stack in single level storage. The amount of automatic storage used by all the programs and procedures on the program stack cannot exceed 16 MB.
Some of the things that use automatic storage are as follows:
o Program variables
o Local Temp variables (compiler generated)
o Parameters for procedure calls
o Debugging views
What you are seeing is an application issue. The programs and procedures on the program stack are using up all of the automatic storage available to the job, which is limited to 16MB for single level storage. What is the program doing when it fails? Is it looping with many recursive calls? Does one procedure require a significant amount of automatic storage?
o Program variables
o Local Temp variables (compiler generated)
o Parameters for procedure calls
o Debugging views
What you are seeing is an application issue. The programs and procedures on the program stack are using up all of the automatic storage available to the job, which is limited to 16MB for single level storage. What is the program doing when it fails? Is it looping with many recursive calls? Does one procedure require a significant amount of automatic storage?
When the MCH4229 occurs, the issue with too much automatic storage being used might be caused by a program or procedure earlier in the call stack. For example, if PGMA calls PGMB which calls PGMC, and PGMC attempts to call PGMD, that call to PGMD might fail with MCH4429, but it might be PGMB which requires a significant amount of automatic storage. To see all the programs and procedures on the program stack, use command DSPJOB OPTION(*PGMSTK).
You have the following two options when this is encountered:
You have the following two options when this is encountered:
| 1. | Reduce the amount of automatic storage used by the application. |
| 2. | Switch to STGMDL(*TERASPACE) storage. Chapter 4 of the ILE Concepts manual goes over the different storage models: https://www.ibm.com/docs/en/ssw_ibm_i_76/pdf/sc415606.pdf |
Compiling with the STGMDL(*TERASPACE) option will greatly increase the automatic storage available at run time. It is recommended that all programs in the application be recompiled with this option, rather than just the program experiencing the issue (or called programs can use STGMDL(*INHERIT)
when the caller has STGMDL(*TERASPACE)).
===========================================
Some possible ways to reduce the automatic storage required for calls:
Large parameters passed by value:
When assessing the storage used by the application, here is something to consider. The compiler will allocate storage based on defined calls to procedures when the parameters are passed by VALUE.
The VALUE keyword on the parameter definition tells the procedure to make a copy of the data that it wants to accept as a parameter. The procedure operates on the copy, rather than on the data itself.
The CONST keyword tells the caller to pass the address of the parameter to the procedure. However, the procedure is not allowed to modify the data it refers to in the parameter.
Take this example, the ExecCLCmd procedure has a "large" parameter passed by value:
D ExecCLCmd PR N
D @@Cmd 32702A VALUE
D @@Cmd 32702A VALUE
Passing a 32702-byte parameter by value, requires at least 32702 additional bytes of automatic storage to be generated into the procedure for each call. This automatic storage is required by the called procedure before the procedure is called. Passing parameters in this manner can cause the application to run out of the 16 MB of automatic storage sooner than the user may expect, resulting in the MCH4229 error.
One possible work-around is to change the parameter from VALUE to CONST, since the procedure will not need to generate the extra 32072 bytes of automatic storage for each call:
D ExecCLCmd PR N
D @@Cmd 32702A CONST
D @@Cmd 32702A CONST
If it is not possible to change the actual procedure, since it may have many uses in other current programs, create a wrapper procedure with a CONST parameter.
dcl-proc ExecCLCmd_const;
dcl-pi *n;
Command char(32702) const;
end-pi;
ExecClCmd(Command);
end-proc;
There is a good non-IBM primer to complement this article on Parameter Passing and Performance. Sharing with permission of the author Ted Holt:
dcl-pi *n;
Command char(32702) const;
end-pi;
ExecClCmd(Command);
end-proc;
There is a good non-IBM primer to complement this article on Parameter Passing and Performance. Sharing with permission of the author Ted Holt:
https://www.itjungle.com/2007/06/20/fhg062007-story01/
Large return values:
When you call a procedure that returns a value, the compiler allocates automatic storage to handle the return value, possibly even more than the size of the return value.
To reduce the amount of storage required for large return values, you could
Large return values:
When you call a procedure that returns a value, the compiler allocates automatic storage to handle the return value, possibly even more than the size of the return value.
To reduce the amount of storage required for large return values, you could
- Change the procedure to have an extra output parameter instead of returning a value
- Or if you are using ILE RPG, you could add the RTNPARM keyword to the prototype and procedure interface.
Adding the RTNPARM keyword:
This causes the compiler to add a "secret" extra parameter to handle the return value, and eliminate the actual return value altogether.
You don't need to make any changes to your RPG code after adding the RTNPARM keyword, but if the procedure is exported, you do need to recompile the module that exports the procedure and everything that calls the procedure.
And if you are calling the procedure from another programming language, you will need to change that call to remove the return value and add the extra parameter, coded as the first parameter.
Here is the IBM documentation about the RTNPARM keyword: https://www.ibm.com/docs/en/ssw_ibm_i_76/rzasd/drtnparm.htm
Related Information
[{"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":"6.1.0;7.1.0;7.2.0;7.3.0;7.4.0;7.5.0;7.6.0"}]
Was this topic helpful?
Document Information
Modified date:
16 July 2025
UID
nas8N1021174