Re: API QSPROUTQ - not returning correct results

On 25-Feb-2015 09:41 -0600, Dan Rasch wrote:

We are seeing a problem with the QSPROUTQ API, which has the
following details:

<<SNIP>> Length of receiver variable Input Binary(4) <<SNIP>>

the DS looks like this:

D OUTQ0200 DS
D O2BytRtn 10i 0
D O2BytAvl 10i 0
D O2OutQnam 10a
D O2OutQlib 10a
D O2FilOrd 10a
D O2DspAnyF 10a
D O2JobSep 10i 0
D O2OprCtl 10a
D O2DtaQnam 10a
D O2DtaQlib 10a
D O2AutChk 10a
D O2NbrF 10i 0

We are getting 1's in the O2NbrF field for printers that have
nothing in the OUTQ.
But only on 6 of the 50+ printers we select.

Is anyone familiar with this API, or a known problem?

What release is being used? Possibly moot, as a web search of that API name with the symptom keyword for /incorrect output/ yielded no hits; given my low expectations for documentation of APARs with proper symptom keywords, maybe the release could be important, but certainly a failure by IBM to properly document an issue would make that information less useful in attempts at locating an APAR.

How was the variable for the _Length of receiver variable_ declared and what was the value passed to the API for that as second argument on the API invocations that did not provide expected output?

What does "getting 1's" mean? Perhaps show what the following debug requests yield:
Eval O2NbrF : x
Eval O2NbrF : x

What is the result of O2BytRtn and O2BytAvl on the invocations that yield unexpected output? If (O2BytRtn<95) then the value of O2NbrF must be ignored.

How was the error code declared and what was the result in the requests not providing expected output? Like the number of bytes returned must be appropriate before referring to the data in the return variable, so too must the result in the error code be appropriate before referring to the data in the return variable.