On Tue, Aug 19, 2014 at 3:28 PM, Donald Likens <[email protected]>
wrote:
> I have been looking at the LE documentation now for days and still not
> sure what I need to do to have my Assembler program call C or C++ programs.
> I need this interface to be very efficient because I will be calling these
> subroutines maybe more than a 1,000,000 times a day. What I have come up
> with is to use CEEPIPI to build the environment.
>
> LA R5,PPTBL GET ADDRESS OF PIPI TABLE
> ST R5,@CEXPTBL CEEXPTBL-ADDR -> PIPI TABLE
> L R15,PPRTNPTR GET ADDRESS OF CEEPIPI ROUTINE
> * INVOKE CEEPIPI ROUTINE
> CALL (15),(INITSUB,@CEXPTBL,@SRVRTNS,RUNTMOPT,TOKEN)
>
> I will have three subroutines so I think I need to put each one of these
> routines in the preinit table.
>
> Now I think I need to use CEEPIPI again when I want to call each
> subroutine.
>
> ST R11,PARM
> L R15,PPRTNPTR GET ADDRESS OF CEEPIPI ROUTINE
> CALL (15),(CALLSUB,PTBINDEX,TOKEN,PARM, X
> SUBRETC,SUBRSNC,SUBFBC) INVOKE CEEPIPI ROUTINE
>
> Note:
> Note: The C routines have not been created yet, so I can't try these
> things out.
>
> Questions:
> 1) Do I have it correct?
> 2) Do I even need LE?
3) The book talks about XPLINK. I don't quite understand it. Is this
> something I should explore more?
>
I call C (not C++) subroutines from HLASM. But I do it by making my HLASM
LE compliant from the start. I see no reason not to. My start up code looks
like:
PRINT GEN
MNOTE *,'SYSOPT_OPTABLE=&SYSOPT_OPTABLE'
SYSSTATE ASCENV=P,
AMODE64=NO,
ARCHLVL=2
IEABRCX DEFINE
IEABRCX DISABLE
IEABRCX ENABLE
_BALR OPSYN BALR
BALR OPSYN BASR
_CSECT OPSYN CSECT
CSECT OPSYN RSECT
POP PRINT
LSENQ CEEENTRY PPA=LSENQ_PPA,
MAIN=YES,
AUTO=DSASIZE,
BASE=R11_32
USING CEECAA,R12_32
USING CEEDSA,R13_32
J GO
GOBACK DS 0H
CEETERM RC=RETURN_CODE,
MODIFIER=MODIFIER,
MF=(E,CEETERM_BLOCK)
LTORG
GO DS 0H
* code goes here
LSENQ_PPA CEEPPA LIBRARY=NO,
PPA2=YES,
EXTPROC=YES,
TSTAMP=YES,
PEP=YES,
INSTOP=YES,
EXITDSA=NO,
OWNEXM=YES,
EPNAME=LSENQ,
VER=1,
REL=1,
MOD=0,
DSA=YES
CEEDSA
* DYNAMIC AREA IS DEFINED HERE.
* THIS MUST BE INITIALIZED DURING EXECUTION.
* THIS IS WITHIN A DSECT, SO NO DATA IS REALLY INITIALIZED
DS 0D FORCE DOUBLEWORD
... data areas
RETURN_CODE DS F
MODIFIER DS F
RETURN_VALUE DC A(0) PREVIOUS DEFAULT DUB
REASON_CODE DC A(0)
CEETERM_BLOCK CEETERM MF=L
DSASIZE EQU *-CEEDSA
CEECAA
END LSENQ
The code above can call the C language subroutines, such as SPRINTF(), as
well as user written C code. I have never looked at using XPLINK or C++, so
I can't say anything about calling that type of code. Note that the above
can still use all the normal z/OS macros that non-LE code can use. And it
can call non-LE routines, both system, vendor, and user supplied. In
particular, I use the above to write z/OS UNIX programs. In my programs, I
use C subroutines as well as a number of the UNIX callable services
(BPX????? routines) as well as z/OS services such as ISGENQ and others.
However, in many cases, I try to use LE service routines instead of native
z/OS services. Especially to get dynamic storage. I don't use STORAGE
OBTAIN / RELEASE or GETMAIN / FREEMAIN and use CEEGTST / CEEFRST to get
storage in the LE maintained "heaps". But this is just my preference so
that the LE formatter knows about them.
--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
