Re: Machine interface _MATINVS2

On 06/09/2007, at 1:51 PM, Peter Connell wrote:

I have critical production code which compiles the machine interface
procedure named _MATINVS2.
The reason this MI is used is that it is extremely efficient for the
purpose for which it is used.

This has always worked fine until upgrading to V5R4 where it now throws
a dreaded
Space offset X'40405BEF' or X'0000000000000000' is outside current limit
for job ...................

That's because you have a coding defect. You fail to inform the MI built-in of how much space you have provided for the materialisation. You need to set wInvBytPrv before you pass control to the built-in. As to why this worked on previous releases? Simply luck.

There is IBM doc for the MI procedure named MATINVS but not for MATINVS2
at
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatk/ inst.h
tm

That's because _MATINVS1 and _MATINVS2 are built-ins. They are separate interfaces to the MATINVS MI instruction. The MI instruction is documented in the MI Reference manual and the C function interface is documented in the ILE C/C++ MI LIbrary Reference. You're expected to do the translation between MI instruction description and built-in yourself based on the definition of the prototype in the various QSYSINC/MIH includes.

The ILE C/C++ MI LIbrary Reference mentions the existence of the various built-ins but does not explain the differences between them. You have to work that out for yourself. This manual hasn't been updated since VRM370 and is woefully out of date. It doesn't include many of the currently available MI instructions such as MATINVS. I suspect that is because this manual only documents the function interface and many of the MI instructions are available only as built- ins. That is certainly the case for MATINVS. I am not aware of any external documentation for the various built-ins but I presume some such exists inside IBM.

Strangely, the compiler fails to resolve _MATINVS but it does compile
with _MATINVS1 and _MATINVS2

Not strange at all. _MATINVS does not exist and MATINVS has not been exposed as a function.

_MATINVS1 appears to require a pointer as a 2nd argument

Yes, it expects a System Pointer to the PCO of the job for which you want to materialise the invocation stack.

_MATINVS2 only requires on argument to receive the returned stack info.

Yes, it only works on the current job invocation stack therefore does not need a PCO pointer.

So I've been attempting to use _MATINVS1 but it is throwing a "Pointer
not set for location referenced" error.

I have been unable to get _MATINVS1 to work from RPG or C when passing a NULL second operand. It does work from C when I explicitly pass a resolved pointer to the current process PCO. I have not tried that from RPG yet. Given that I have solved your immediate problem I'll leave that for a later experiment.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------