×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 13-Nov-2013 14:08 -0800, John McKee wrote:
I think I've seen this on MIDRANGE before. Tried searching but found
lots of other hits.
The msg MCH3402 is a *very generic* condition. Knowing that message
ID is like your mechanic knowing your car makes a /banging/ noise, but
nothing else; i.e. hardly sufficient for the mechanic to diagnose the
origin of the noise issue.
Is this a rehash of?:
http://archive.midrange.com/rpg400-l/201306/msg00076.html
I wrote an RPGLE program. A function is used in a service program.
When all data has been processed, *INLR is set on.
And that /function/ would be activated in *CALLER, *NEW, or a named
activation? And the ACTGRP of the RPGLE program?
Run the program and it works. Run a second time, and MCH3402 is
received. Sign off and back on, and program works fine again.
The generic condition needs some /context/ so as to identify what is
the failure other than knowing that a "reference was made to a pointer
to a destroyed object"
Do I need to change program to include something to get rid of the
error?
Something should probably be changed, to ensure the proper operation
on a second invocation without an error. Undiagnosed problems are an
undesirable /loose end/ that may be an indication of a bigger issue that
needs to be resolved.
This is more of a curiosity question, as program likely won't be run
very often - and won't be run by anybody else.
And resolving unexpected errors is probably worthwhile to ensure
whatever is unexpected in that scenario, is not also possible to cause
the same or even different errors in a different scenario... with the
same origin. For example if the function in a named activation is
getting the error, then another invoker of that same function would be
expected to get the same error.
Something about activation group is in my mind.
Often the origin is that the RPGLE was compiled and runs in the
*DFTACTGRP, and the Service Program is defined with ACTGRP(*CALLER), and
that function in the service program opens a file that gets closed by
a[n implicit] RCLRSC. Because the default activation group can not be
reclaimed via RCLACTGRP, a signoff\signon circumvents the issue.
http://archive.midrange.com/rpg400-l/200512/msg00779.html
Just curious why it popped up.
Get a spooled joblog with the MCH3402, showing the preceding request
message and the following RPG [inquiry] message or the next request
message if nothing follows the MCH3402. The spooled joblog shows the
/context/ for the failure. Something that can only be guessed, without
some solid details.
midrange.com
