View previous topic :: View next topic
|
Author |
Message |
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Sorry, but I cannot find any explanation from available sources.
When already tested REXX code has been successfully compiled using REXXTOOLS RXTCOMP compiler, and then a binary load module created, it fails at run time when trying to call any TSO function, like OUTTRAP or whatever:
Quote: |
212 +++ X=OUTTRAP("RES.")
IRX0043I Error running TESTMOD1, line 212: Routine not found |
Kindly give me a clue where the external TSO functions (or any other external functions?) must be defined to be used with load module created from a compiled REXX code? |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2545 Location: Silicon Valley
|
|
|
|
What environment are you running it on?
If it is a batch job, remember that you still need to provide a TSO environment. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
I do not know about the REXXTOOLS compiler
but the IBM REXX compiler is very sensitive to the STUB linked into the executable
Using the wrong STUB would usually result in an odd behavior |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
After long investigation I was able to find the answer as fine print in the Open Software Inc. manual
Quote: |
Note: If your compiled REXX program utilizes any TSO service, you must run it under IKJEFT01 (the batch TMP). |
|
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2545 Location: Silicon Valley
|
|
|
|
repeating:
Quote: |
remember that you still need to provide a TSO environment. |
That is, not sure you need a long investigation. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Pedro wrote: |
repeating:
Quote: |
remember that you still need to provide a TSO environment. |
That is, not sure you need a long investigation. |
0) This requirement might be interpreted as "ADDRESS TSO" which could be executed in compiled version, but did not help to access TSO services.
1) Then, WTF compiled REXX version is needed? The widely used standard REXX instruments unpredictably do not run from successfully(!) compiled REXX (and linked load module).
2) Despite of what manual says, the compiled REXX just fails with S0C4 when started via IKJEFT01, as recommended by manual...
So, finally even "long investigation" did not help so far |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
What did the vendor say when you asked your question there? |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Robert Sample wrote: |
What did the vendor say when you asked your question there? |
I am subcontractor, and not supposed to contact the vendor directly.
After some investigation I was able to find the reason. The client's Endevor team provided so called "processor group" to "automatically perform REXX compilation, and link edit the load module". Noone of that support group was able to clarify any minor question.
Further investigation discovered that the "standard processor group" for REXX compilation has internal hardcoded REXX compiler option PREFIX(RXTRXPRC), the one compatible with... calling REXX from COBOL only! The created object/load modules became incompatible with calls from JCL/TSO/Assembler etc.
The Endevor team has been notified of their own problem. So far I use my own JCL to perform REXX compilation. Now it's working as described.
Thank you |
|
Back to top |
|
|
|