Steve, RPG and C likely don't use the builtin function numbers; instead, the front ends pass a builtin name (e.g. '_LBCPYNV') through w-code to the common back end, which likely looks up a table and converts builtin names to builtin numbers and puts that into NMI. The NMI translator down in SLIC likely uses builtin numbers to look up a table to determine code generatation. You'll find this mailing list archive has a REXX program PRTBUILTIN that prints the builtin names and numbers. It will work on V5R1 and earlier. "Builtin function" doesn't imply "inline function". If you dump a process control space with System Service Tools, you'll see SLIC run-time routines for builtin functions in between HLL program/procedure entries on the call stack. Many builtin functions run on the call stack. For some reason, I don't know why, the MATINVS MI instruction receiver variable only lists the call stack entries for HLL program/procedures, and omits references to the SLIC run-time routines for builtin functions on the call stack. Perhaps, IBM doesn't want SLIC to be observable to the MATINVS user. If you want to inline a user procedure, C has a "#pragma inline" thing. Perhaps IBM could make it work in RPG, too, like on a D-spec: OPTIONS (*INLINE). When your builtin function prototype in RPG or C is incorrect (and that's any builtin function, not just the _LBCPYNV that you observered), the error you observe during a compile really starts down in the NMI translator in SLIC with MCH4227, "Instruction stream not valid." Read the help text in your job log for MCH4227 carefully and see the reason code, then look up that reason code under MCH4227 in the online MI reference manual, and that will give you a (sort of) clue as to your prototype error. For example, if the reason code is 14, meaning "the MI value stack has fewer items on it than need to be popped," then your prototype is missing a parameter. Ugly, I know, I wish the RPG and C front ends would validate our builtin function prototypes, but they don't.