Re: MCH1210 error in QGYOLSPL api

On 02-Dec-2011 09:25 , mgarrison@xxxxxxxxxx wrote:

I have the following program (subset of the actual program but this
will compile for demonstration purposes) using the QGYOLSPL api to
retrieve a list of the spool files on our systems. When I run the
program it is crashing with escape error message MCH1210 Receiver
value too small to hold result which is not listed in the
documentation for the QGYOLSPL api. We are at v6r1.

The specifics of the error msgMCH1210 [e.g. from the spooled joblog or f6=print; or maybe the dump and QPDSPJOB if produced] were omitted. Nobody can know with accuracy, what describes the failure, without that information. If the error was in the user program, then of course the API would not be reporting that condition. Since the invocation specifies an [apparently valid] error code parameter, no errors should be signaled from the API to the user program; more likely the error is in the user program, where the API has no control.

Does anyone have any thoughts as to why I am receiving the error
message?

An overflow on an assignment to a numeric variable is the most likely origin :-) Thus if for example, the API were told to write a numeric value into an signed n-byte integer variable, but the API documentation requires that the receiver variable should be an unsigned n-byte integer, then half of the possible values would effect an overflow.

I have tried numerous things including copying from posted
on the net and without success I am now definitely into the WAG
stage.

Review of the full details of the MCH1210 might be helpful to enable a transition from a WAG toward a SWAG.

From an old discussion found on the web, and an old APAR, the likely origin is incorrect filtering; either by specification to the API, or by the program which performs the filtering for the API, such that the actual number of spooled files returned greatly exceeds what should have been included by the selection.?

With mention of filtering, a cursory review of the code <<snipped from this reply>> shows the third parameter [which is OUTPUT] is using the same uninitialized DS as the sixth parameter [which is INPUT] for the filtering. Using the same storage for both an input and an output parameter is by itself, very likely to lead to catastrophic errors. Thus that is very likely that is the cause of the problem, and very possibly causing the API to fail long before the API has even been able to setup error code processing to inform by error code versus error message.

Regards, Chuck