IBM Mainframe Forum

I've got a REXX external function coded in assembler, which I'm using successfully from REXX. Is it possible to call it from a Cobol program as well and how would that look like? Thanks!

REXX external function has a very specific meaning
do You realize that the parameter passing conventions are completely different from the standard?

start here
http://publibz.boulder.ibm.com/cgi-bin/ ... s/IKJ4BK90
and proceed to
http://publibz.boulder.ibm.com/cgi-bin/ ... 0626210253
and to
http://publibz.boulder.ibm.com/cgi-bin/ ... T#FIRSTHIT
to arrive here for the details
http://publibz.boulder.ibm.com/cgi-bin/ ... 0253&CASE=

enrico-sorichetti wrote:REXX external function has a very specific meaning
do You realize that the parameter passing conventions are completely different from the standard?

Yes, that's why I'm asking if it would be doable at all. Including retrieving the return value?

Is your Assembler program Language Environment "compilant"? If so, it might be possible. Make a cut-down version which does something noticeable when called, and try it, by setting up a table of address/lengths and then calling with the table. A return value should be possible as well. The manual shows how to call C functions, and if it is similar-enough there is a chance.

However, if not LE compliant, go whistle.

LE compliancy does not make any difference ....
rexx external function has a specific meaning as far as the execution environment and parameter passing are concerned ...
for example when using retcode = function(....)
the return code is not passed using reg 15 it is passed using the REXX evalblock...
( a non zero r15 will result in REXX issuing the message Incorrect call to routine

and... and... and...

If not LE compliant, won't (probably) work from (LE Compliant) Cobol.

If the rexx external function requires a specific execution environment, that would be an issue.

Cobol can call a C/C++ function, doesn't use the R15 return-code (has a tucked-away piece of storage you can specify).

Looking at the parameter set-up and the ability to receive the return-value from a "function call", it could be "possible". Either or both of the two "environment" things could kill the possibility.

and... and... and... certainly. I haven't done it, so I don't know what lurks. Don't have TS's assembler mini-version.

Does the usage have to be a "rexx external function"? Can't the rexx just use a module which is OK for the Cobol program to call? Maybe not "cool" enough.

Could one call the function from a rexx snippet called from the cobol program? Wouldn't try it in production though!

Does the usage have to be a "rexx external function"?

if the <function> has been written as a rexx external function that' s it

Can't the rexx just use a module which is OK for the Cobol program to call?

if the <thing> has already been written, it must be REwritten as a <standard> callable <object>

REXX variables are variable-length strings and REXX takes care of everything,
as seen here http://publibz.boulder.ibm.com/cgi-bin/ ... 0253&CASE=
where rexx takes care of all the length issues
values can be passed back to the calling REXX
1 - using rexx SHV interface for REXX under TSO or IRXJCL
2 - using IKJCT441 ( TSO generic variable access routine ) for REXX under TSO
- both methods have pros/cons
1 - valid only for REXX scripts
2 - allows to share variables with CLISTS

using the Address <environment> facility any assembler subroutine can be called from REXX ( see IGGCSI00 )
but then all the variable handling is less than automated ( the user must provide for fixed/variable length issues )

Maybe not "cool" enough.

coolness does not make any difference, it is just impractical

Could one call the function from a rexx snippet called from the cobol program?

but then there would be the issue of passing back to COBOL the results
COBOL/REXX is kind of unidirectional, things can be passed to REXX, not back

I think we are going round in circles and digging ourselves in deeper, somehow.

Cobol can build the parameter block like that. On the Call, the RETURNING phrase could be used to receive the function value into a data-item defined in the Cobol programl.

If the parameter-block/return value would be the same for calling rexx, then that is good. I've been told calling rexx from Cobol is possible.

As for further two-communication between Cobol/rexx the address/length gives the option of changing the data at that address, doesn't it?

I may be missing something "obvious" because I haven't done any of this. From the manual I can't see the problem with these parts.

The "evironment" stuff can turn out to be a different thing entirely. Parameters/communication/return-value should work. Not with a "vanilla" CALL, but nothing too complex or obscure.

Without the assembler snippet I can't test it

enrico-sorichetti wrote:

Does the usage have to be a "rexx external function"?

if the <function> has been written as a rexx external function that' s it

Yes, it does already exist and is working fine (from rexx).

enrico-sorichetti wrote:

Can't the rexx just use a module which is OK for the Cobol program to call?

if the <thing> has already been written, it must be REwritten as a <standard> callable <object>

Creating a second version for Cobol would of course be an option, but unfortunately it's probably beyond my capabilities...

enrico-sorichetti wrote:REXX variables are variable-length strings and REXX takes care of everything,
as seen here http://publibz.boulder.ibm.com/cgi-bin/ ... 0253&CASE=
where rexx takes care of all the length issues
values can be passed back to the calling REXX
1 - using rexx SHV interface for REXX under TSO or IRXJCL
2 - using IKJCT441 ( TSO generic variable access routine ) for REXX under TSO
- both methods have pros/cons
1 - valid only for REXX scripts
2 - allows to share variables with CLISTS

As far as I can see evalblock and SHV is used.

enrico-sorichetti wrote:

Could one call the function from a rexx snippet called from the cobol program?

but then there would be the issue of passing back to COBOL the results
COBOL/REXX is kind of unidirectional, things can be passed to REXX, not back

And this would probably be very slow as well.