Re: External Functions in C on z/OS

[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 
not supported under Metal C.

FWIW, I was looking at creating a Rexx Function to retrieve a record from a 
EZNOSQL Database and return it in the Rexx Variable for use. IBM has C/Java 
APIs for EZNOSQL, but not Rexx at this time. There is an idea logged to create 
it, but its marked as future consideration, so no telling when (or if) it will 
appear.


It is interesting to learn this problem (C/C++ being slow for creating external Rexx functions in 
C/C++ due to LE). It seems that the C/Java combination does not have that problem? If so, then one 
possibility would be to have a port of ooRexx and BSF4ooRexx850 (Rexx-Java-bridge) which makes all 
of Java available but in the clothes of Rexx to exploit Java directly! Creating external Rexx 
function and ooRexx method packages is easy and straight forward.


For Linux on IBM Z mainframes there have been mainframe users who use ooRexx and BSF4ooRexx850 for 
interfacing with DB2 from their Rexx programs. ooRexx is open source and straight forward to compile 
for Linux on IBM Z, the same for BSF4ooRexx850.


Actually there is a s390x port of  ooRexx from 
, and BSF4ooRexx850 from 
 includes a s390x port in its 
installation zip-archive for that very purpose! This allows to immediately use ooRexx on mainframes 
and with the ooRexx-Java bridge to allow to use all of Java as it was ooRexx, *quite* easy and 
powerful!


A Rexx programmer can exploit all of what is available on Linux on IBM Z mainframes. One can 
interact with any Java class/object to use anything Java makes available (and having even callbacks 
from Java to Rexx out of the box)! So, anything IBM and others make available via Java can be used 
from Rexx.


So if Linux on IBM Z is an option you could immediately check out that powerful combination and 
leverage your Rexx skills to exploit all Java classes without a need to learn the Java programming 
language.


Also, you could use this infrastructure on your Windows, macOS and Linux machines as Java makes the 
developed solutions portable! With other wordks, you can develop Rexx apps exploiting Java e.g. on 
Windows, then run the Rexx app on Windows, but also run it unchanged on macOS or Linux, even on 
Linux on IBM Z mainframes!


---rony

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OSA-ICC Connection Question

[Radoslaw Skorupka]

W dniu 16.11.2023 o 01:47, Michael Babcock pisze:

We have an OSA-ICC connection set up as a 3270 session type.   The LU Name
in that definition is TERM140.  The CUA is B400.We have a 3270 session
defined with the proper IP and the same LU Name of TERM140.This all
works as expected.  My question is that I thought a VTAM APPL with an
LUNAME of TERM140 was required but I do not see a TERM140 defined in VTAM
at all.   I’m not a network guy.   Since this is working, I assume it’s not
required.   Can someone enlighten me?


In simple words, LUNAME used in OSA-ICC session definition and emulator 
- it does NOT exist in any VTAM or TCPIP configuration.
Instead, VTAM use device number (devnum), which is in turn not used in 
emulator session. However OSA-ICC session ties devnum with LUNAME. Note: 
the same devnum can be used by different LPARs and every LPAR has its 
own console/terminal. It is not shared, just "duplicate" devnum. However 
OSA-ICC use devum *and* MIF and CSS to uniquely identify the device.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rexx to clone users in RACF

[Radoslaw Skorupka]

W dniu 16.11.2023 o 05:04, Peter pisze:

Hello

I am looking for a rexx logic which can multiple RACFID based on one model
user ?

Does anyone have any sample rexx code or any logic that you can share with
me?


Hint: use template.
Just create some member with all definitions needed to create a user. 
Then CHANGE USER1 USER2.

If you really need it "automated" then use REXX/ISPF edit features.

BTW: Think about security model. Vast majority of RACF users should have 
authorities coming from group membership. Such approach allows very easy 
addition/deletion of users.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there

[Michael Babcock]

Bring up a one pack rescue system that can get to the same PARMLIB and
change it.

On Thu, Nov 16, 2023 at 12:54 AM Laurence Chiu  wrote:

> It was gold for me and will help me settle a dispute with some local
> sysprogs who said there would be no problem. My question is, it says if you
> don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the
> problem occurs, how do you get online to change it? I could not find an
> operator command to change it and since the system is able to IPL,
> you can't logon to change it.
>
> On Thu, Nov 16, 2023 at 4:18 PM kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Awesome, how do we even find such gems with TechDocs being what it is...
> > Luckily for this one, I seem to have it bookmarked.
> >
> >
> > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi <
> > fogar...@gmail.com> wrote:
> >
> >
> > > Answered a decade ago including how to continue the IPL and get running
> > > (either single system or sysplex without CF)
> > >
> >
> https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf
> > > "The paper is being written to provide clear and concise instructions
> on
> > > how to address the sysplex support team’s most common callout. Where is
> > My
> > > Coupling Facility?"
> > >
> > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs <
> > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a
> > > > X'0A3' wait state.
> > > >
> > > > Mark Jacobs
> > > >
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > >
> > > > GPG Public Key -
> > > >
> >
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > > >
> > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu <
> > > > lch...@gmail.com> wrote:
> > > >
> > > > > Thinking about a LPAR defined as being in a parallel sysplex with
> > > > > GRS=STAR.
> > > > >
> > > > > What happens if you IPL that LPAR and the CF is not active? Will it
> > > > > start,
> > > > > issue a WTOR or just fail? We are wondering what would happen if
> our
> > LPAR
> > > > > was started at the DR site (off a replicated set of volumes) but
> the
> > DR
> > > > > CEC
> > > > > did not have a CF defined. Thanks
> > > > >
> > > > >
> > --
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there

[Mark Jacobs]

You can change the Load Parameter in the activation profile to have z/OS Prompt 
for System Parameters Response and then specify GRS=NONE/TRYJOIN there.

Mark Jacobs  


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


On Thursday, November 16th, 2023 at 1:53 AM, Laurence Chiu  
wrote:


> It was gold for me and will help me settle a dispute with some local
> sysprogs who said there would be no problem. My question is, it says if you
> don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the
> problem occurs, how do you get online to change it? I could not find an
> operator command to change it and since the system is able to IPL,
> you can't logon to change it.
> 
> On Thu, Nov 16, 2023 at 4:18 PM kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Awesome, how do we even find such gems with TechDocs being what it is...
> > Luckily for this one, I seem to have it bookmarked.
> > 
> > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi <
> > fogar...@gmail.com> wrote:
> > 
> > > Answered a decade ago including how to continue the IPL and get running
> > > (either single system or sysplex without CF)
> > 
> > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf
> > 
> > > "The paper is being written to provide clear and concise instructions on
> > > how to address the sysplex support team’s most common callout. Where is
> > > My
> > > Coupling Facility?"
> > > 
> > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs <
> > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > > 
> > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a
> > > > X'0A3' wait state.
> > > > 
> > > > Mark Jacobs
> > > > 
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > 
> > > > GPG Public Key -
> > 
> > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > 
> > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu <
> > > > lch...@gmail.com> wrote:
> > > > 
> > > > > Thinking about a LPAR defined as being in a parallel sysplex with
> > > > > GRS=STAR.
> > > > > 
> > > > > What happens if you IPL that LPAR and the CF is not active? Will it
> > > > > start,
> > > > > issue a WTOR or just fail? We are wondering what would happen if our
> > > > > LPAR
> > > > > was started at the DR site (off a replicated set of volumes) but the
> > > > > DR
> > > > > CEC
> > > > > did not have a CF defined. Thanks
> > 
> > --
> > 
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > > > > IBM-MAIN
> > > > 
> > > > --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > 
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there

[Jay Maynard]

Can you specify it at IPL time by replying to the IEA101A SPECIFY SYSTEM
PARAMETERS message? You would need an IEASYSxx that has the necessary
parameter to issue the prompt in it set up beforehand.

On Thu, Nov 16, 2023 at 12:54 AM Laurence Chiu  wrote:

> It was gold for me and will help me settle a dispute with some local
> sysprogs who said there would be no problem. My question is, it says if you
> don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the
> problem occurs, how do you get online to change it? I could not find an
> operator command to change it and since the system is able to IPL,
> you can't logon to change it.
>
> On Thu, Nov 16, 2023 at 4:18 PM kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Awesome, how do we even find such gems with TechDocs being what it is...
> > Luckily for this one, I seem to have it bookmarked.
> >
> >
> > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi <
> > fogar...@gmail.com> wrote:
> >
> >
> > > Answered a decade ago including how to continue the IPL and get running
> > > (either single system or sysplex without CF)
> > >
> >
> https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf
> > > "The paper is being written to provide clear and concise instructions
> on
> > > how to address the sysplex support team’s most common callout. Where is
> > My
> > > Coupling Facility?"
> > >
> > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs <
> > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a
> > > > X'0A3' wait state.
> > > >
> > > > Mark Jacobs
> > > >
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > >
> > > > GPG Public Key -
> > > >
> >
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > > >
> > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu <
> > > > lch...@gmail.com> wrote:
> > > >
> > > > > Thinking about a LPAR defined as being in a parallel sysplex with
> > > > > GRS=STAR.
> > > > >
> > > > > What happens if you IPL that LPAR and the CF is not active? Will it
> > > > > start,
> > > > > issue a WTOR or just fail? We are wondering what would happen if
> our
> > LPAR
> > > > > was started at the DR site (off a replicated set of volumes) but
> the
> > DR
> > > > > CEC
> > > > > did not have a CF defined. Thanks
> > > > >
> > > > >
> > --
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lessons Learned - Mass Extended Format DS Conversion - ZOS 2.5

[Radoslaw Skorupka]

W dniu 15.11.2023 o 13:13, Steve Estle pisze:

All,

We are in the midst of rolling out pervasive encryption in our ZOS 2.5 customer 
environment.  To get there of course we need to move to extended format 
datasets (sequential, VSAM, etc) which we have minimal exposure / experience 
with today (We have multiple  100K's of datasets in our catalogs across 4 
LPAR's.  We also will be leveraging hardware compression (ZEDC) as we migrate 
things as well towards path to pervasive encryption (PV) of course following 
best practice to compress before encrypting.

Have reviewed redbooks on PV, extended format, and hardware compression 
(experiences with hardware compression so far have been outstanding - 
especially in our DFDSS backup processing).

What I'm looking for are any gotchas / lessons learned / real life experiences 
in embarking on this mass migration from basic format datasets over to extended 
compressed format DSN's and encryption that aren't documented in standard doc 
or redbooks.  Or maybe you ran across or developed some tools to aid in such 
large scale migrations?

If you have anything you'd like to share feel free to share it here or if 
prefer to talk offline contact me  atsest...@gmail.com.

Thanks in advance for sharing.


My experience: nothing changed. Except from CPU, elapsed time 
(non-significant IMHO) changes.
Of course you can find find/detect some application using non-standard 
method for I/O and then you would be tied to non-Extended format.
And this is my advice: if you want to feel safe then start from basic -> 
Extended Format conversion. With no encryption and even no compression. 
Then nobody would say "it is because of encryption".
Later convert EF datasets to use PV and compression. Obviously *use* 
compression when using PV.
And take care about keys. Backup your CKDS. Have a procedure for Master 
Key.



--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OSA-ICC Connection Question

[Michael Babcock]

Perhaps it would be better if I explain what we have.   We use the BMC 
suite of products including the Terminal Address Space (an alternate 
access method I think they call it).  Within TAS, there is a LOGON 
UCB(B400) parameter.  The B400 corresponds to the OSA-ICC definition.  
We have a Visara 500LX box that contains a 3270 session with the same 
LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a 
LBUILD for B400 CUADDR anywhere in VTAM.  I expected to see one however. 
   I assume then that the TAS is doing something under the covers and 
as such VTAM doesn't need an LBUILD for B400.  We do have LBUILDs for 
other B4xx addresses (but they don't use TAS, they are for TSO).


On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote:

W dniu 16.11.2023 o 01:47, Michael Babcock pisze:
We have an OSA-ICC connection set up as a 3270 session type.   The LU 
Name
in that definition is TERM140.  The CUA is B400.    We have a 3270 
session

defined with the proper IP and the same LU Name of TERM140. This all
works as expected.  My question is that I thought a VTAM APPL with an
LUNAME of TERM140 was required but I do not see a TERM140 defined in 
VTAM
at all.   I’m not a network guy.   Since this is working, I assume 
it’s not

required.   Can someone enlighten me?


In simple words, LUNAME used in OSA-ICC session definition and 
emulator - it does NOT exist in any VTAM or TCPIP configuration.
Instead, VTAM use device number (devnum), which is in turn not used in 
emulator session. However OSA-ICC session ties devnum with LUNAME. 
Note: the same devnum can be used by different LPARs and every LPAR 
has its own console/terminal. It is not shared, just "duplicate" 
devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely 
identify the device.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: The JES2 NJE node that cannot die.

[Tom Longfellow]

Nice idea.  The only CONNECT statements I have are for NJE over IP.I am not 
sure how to apply this to an SNA connection.
I

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: The JES2 NJE node that cannot die.

[Tom Longfellow]

Thanks,   While that might shutdown the node,  My eventual goal to is remove it 
entirely.   I am trying to do it in stages.  First, deactivate it.  Wait.  Then 
Remove it.
I see no need to apply external solutions (RACF) to the procedure.
My experience and monitoring tells me that this node is already completely 
unused.   I am just trying to build a quickly reversable deactivation to cover 
myself  just in case.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OSA-ICC Connection Question

[Jay Maynard]

Yes, TAS is doing something under the covers. Since you're giving it a
device number to talk to the OSA-ICC device, that means that device is not
owned by VTAM at all, at any time; instead, TAS is talking to it directly
using channel programming like it's a channel-attached, non-SNA 3270
terminal. Under those circumstances, there's no need tor an LBUILD/LU
combination for that device, since VTAM's not talking to it. Instead,
there's an LU definition in VTAM for TAS to pass the device through to
VTAM, and that LU (which need not be the same one for every session) is
what communicates with VTAM applications like TSO.

On Thu, Nov 16, 2023 at 8:53 AM Michael Babcock 
wrote:

> Perhaps it would be better if I explain what we have.   We use the BMC
> suite of products including the Terminal Address Space (an alternate
> access method I think they call it).  Within TAS, there is a LOGON
> UCB(B400) parameter.  The B400 corresponds to the OSA-ICC definition.
> We have a Visara 500LX box that contains a 3270 session with the same
> LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a
> LBUILD for B400 CUADDR anywhere in VTAM.  I expected to see one however.
> I assume then that the TAS is doing something under the covers and
> as such VTAM doesn't need an LBUILD for B400.  We do have LBUILDs for
> other B4xx addresses (but they don't use TAS, they are for TSO).
>
> On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote:
> > W dniu 16.11.2023 o 01:47, Michael Babcock pisze:
> >> We have an OSA-ICC connection set up as a 3270 session type.   The LU
> >> Name
> >> in that definition is TERM140.  The CUA is B400.We have a 3270
> >> session
> >> defined with the proper IP and the same LU Name of TERM140. This all
> >> works as expected.  My question is that I thought a VTAM APPL with an
> >> LUNAME of TERM140 was required but I do not see a TERM140 defined in
> >> VTAM
> >> at all.   I’m not a network guy.   Since this is working, I assume
> >> it’s not
> >> required.   Can someone enlighten me?
> >
> > In simple words, LUNAME used in OSA-ICC session definition and
> > emulator - it does NOT exist in any VTAM or TCPIP configuration.
> > Instead, VTAM use device number (devnum), which is in turn not used in
> > emulator session. However OSA-ICC session ties devnum with LUNAME.
> > Note: the same devnum can be used by different LPARs and every LPAR
> > has its own console/terminal. It is not shared, just "duplicate"
> > devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely
> > identify the device.
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there

[Burrell, Todd]

I seem to remember that you can override the system parameters at IPL time and 
specify PLEXCFG=MONOPLEX.  This should bring you up in a single system plex.  
Or you can specify PLEXCFG=XCFLOCAL and not be in a plex at all. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Laurence Chiu
Sent: Thursday, November 16, 2023 1:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What happens if you IPL a LPAR defined as being in a parallel 
sysplex but the CF LPAR is not there

It was gold for me and will help me settle a dispute with some local sysprogs 
who said there would be no problem. My question is, it says if you don't have a 
CF then change GRS=TRYJOIN or =NONE. Problem is, when the problem occurs, how 
do you get online to change it? I could not find an operator command to change 
it and since the system is able to IPL, you can't logon to change it.

On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < 
02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:

> Awesome, how do we even find such gems with TechDocs being what it is...
> Luckily for this one, I seem to have it bookmarked.
>
>
> On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < 
> fogar...@gmail.com> wrote:
>
>
> > Answered a decade ago including how to continue the IPL and get 
> > running (either single system or sysplex without CF)
> >
> https://www.ibm.com/support/pages/system/files/inline-files/Where_is_M
> y_Coupling_Facility.pdf
> > "The paper is being written to provide clear and concise 
> > instructions on how to address the sysplex support team’s most 
> > common callout. Where is
> My
> > Coupling Facility?"
> >
> > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < 
> > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into 
> > > a X'0A3' wait state.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key -
> > >
> [URL Removed for your safety]
> > >
> > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < 
> > > lch...@gmail.com> wrote:
> > >
> > > > Thinking about a LPAR defined as being in a parallel sysplex 
> > > > with GRS=STAR.
> > > >
> > > > What happens if you IPL that LPAR and the CF is not active? Will 
> > > > it start, issue a WTOR or just fail? We are wondering what would 
> > > > happen if our
> LPAR
> > > > was started at the DR site (off a replicated set of volumes) but 
> > > > the
> DR
> > > > CEC
> > > > did not have a CF defined. Thanks
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions, 
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > >
> > > --
> > >  For IBM-MAIN subscribe / signoff / archive access 
> > > instructions, send email to lists...@listserv.ua.edu with the 
> > > message: INFO IBM-MAIN
> >
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

We comply with applicable Federal civil rights laws and do not discriminate.

Visit floridablue.com/ndnotice  to view our 
Non-Discrimination policy and find information on our free language assistance 
services.

 

Florida Blue is a trade name of Blue Cross and Blue Shield of Florida, Inc.  
Blue Cross and Blue Shield of Florida, Inc., and its subsidiary and affiliate 
companies are not responsible for errors or omissions in this e-mail message. 
Any personal comments made in this e-mail do not reflect the views of Blue 
Cross and Blue Shield of Florida, Inc.  The information contained in this 
document may be confidential and intended solely for the use of the individual 
or entity to whom it is addressed.  This document may contain material that is 
privileged or protected from disclosure under applicable law.  If you are not 
the intended recipient or the individual responsible for delivering to the 
intended recipient, please (1) be advised that any use, dissemination, 
forwarding, or copying of this document IS STRICTLY PROHIBITED; and (2) notify 
sender immediately by telephone and destroy the document. THANK YOU.


--
For IBM-MAIN subscribe / signoff / archive access instruct

Re: The JES2 NJE node that cannot die.

[Tom Longfellow]

I have already gone the VTAM Inact route but I have not tried it for EVERYONE.  
  

If I do temporarily kick everyone to  the curb so that the dead node can be 
deleted,  I have yet to find a JES command to delete a node.
Best guess at this point, using your theory is to:
   Shut all JES2 connectivity that could potential lead me to the node to be 
removed.  But If I had command to shut connectivity, my problem would be solved.
   $TNODE(BADBOY),NAME=GOAWAY

No one will know who GOAWAY is and routing to anywhere should fail.

Awkward, but potentially effective

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OSA-ICC Connection Question

[Jay Maynard]

A bit of Googling reveals that TAS is a component of BMC MainView. Under
those circumstances, that OSA-ICC session might never talk to a VTAM
application like TSO at all; if so, then there's no need for an application
LU to pass the emulated terminal to VTAM. In either case, TAS handles all
communication with the device, and VTAM never gets involved.

On Thu, Nov 16, 2023 at 9:02 AM Jay Maynard  wrote:

> Yes, TAS is doing something under the covers. Since you're giving it a
> device number to talk to the OSA-ICC device, that means that device is not
> owned by VTAM at all, at any time; instead, TAS is talking to it directly
> using channel programming like it's a channel-attached, non-SNA 3270
> terminal. Under those circumstances, there's no need tor an LBUILD/LU
> combination for that device, since VTAM's not talking to it. Instead,
> there's an LU definition in VTAM for TAS to pass the device through to
> VTAM, and that LU (which need not be the same one for every session) is
> what communicates with VTAM applications like TSO.
>
> On Thu, Nov 16, 2023 at 8:53 AM Michael Babcock 
> wrote:
>
>> Perhaps it would be better if I explain what we have.   We use the BMC
>> suite of products including the Terminal Address Space (an alternate
>> access method I think they call it).  Within TAS, there is a LOGON
>> UCB(B400) parameter.  The B400 corresponds to the OSA-ICC definition.
>> We have a Visara 500LX box that contains a 3270 session with the same
>> LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a
>> LBUILD for B400 CUADDR anywhere in VTAM.  I expected to see one however.
>> I assume then that the TAS is doing something under the covers and
>> as such VTAM doesn't need an LBUILD for B400.  We do have LBUILDs for
>> other B4xx addresses (but they don't use TAS, they are for TSO).
>>
>> On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote:
>> > W dniu 16.11.2023 o 01:47, Michael Babcock pisze:
>> >> We have an OSA-ICC connection set up as a 3270 session type.   The LU
>> >> Name
>> >> in that definition is TERM140.  The CUA is B400.We have a 3270
>> >> session
>> >> defined with the proper IP and the same LU Name of TERM140. This all
>> >> works as expected.  My question is that I thought a VTAM APPL with an
>> >> LUNAME of TERM140 was required but I do not see a TERM140 defined in
>> >> VTAM
>> >> at all.   I’m not a network guy.   Since this is working, I assume
>> >> it’s not
>> >> required.   Can someone enlighten me?
>> >
>> > In simple words, LUNAME used in OSA-ICC session definition and
>> > emulator - it does NOT exist in any VTAM or TCPIP configuration.
>> > Instead, VTAM use device number (devnum), which is in turn not used in
>> > emulator session. However OSA-ICC session ties devnum with LUNAME.
>> > Note: the same devnum can be used by different LPARs and every LPAR
>> > has its own console/terminal. It is not shared, just "duplicate"
>> > devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely
>> > identify the device.
>> >
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Jay Maynard
>
>

-- 
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[Rick Troth]

I remember the DSECT2C command, but might have been from an ISV (maybe 
Dignus?).
But converting a DSECT to a struct is kinda easy. So if you have the 
Rexx and TSO control blocks in assembler, you should be able to cook-up 
C structs for equivalent representation.

If you need help with that, just holler. BT/DT

-- R; <><


On 11/15/23 16:26, Farley, Peter wrote:

OK, I sort of understand the “personal preference” about not using inline 
assembler (it is kludgey, I agree) and somewhat understand the concern about 
the “unsupported” aspect of retrieving register contents at entry, but if that 
is the case why not use MetalC where you have much more control of the entry 
and exit logic, and could easily provide your own version of the prolog that 
guaranteed access to the contents of R0?  Is there some C library routine that 
is not provided by MetalC that you would need in your Rexx external function?

Also you are correct that IBM does not supply C versions of the Rexx or TSO 
control blocks.  Like Colin, I cobbled together my own collection of them from 
the assembler macro library source using the EDCDSECT utility and some 
semi-automated post-processing.

Peter

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 way to get the entry R13 from within 
the C/C++ code. Obviously, if you could, then any other register is trivial.



- Yes, people suggested inline assembler. I rejected that approach -- it may be 
completely viable but I rejected it -- because



a. I am just not a fan of inline assembler. Call it personal preference. I think the 
syntax seems kludgey. I prefer an external module written in "real" assembler. 
I fully accept that this is just my personal opinion and others who think otherwise are 
just as valid.

b. IIRC the logic was a little bit unsupported. XLC is stable now, so it would 
probably be safe, but for me that was another nail in the coffin of the in-line 
assembler approach.



The code is exactly 11 executable instructions, four of them because I set up 
an eyecatcher that is not really necessary.



I do it without a save area. I branch to the C code with the assumption that 
the C code will ultimately return to *my caller* and not to me.



FWIW, I pass R0 in the EVALBLOCK data area, a totally "safe" spot that does not 
require a GETMAIN.



Charles



On Wed, 15 Nov 2023 17:54:44 +, Farley, Peter  
wrote:




Isn’t there is some C library function (maybe unique to XLC/C++) that lets you 
get the value of R13 (current DSA pointer)?  With that pointer value in hand, 
couldn’t one chain up the DSA stack to get to the saved registers at entry, or 
is that not possible?
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 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 looked for the IRX macros in SYS1.MACLIB?
Are you familiar with EDCDSECT?
Slightly changing the subject, to interface with ehe Rexx environment from a 
called function you will need the entry R0, I found no great way to get that. I 
had to write a tiny front end in assembler that passes R0 to a C/C++ main().
Charles
On Wed, 15 Nov 20 3 10:57:14 -0600, Eric Erickson  wrote:

I've written quite a few callable external funitions 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 use C, but can not seem 
to find any examples or header files for the Rexx Control Blocks. I can't believe 
nobody has done this over the years? Is it even supported?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
F

Re: OSA-ICC Connection Question

[Radoslaw Skorupka]

As other said, TAS use mean no VTAM definitions.
However ...it doesn't matter.
MVS console is also out of VTAM scope.
But the rules are still valid: VTAM or TAS or CONSOLxx does not use 
LUNAME from OSA-ICC. All of them use devnum only to identify the 
terminal/console.
How to define non-SNA terminal or console in z/OS? It is well documented 
IMHO and ICC does not change anything. Just do it as for 3174-xxL 
attached terminals.


--
Radoslaw Skorupka
Lodz, Poland





W dniu 16.11.2023 o 15:53, Michael Babcock pisze:
Perhaps it would be better if I explain what we have.   We use the BMC 
suite of products including the Terminal Address Space (an alternate 
access method I think they call it).  Within TAS, there is a LOGON 
UCB(B400) parameter.  The B400 corresponds to the OSA-ICC definition.  
We have a Visara 500LX box that contains a 3270 session with the same 
LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a 
LBUILD for B400 CUADDR anywhere in VTAM.  I expected to see one 
however.    I assume then that the TAS is doing something under the 
covers and as such VTAM doesn't need an LBUILD for B400.  We do have 
LBUILDs for other B4xx addresses (but they don't use TAS, they are for 
TSO).


On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote:

W dniu 16.11.2023 o 01:47, Michael Babcock pisze:
We have an OSA-ICC connection set up as a 3270 session type.   The 
LU Name
in that definition is TERM140.  The CUA is B400.    We have a 3270 
session

defined with the proper IP and the same LU Name of TERM140. This all
works as expected.  My question is that I thought a VTAM APPL with an
LUNAME of TERM140 was required but I do not see a TERM140 defined in 
VTAM
at all.   I’m not a network guy.   Since this is working, I assume 
it’s not

required.   Can someone enlighten me?


In simple words, LUNAME used in OSA-ICC session definition and 
emulator - it does NOT exist in any VTAM or TCPIP configuration.
Instead, VTAM use device number (devnum), which is in turn not used 
in emulator session. However OSA-ICC session ties devnum with LUNAME. 
Note: the same devnum can be used by different LPARs and every LPAR 
has its own console/terminal. It is not shared, just "duplicate" 
devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely 
identify the device.






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[Rick Troth]

Agreed!
The set-up/tear-down of LE is a pain.

In a previous life, I brought up LE to have it available for C (or any 
other LE languages) sort of on demand. Calling linkage to/from the other 
languages worked fine. It was that LE establishment that would lead to 
ABENDs if not done (or if not done right).


And yeah ... C structs. No biggie.

-- R; <><


On 11/15/23 20:12, David Crayford wrote:

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/include/zos (there is a PDS/E but I can’t remember what it's 
called). FWIW, writing external functions in C/C++ is a bad idea unless it’s 
main routine. The overhead of standing up and ripping down an LE environment is 
huge. Metal/C is an option. It’s one of the reasons why I don’t like REXX, it’s 
difficult to extend with languages other than assembler which makes it useless 
for what I want for a glue language.


On 16 Nov 2023, at 2:06 am, Charles Mills  wrote:

@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, then any other register is trivial.

- Yes, people suggested inline assembler. I rejected that approach -- it may be 
completely viable but I rejected it -- because

a. I am just not a fan of inline assembler. Call it personal preference. I think the 
syntax seems kludgey. I prefer an external module written in "real" assembler. 
I fully accept that this is just my personal opinion and others who think otherwise are 
just as valid.
b. IIRC the logic was a little bit unsupported. XLC is stable now, so it would 
probably be safe, but for me that was another nail in the coffin of the in-line 
assembler approach.

The code is exactly 11 executable instructions, four of them because I set up 
an eyecatcher that is not really necessary.

I do it without a save area. I branch to the C code with the assumption that 
the C code will ultimately return to *my caller* and not to me.

FWIW, I pass R0 in the EVALBLOCK data area, a totally "safe" spot that does not 
require a GETMAIN.

Charles

On Wed, 15 Nov 2023 17:54:44 +, Farley, Peter  
wrote:


Isn’t there is some C library function (maybe unique to XLC/C++) that lets you 
get the value of R13 (current DSA pointer)?  With that pointer value in hand, 
couldn’t one chain up the DSA stack to get to the saved registers at entry, or 
is that not possible?

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 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 looked for the IRX macros in SYS1.MACLIB?



Are you familiar with EDCDSECT?



Slightly changing the subject, to interface with ehe Rexx environment from a 
called function you will need the entry R0, I found no great way to get that. I 
had to write a tiny front end in assembler that passes R0 to a C/C++ main().



Charles



On Wed, 15 Nov 20 3 10:57:14 -0600, Eric Erickson  wrote:




I've written quite a few callable external funitions 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 use C, but can not seem 
to find any examples or header files for the Rexx Control Blocks. I can't believe 
nobody has done this over the years? Is it even supported?



--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the 

Re: The JES2 NJE node that cannot die.

[Tom Longfellow]

Here is my second failed attempt using what I think I learned from Brian.


>"First you need to (in vtam via V NET,INACT,ID=) inactivate any cross domain 
>and CDRSC connections between that LPAR and everyone else, then you need to 
>(in JES) using the >TSOCKET(name) command change it to connect=no.  From that 
>point on, the physical connections just plain doesn't' exist and you can 
>remove it via the delete connection command that >someone mentioned earlier."

I killed all SNA lines in my JES system.   All nodes were inactive and not 
connected to me.
I did $TNODE to set CONNECT=NO and to change the NAME=. --- I cannot fined a 
SOCKET to manipulate.
I would have loved a delete node command, but still cannot find one.

Restarting the SNA lines and foreign nodes  reconnected the node number of the 
targeted node.

One of my partner JES2 systems out there is acting as a guardian angel to 
preseve this link.   even when I say connect=no and kill the physical links, it 
steps in to act as a middle man to preserve the connectivity.   I define this 
angel with PATHMGR=YES.  If I change that to NO he refuses to talk to me at all.

=-=-=-

It is beginning to look like I am just going to have to restart JES without any 
definitions with that node number   Dynamic changes just do not work for me.   
If I do not define node(n2) on my system then the guardian angel will be 
stymied and I will have to live with the 'unknown node' messages when 
connectivity attempt is made by the guardian angel. 

Please do not tell the security auditors that I have no way to cut connectivity 
to an untrusted node.   They will go ballistic.   I guess that in a pinch I 
could fall back on the RACF defense (but would it catch the raw connectivity 
that my guardian angel is forwarding me from the badboy node?)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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 some closed source code. I think it

may be ok to open source it but I'll have to check with the PTB.



On Thu, Nov 16, 2023 at 1:45 PM Farley, Peter <

031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:



> David,

>

> I see at your RTK github you are only providing load modules.  Is there

> any chance you can you provide corresponding source for others to use as a

> model for other applications (like Eric’s EZNOSQL)?  The basic RTK setup

> really sounds like a good fit for a CBT submission, if there are no

> intellectual property issues.

>

> Peter

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[Tom Marchant]

An XL C/C++ may or may not have a DSA address in R13. If it is XPLINK, it will 
not. 64-bit C/C++ programs always use XPLINK-64 linkage. 
In fact, 64-bit LE programs only use XPLINK-64 linkage.

-- 
Tom Marchant

On Wed, 15 Nov 2023 17:54:44 +, Farley, Peter  
wrote:

>Isn’t there is some C library function (maybe unique to XLC/C++) that lets you 
>get the value of R13 (current DSA pointer)?  With that pointer value in hand, 
>couldn’t one chain up the DSA stack to get to the saved registers at entry, or 
>is that not possible?
>
>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 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 looked for the IRX macros in SYS1.MACLIB?
>
>
>
>Are you familiar with EDCDSECT?
>
>
>
>Slightly changing the subject, to interface with ehe Rexx environment from a 
>called function you will need the entry R0, I found no great way to get that. 
>I had to write a tiny front end in assembler that passes R0 to a C/C++ main().
>
>
>
>Charles
>
>
>
>On Wed, 15 Nov 20 3 10:57:14 -0600, Eric Erickson  
>wrote:
>
>
>
>>I've written quite a few callable external funitions 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 use C, 
>>but can not seem to find any examples or header files for the Rexx Control 
>>Blocks. I can't believe nobody has done this over the years? Is it even 
>>supported?
>
>
>
>--
>
>This message and any attachments are intended only for the use of the 
>addressee and may contain information that is privileged and confidential. If 
>the reader of the message is not the intended recipient or an authorized 
>representative of the intended recipient, you are hereby notified that any 
>dissemination of this communication is strictly prohibited. If you have 
>received this communication in error, please notify us immediately by e-mail 
>and delete the message and any attachments from your system.
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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 code is running a complex Rexx environment that frankly I do not fully 
understand. (I didn't write it and it isn't "mine.") I wanted to be sure I had 
THE right environment block, not SOME environment block. An 11-instruction 
assembler module seemed like a great solution. I still believe that it was.

 Charles

On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford  wrote:

>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;

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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 block anywhere else but in the standard linkage?

Charles

On Wed, 15 Nov 2023 14:02:55 -0600, Paul Gilmartin  wrote:

>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 a misguided fixation on "portability"!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OSA-ICC Connection Question

[Michael Babcock]

Thanks to all that responded!   I appreciate the help!

On Thu, Nov 16, 2023 at 9:10 AM Jay Maynard  wrote:

> A bit of Googling reveals that TAS is a component of BMC MainView. Under
> those circumstances, that OSA-ICC session might never talk to a VTAM
> application like TSO at all; if so, then there's no need for an application
> LU to pass the emulated terminal to VTAM. In either case, TAS handles all
> communication with the device, and VTAM never gets involved.
>
> On Thu, Nov 16, 2023 at 9:02 AM Jay Maynard  wrote:
>
> > Yes, TAS is doing something under the covers. Since you're giving it a
> > device number to talk to the OSA-ICC device, that means that device is
> not
> > owned by VTAM at all, at any time; instead, TAS is talking to it directly
> > using channel programming like it's a channel-attached, non-SNA 3270
> > terminal. Under those circumstances, there's no need tor an LBUILD/LU
> > combination for that device, since VTAM's not talking to it. Instead,
> > there's an LU definition in VTAM for TAS to pass the device through to
> > VTAM, and that LU (which need not be the same one for every session) is
> > what communicates with VTAM applications like TSO.
> >
> > On Thu, Nov 16, 2023 at 8:53 AM Michael Babcock 
> > wrote:
> >
> >> Perhaps it would be better if I explain what we have.   We use the BMC
> >> suite of products including the Terminal Address Space (an alternate
> >> access method I think they call it).  Within TAS, there is a LOGON
> >> UCB(B400) parameter.  The B400 corresponds to the OSA-ICC definition.
> >> We have a Visara 500LX box that contains a 3270 session with the same
> >> LUNAME and CUADDR as the OSA-ICC definition (B400). We do not have a
> >> LBUILD for B400 CUADDR anywhere in VTAM.  I expected to see one however.
> >> I assume then that the TAS is doing something under the covers and
> >> as such VTAM doesn't need an LBUILD for B400.  We do have LBUILDs for
> >> other B4xx addresses (but they don't use TAS, they are for TSO).
> >>
> >> On 11/16/2023 5:10 AM, Radoslaw Skorupka wrote:
> >> > W dniu 16.11.2023 o 01:47, Michael Babcock pisze:
> >> >> We have an OSA-ICC connection set up as a 3270 session type.   The LU
> >> >> Name
> >> >> in that definition is TERM140.  The CUA is B400.We have a 3270
> >> >> session
> >> >> defined with the proper IP and the same LU Name of TERM140. This all
> >> >> works as expected.  My question is that I thought a VTAM APPL with an
> >> >> LUNAME of TERM140 was required but I do not see a TERM140 defined in
> >> >> VTAM
> >> >> at all.   I’m not a network guy.   Since this is working, I assume
> >> >> it’s not
> >> >> required.   Can someone enlighten me?
> >> >
> >> > In simple words, LUNAME used in OSA-ICC session definition and
> >> > emulator - it does NOT exist in any VTAM or TCPIP configuration.
> >> > Instead, VTAM use device number (devnum), which is in turn not used in
> >> > emulator session. However OSA-ICC session ties devnum with LUNAME.
> >> > Note: the same devnum can be used by different LPARs and every LPAR
> >> > has its own console/terminal. It is not shared, just "duplicate"
> >> > devnum. However OSA-ICC use devum *and* MIF and CSS to uniquely
> >> > identify the device.
> >> >
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
> > --
> > Jay Maynard
> >
> >
>
> --
> Jay Maynard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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) and somewhat understand the concern about 
>the “unsupported” aspect of retrieving register contents at entry, but if that 
>is the case why not use MetalC where you have much more control of the entry 
>and exit logic, and could easily provide your own version of the prolog that 
>guaranteed access to the contents of R0?  Is there some C library routine that 
>is not provided by MetalC that you would need in your Rexx external function?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[Farley, Peter]

You could still use a MetalC “front end” to both capture R0 and establish the 
LE/C++ environment via CEEPIPI, saving addresses and/or data as needed in a 
writeable static area, and on subsequent calls just invoke the C++ code to 
execute the needed functions.

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 the invoking Rexx code would then need to call before exiting.

Peter

From: IBM Mainframe 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 2023 21:26:18 +, Farley, Peter 
mailto:peter.far...@broadridge.com>> wrote:



>OK, I sort of understand the “personal preference” about not using inline 
>assembler (it is kludgey, I agree) and somewhat understand the concern about 
>the “unsupported” aspect of retrieving register contents at entry, but if that 
>is the case why not use MetalC where you have much more control of the entry 
>and exit logic, and could easily provide your own version of the prolog that 
>guaranteed access to the contents of R0?  Is there some C library routine that 
>is not provided by MetalC that you would need in your Rexx external function?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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 the invoking Rexx code would then need to call before exiting.
>
Is there a replaceable routine for REXX EXIT?

Some packages place a reasonable burden on the end user with:
CALL *CALLS 'ON'  /* Establish environment.  */
/* do stuff */
CALL *CALLS 'OFF'  /* Terminate  */

(SYSCALLS( 'OFF' ) is disparaged by its author.)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there

[Laurence Chiu]

Thanks to all. We do have an emergency single pack LPAR we can use but I
would rather be prepared and either have a IEASYSnn setup or have operator
instructions ready for people to know what to do when in a DR situation
when the pressure is on

On Fri, Nov 17, 2023 at 4:04 AM Burrell, Todd <
0316e668f7df-dmarc-requ...@listserv.ua.edu> wrote:

> I seem to remember that you can override the system parameters at IPL time
> and specify PLEXCFG=MONOPLEX.  This should bring you up in a single system
> plex.  Or you can specify PLEXCFG=XCFLOCAL and not be in a plex at all.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Laurence Chiu
> Sent: Thursday, November 16, 2023 1:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What happens if you IPL a LPAR defined as being in a parallel
> sysplex but the CF LPAR is not there
>
> It was gold for me and will help me settle a dispute with some local
> sysprogs who said there would be no problem. My question is, it says if you
> don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the
> problem occurs, how do you get online to change it? I could not find an
> operator command to change it and since the system is able to IPL, you
> can't logon to change it.
>
> On Thu, Nov 16, 2023 at 4:18 PM kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Awesome, how do we even find such gems with TechDocs being what it is...
> > Luckily for this one, I seem to have it bookmarked.
> >
> >
> > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi <
> > fogar...@gmail.com> wrote:
> >
> >
> > > Answered a decade ago including how to continue the IPL and get
> > > running (either single system or sysplex without CF)
> > >
> > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_M
> > y_Coupling_Facility.pdf
> > > "The paper is being written to provide clear and concise
> > > instructions on how to address the sysplex support team’s most
> > > common callout. Where is
> > My
> > > Coupling Facility?"
> > >
> > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs <
> > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into
> > > > a X'0A3' wait state.
> > > >
> > > > Mark Jacobs
> > > >
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > >
> > > > GPG Public Key -
> > > >
> > [URL Removed for your safety]
> > > >
> > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu <
> > > > lch...@gmail.com> wrote:
> > > >
> > > > > Thinking about a LPAR defined as being in a parallel sysplex
> > > > > with GRS=STAR.
> > > > >
> > > > > What happens if you IPL that LPAR and the CF is not active? Will
> > > > > it start, issue a WTOR or just fail? We are wondering what would
> > > > > happen if our
> > LPAR
> > > > > was started at the DR site (off a replicated set of volumes) but
> > > > > the
> > DR
> > > > > CEC
> > > > > did not have a CF defined. Thanks
> > > > >
> > > > >
> > --
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> > > >
> > > > --
> > > >  For IBM-MAIN subscribe / signoff / archive access
> > > > instructions, send email to lists...@listserv.ua.edu with the
> > > > message: INFO IBM-MAIN
> > >
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> We comply with applicable Federal civil rights laws and do not
> discriminate.
>
> Visit floridablue.com/ndnotice  to view
> our Non-Discrimination policy and find information on our free language
> assistance services.
>
>
>
> Florida Blue is a trade name of Blue Cross and Blue Shield of Florida,
> Inc.  Blue Cross and Blue Shield of Florida, Inc., and its subsidiary and
> affiliate companies are not responsible for errors or omissions in this
> e-mail message. Any personal comments made in this e-mail do not reflect
> the views of Blue Cross and Blue Shield of Florida, Inc.  The information
> contained in this document may be confidential and intended solely for the
> use of the individual or entity to whom it is addressed.  This document may
> con

Re: External Functions in C on z/OS

[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 which includes 
classes for mapping data structures with Python classes. We use 
BigEndianStructure for mapping control blocks 
https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure. It 
would be cool if the tooling that we worked on with Peter Relson to create C 
header files could be reused to generate Python mappings. With the recent zIIP 
offloading Python is strategic. 

> On 17 Nov 2023, at 12:38 am, Charles Mills  wrote:
> 
>  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 code is running a complex Rexx environment that frankly I do not fully 
> understand. (I didn't write it and it isn't "mine.") I wanted to be sure I 
> had THE right environment block, not SOME environment block. An 
> 11-instruction assembler module seemed like a great solution. I still believe 
> that it was.
> 
>  Charles
> 
> On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford  
> wrote:
> 
>> 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;
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[Seymour J Metz]

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
עַם יִשְׂרָאֵל חַי




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 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 which includes 
classes for mapping data structures with Python classes. We use 
BigEndianStructure for mapping control blocks 
https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure. It 
would be cool if the tooling that we worked on with Peter Relson to create C 
header files could be reused to generate Python mappings. With the recent zIIP 
offloading Python is strategic.

> On 17 Nov 2023, at 12:38 am, Charles Mills  wrote:
>
>  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 code is running a complex Rexx environment that frankly I do not fully 
> understand. (I didn't write it and it isn't "mine.") I wanted to be sure I 
> had THE right environment block, not SOME environment block. An 
> 11-instruction assembler module seemed like a great solution. I still believe 
> that it was.
>
>  Charles
>
> On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford  
> wrote:
>
>> 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;
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[David Crayford]

I don't find ooRexx useful on the PC as it's basically on life support
where Python has millions of contributors. Take data validation as an
example. There is a first class library https://docs.pydantic.dev/latest/.

Python isn't my favorite language by a large margin. But it is useful so it
wins. Same same with Java. Personal preference is secondary to a pragmatic
choice.

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 (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 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
> which includes classes for mapping data structures with Python classes. We
> use BigEndianStructure for mapping control blocks
> https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure.
> It would be cool if the tooling that we worked on with Peter Relson to
> create C header files could be reused to generate Python mappings. With the
> recent zIIP offloading Python is strategic.
>
> > On 17 Nov 2023, at 12:38 am, Charles Mills  wrote:
> >
> >  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 code is running a complex Rexx environment that frankly I do not
> fully understand. (I didn't write it and it isn't "mine.") I wanted to be
> sure I had THE right environment block, not SOME environment block. An
> 11-instruction assembler module seemed like a great solution. I still
> believe that it was.
> >
> >  Charles
> >
> > On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford 
> wrote:
> >
> >> 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;
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[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 wanted me to develop something they first had to re-write their 
existing system.

Charles

On Fri, 17 Nov 2023 05:02:57 +0800, David Crayford  wrote:

>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 which includes 
>classes for mapping data structures with Python classes. We use 
>BigEndianStructure for mapping control blocks 
>https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure. It 
>would be cool if the tooling that we worked on with Peter Relson to create C 
>header files could be reused to generate Python mappings. With the recent zIIP 
>offloading Python is strategic. 
>
>> On 17 Nov 2023, at 12:38 am, Charles Mills  wrote:
>> 
>>  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 code is running a complex Rexx environment that frankly I do not fully 
>> understand. (I didn't write it and it isn't "mine.") I wanted to be sure I 
>> had THE right environment block, not SOME environment block. An 
>> 11-instruction assembler module seemed like a great solution. I still 
>> believe that it was.
>> 
>>  Charles
>> 
>> On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford  
>> wrote:
>> 
>>> 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;
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: External Functions in C on z/OS

[Seymour J Metz]

Different folks, different strokes. But I agree about libraries; I don't like 
Perl syntax, but I use it because of CPAN; I find LaTeX awkward, but I can do 
things in it and CTAN that would be difficult without it.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




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 life support
where Python has millions of contributors. Take data validation as an
example. There is a first class library https://docs.pydantic.dev/latest/.

Python isn't my favorite language by a large margin. But it is useful so it
wins. Same same with Java. Personal preference is secondary to a pragmatic
choice.

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 (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 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
> which includes classes for mapping data structures with Python classes. We
> use BigEndianStructure for mapping control blocks
> https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure.
> It would be cool if the tooling that we worked on with Peter Relson to
> create C header files could be reused to generate Python mappings. With the
> recent zIIP offloading Python is strategic.
>
> > On 17 Nov 2023, at 12:38 am, Charles Mills  wrote:
> >
> >  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 code is running a complex Rexx environment that frankly I do not
> fully understand. (I didn't write it and it isn't "mine.") I wanted to be
> sure I had THE right environment block, not SOME environment block. An
> 11-instruction assembler module seemed like a great solution. I still
> believe that it was.
> >
> >  Charles
> >
> > On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford 
> wrote:
> >
> >> 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;
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rexx to clone users in RACF

[Jon Perryman]

On Thu, 16 Nov 2023 08:04:47 +0400, Peter  wrote:

>I am looking for a rexx logic which can multiple RACFID based on one model 
>user ?

Doesn't the RACF ISPF interface have the ability to close a user?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rexx to clone users in RACF

[Wayne Bickerdike]

*Doesn't the RACF ISPF interface have the ability to close a user?*

No, Consul RACF which became z/Secure has that capability. As Radowslaw
says, set up a template or use an ISPF file tailoring skeleton with a set
of templates and generate from a panel.


On Fri, Nov 17, 2023 at 1:55 PM Jon Perryman  wrote:

> On Thu, 16 Nov 2023 08:04:47 +0400, Peter  wrote:
>
> >I am looking for a rexx logic which can multiple RACFID based on one
> model user ?
>
> Doesn't the RACF ISPF interface have the ability to close a user?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN