Re: External Functions in C on z/OS

2023-11-22 Thread Rick Troth
ri, Nov 17, 2023 at 5:32 AM Seymour J Metz wrote: I find REXX extremely useful on PCs, but TSO/E REXX is a backwater compared to ooRexx, and I would be tempted to use Java or Python for complicated TSO scripts. But on z/Linux ooRexx with BSF4REXX is a viable option. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂ

Re: External Functions in C on z/OS

2023-11-22 Thread Rony G. Flatscher
; On Fri, Nov 17, 2023 at 5:32 AM Seymour J Metz wrote: I find REXX extremely useful on PCs, but TSO/E REXX is a backwater compared to ooRexx, and I would be tempted to use Java or Python for complicated TSO scripts. But on z/Linux ooRexx with BSF4REXX is a viable option. -- Shmuel (Seym

Re: External Functions in C on z/OS

2023-11-22 Thread Seymour J Metz
To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS Are you saying that you can call Java from ooRexx? How does that happen? Do you spin-up a JVM running in standby mode? Do you run ooRexx in a JVM? I can call native code from Java, but always have to transit the JNI. Never

Re: External Functions in C on z/OS

2023-11-22 Thread Rick Troth
ttp://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Thursday, November 16, 2023 4:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS I choose a language on capabilities rather than personal p

Re: External Functions in C on z/OS

2023-11-18 Thread Paul Gilmartin
On Sat, 18 Nov 2023 13:27:10 +0800, David Crayford wrote: >... What’s important to note is that their ports use enhanced ASCII and > run in the z/OS UNIX environment so there is very little chance of using > ooRexx to write an edit macro or a TSO/ISPF program. > ISPF can Edit files tagged

Re: External Functions in C on z/OS

2023-11-17 Thread David Crayford
mason.gmu.edu/~smetz3 >>> עַם יִשְׂרָאֵל חַי >>> >>> >>> >>> >>> From: IBM Mainframe Discussion List on behalf >>> of David Crayford >>> Sent: Thursday, November 16, 2023 4:02 PM >

Re: External Functions in C on z/OS

2023-11-17 Thread Rony G. Flatscher
muel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Thursday, November 16, 2023 4:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS I choose

Re: External Functions in C on z/OS

2023-11-16 Thread Seymour J Metz
ל חַי From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Thursday, November 16, 2023 4:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS I don't find ooRexx useful on the PC as it's basically on lif

Re: External Functions in C on z/OS

2023-11-16 Thread Charles Mills
Python seems like a wonderful language. I didn't choose the Rexx language here. The client already had tens of thousands of lines of Rexx code and contracted with me to write a callable function in C++. I did not become a very successful contract programmer by telling clients that if they want

Re: External Functions in C on z/OS

2023-11-16 Thread David Crayford
on behalf > of David Crayford > Sent: Thursday, November 16, 2023 4:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: External Functions in C on z/OS > > I choose a language on capabilities rather than personal preference. I’ve > been accused on this forum by my ex-colleague and

Re: External Functions in C on z/OS

2023-11-16 Thread Seymour J Metz
From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Thursday, November 16, 2023 4:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS I choose a language on capabilities rather than personal preference. I’ve

Re: External Functions in C on z/OS

2023-11-16 Thread David Crayford
I choose a language on capabilities rather than personal preference. I’ve been accused on this forum by my ex-colleague and pal Wayne Bickerdyke of having a pathological dislike of REXX. That’s not true, but I do find it less useful than other languages. Python has a useful library called ctypes

Re: External Functions in C on z/OS

2023-11-16 Thread Paul Gilmartin
On Thu, 16 Nov 2023 16:51:32 +, Farley, Peter wrote: > >Then your Rexx calls would use the least amount of environment setup and >teardown. The down side is you would also need a “terminate” function in the >“front end” to do the needed CEETERM for the LE/C++ environment you set up >which t

Re: External Functions in C on z/OS

2023-11-16 Thread Farley, Peter
Discussion List On Behalf Of Charles Mills Sent: Thursday, November 16, 2023 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS The function not provided by Metal C is basically all of C++. The called module is written in, and exploits, C++. Charles On Wed, 15 Nov

Re: External Functions in C on z/OS

2023-11-16 Thread Charles Mills
The function not provided by Metal C is basically all of C++. The called module is written in, and exploits, C++. Charles On Wed, 15 Nov 2023 21:26:18 +, Farley, Peter wrote: >OK, I sort of understand the “personal preference” about not using inline >assembler (it is kludgey, I agree) a

Re: External Functions in C on z/OS

2023-11-16 Thread Charles Mills
TWO design errors IMHO: XLC should provide a way to get the entry R0. Passing things in R0 is not totally uncommon. Rexx should be passing the environment block using standard linkage. It is passing a standard list of parameters and control blocks as it is. Why put the critical environment blo

Re: External Functions in C on z/OS

2023-11-16 Thread Charles Mills
 Different strokes for different folks. 1. I was not aware of that pointer. This is the classic documentation problem. The answer is right there in the manual, clear as day -- provided you know where to look. A lot of these answers are easy to find, assuming you already know the answer. 2. My

Re: External Functions in C on z/OS

2023-11-16 Thread Charles Mills
It is part of IBM XLC. The program is actually named EDCDSECT. It does a less-than-perfect job but I find it to be an excellent starting point. On Thu, 16 Nov 2023 10:16:54 -0500, Rick Troth wrote: >I remember the DSECT2C command, but might have been from an ISV (maybe ---

Re: External Functions in C on z/OS

2023-11-16 Thread Tom Marchant
y the value of the current R13 to a C >pointer variable, then chain up the DSA stack? > >Peter > >From: IBM Mainframe Discussion List On Behalf Of >Charles Mills >Sent: Wednesday, November 15, 2023 12:39 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: External Function

Re: External Functions in C on z/OS

2023-11-16 Thread Farley, Peter
Thanks for checking, please let us know if they approve or not. Peter From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Thursday, November 16, 2023 12:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS When I first published RTK it was using

Re: External Functions in C on z/OS

2023-11-16 Thread Rick Troth
ain up the DSA stack? Peter From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, November 15, 2023 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS I see, in my C++ projects, EFPL, ENVB, EVALB and SHVB structs that appear to me to ha

Re: External Functions in C on z/OS

2023-11-16 Thread Rick Troth
From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, November 15, 2023 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS @Peter, I went around on the R0 question here a couple of years ago. - No, I don't think there is a reliable

Re: External Functions in C on z/OS

2023-11-16 Thread Peter Relson
David C wrote in /usr/include/zos (there is a PDS/E ... The PDSE is shipped as SYS1.SIEAHDR.H Peter Relson z/OS ore Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@l

Re: External Functions in C on z/OS

2023-11-16 Thread Rony G. Flatscher
On 16.11.2023 02:24, Eric Erickson wrote: First of all thanks to Colin for sending me the headers. Before I went down the path of generating them myself, I want to see what other had experienced trying to do this. I can't use Metal C, as the routines I want to call out of the functions are no

Re: External Functions in C on z/OS

2023-11-15 Thread David Crayford
ctual property issues. > > Peter > > From: IBM Mainframe Discussion List On Behalf > Of David Crayford > Sent: Wednesday, November 15, 2023 9:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: External Functions in C on z/OS > > > My advice is to write a command pr

Re: External Functions in C on z/OS

2023-11-15 Thread Farley, Peter
intellectual property issues. Peter From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Wednesday, November 15, 2023 9:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS My advice is to write a command processor. As I said creating an LE

Re: External Functions in C on z/OS

2023-11-15 Thread Tony Harminc
On Wed, 15 Nov 2023 at 15:03, Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: [...] > In the REXX Ref. I see: > Register 0 > Address of an environment block (optional) > > "optional" should never be specified as a register content. I read that > as: > A

Re: External Functions in C on z/OS

2023-11-15 Thread Farley, Peter
Crayford Sent: Wednesday, November 15, 2023 8:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS There isn’t an R0 issue. IRXINIT(‘FINDENVB’) will fetch the environment block. All of the REXX mapping macros have been converted to C structures and can be found in /usr

Re: External Functions in C on z/OS

2023-11-15 Thread David Crayford
There's a TSO/E vector table that has the address of the REXX routines. // get the address of the TSO/e vector table CVT * cvt = *(( CVT ** ) CVTPTR); TSVT * tsvt = cvt->cvttvt; // IKJTSVT.H - TSO/E Vector Table mapping // // Contains addresses of branch entered routines and control blocks

Re: External Functions in C on z/OS

2023-11-15 Thread Charles Mills
> There isn’t an R0 issue. IRXINIT(‘FINDENVB’) will fetch the environment > block. IIRC I needed the entry R0 to get the address of IRXINIT so I could call it. Charles -- For IBM-MAIN subscribe / signoff / archive access instr

Re: External Functions in C on z/OS

2023-11-15 Thread David Crayford
My advice is to write a command processor. As I said creating an LE environment for each function call will result in terrible performance. I’ve done this many times https://github.com/daveyc/RTK. The trick is to use CEEPIPI to create a pre-initialised LE environment and hang the pointer in USER

Re: External Functions in C on z/OS

2023-11-15 Thread Eric Erickson
First of all thanks to Colin for sending me the headers. Before I went down the path of generating them myself, I want to see what other had experienced trying to do this. I can't use Metal C, as the routines I want to call out of the functions are not supported under Metal C. FWIW, I was lo

Re: External Functions in C on z/OS

2023-11-15 Thread David Crayford
;> At worst, an inline ASM routine to copy the value of the current R13 to a C >> pointer variable, then chain up the DSA stack? >> >> Peter >> >> From: IBM Mainframe Discussion List On Behalf Of >> Charles Mills >> Sent: Wednesday, November 15, 2023 12:39

Re: External Functions in C on z/OS

2023-11-15 Thread Farley, Peter
, November 15, 2023 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS @Peter, I went around on the R0 question here a couple of years ago. - No, I don't think there is a reliable way to get the entry R13 from within the C/C++ code. Obviously, if you could,

Re: External Functions in C on z/OS

2023-11-15 Thread Paul Gilmartin
On Wed, 15 Nov 2023 12:06:48 -0600, Charles Mills wrote: >@Peter, I went around on the R0 question here a couple of years ago. > CMSThink: Since no one uses R0, it's OK for everyone to use it. And the developers who ported REXX to TSO were too unaware to spot the problem and fix it. Or perhaps

Re: External Functions in C on z/OS

2023-11-15 Thread Charles Mills
ovember 15, 2023 12:39 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: External Functions in C on z/OS > > >I see, in my C++ projects, EFPL, ENVB, EVALB and SHVB structs that appear to >me to have been produced from IBM macros by the EDCDSECT tool. > > > >Have you lo

Re: External Functions in C on z/OS

2023-11-15 Thread Farley, Peter
copy the value of the current R13 to a C pointer variable, then chain up the DSA stack? Peter From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, November 15, 2023 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS I see, in my C

Re: External Functions in C on z/OS

2023-11-15 Thread Charles Mills
I see, in my C++ projects, EFPL, ENVB, EVALB and SHVB structs that appear to me to have been produced from IBM macros by the EDCDSECT tool. Have you looked for the IRX macros in SYS1.MACLIB? Are you familiar with EDCDSECT? Slightly changing the subject, to interface with the Rexx environment fr

Re: External Functions in C on z/OS

2023-11-15 Thread Colin Paice
I'll send you an xmit file offline. Ftp to z/OS as bin then use tso receive Colin On Wed, 15 Nov 2023 at 16:57, Eric Erickson wrote: > I've written quite a few callable external functions for Rexx over the > years. On z/OS I've always used assembler as we needed to access system > services fo

External Functions in C on z/OS

2023-11-15 Thread Eric Erickson
I've written quite a few callable external functions for Rexx over the years. On z/OS I've always used assembler as we needed to access system services for a variety of tasks. I've written them in C for other platforms (OS/2 & Windows) over the years. I need to write some on z/OS, but I want to