Re: Convert an MI program to RPG

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Bill,

You wrote:
>Then I am really confused.  From your explanation, it sounds as if you are
>saying that the combination of the object type and object name are the
>second parameter.  But this is not how you coded the function, nor how it
>was prototyped.  The hex representation of the object type is in parameter 1
>and the object name is in parameter 2.  If they are both in parameter 2,
>what is in parm1?


You are confusing the rslvsp() C function -- which is what the RPG IV program 
is using 
-- and the rslvsp MI instruction which is what eventually gets executed by said 
function.

The C function takes four parameters:
        1/ BIN(4)       Object type
        2/ CHAR(31)     NULL-terminated object name (really a pointer to a C 
string)
        3/ CHAR(31)     NULL-terminated object library name (pointer to a C 
string)
        4/ BIN(4)       Authorisation
and returns a system pointer

The MI instruction also takes four parameters (but they are different from the 
function)
        1/ System pointer - set by the instruction to address the named object
        2/ Name structure - This is the one that causes the MCH5003
        3/ System pointer - pointer to the library containing the named object 
or NULL
        4/ Auth - Auth to set in the pointer, NOT repeat NOT the same as the 
Auth in the 
C function.  This parameter cannot be used by user-state programs.

The MCH5003 message is sent by the rslvsp MI INSTRUCTION, not the function.

The C function takes the four parameters and massages them so they fit the form 
required 
by the MI instruction, it invokes the MI instruction, and then returns whatever 
value is 
in parameter 1.

The DUMP would indicate that the variables are set correctly but if you are 
still 
getting the same MCH5003 then your problem is still with the layout of operand 
2 of the 
MI instruction.  It may be related to the position of the null terminator as 
Leif 
suggested but I don't think so. What you see in the DUMP is the RPG view of a 
NULL 
terminated string. The C function should be sorting that out and converting 
from 
D8E4C5D9E8D3C9C200 to 
D8E4C5D9E8D3C9C24040404040404040404040404040404040404040404040.  
You can try Gene's suggestion to put the NULL in byte 31 but I don't believe 
that is 
necessary.  The C function accepts a NULL terminated string with a maximum 
length of 30 
bytes (plus NULL).  It doesn't REQUIRE the NULL in byte 31.  As I said earlier, 
that 
code works here on 440.  OPTIONS(*STRING) just avoids you having to 
NULL-terminate the 
string manually.


>This is from the MI Reference manual:  _SYSPTR rslvsp (_OBJ_TYPE_T obj_type,
>_OBJ_NAME obj_name,   _LIB_NAME lib_name,              _REQ_AUTH auth);

>This clearly shows type and name as seperate parms.  What am I missing?

Because that is the reference manual for the C function NOT repeat NOT the MI 
instruction.  You also need the MI Functional Reference (SC41-4810).

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---