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.




This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].