Update in case in anyone is interested.  The network team disables the ethernet 
interface connected
to the OSA cards, mainframe TCP/IP port and not the ICC port, to ensure nobody 
ever connects to the
DR LPARs thinking they are connected to the production LPARs.  Therefore, the 
OSA interfaces would
not activate when TCP/IP was started.  I updated the RESOLVER configuration to 
use the loopback
address of 127.0.0.1 so DNS queries would not timeout.  It appeared the JVM 
invocation of the IDZ RSE
STC was performing DNS queries.
 
Secondly, I had to define the IDZ RSE ports in the TCP/IP configuration with 
both TCP & UDP.  Prior
to this change, the IDZ RSE ports were not defined in the configuration.  I do 
not know exactly why
this has an effect on the IDZ RSE server daemon being able to initialize, as 
other TCP/IP address spaces
are not affected, i.e. FTP and the IDZ JMON. 



"Confidentially doc, I am the wabbit."

Bugs Bunny

Sent with Proton Mail secure email.

On Tuesday, February 24th, 2026 at 8:21 AM, rpinion865 
<[email protected]> wrote:

> Same RACF database/settings, just IDZ is running on the DR machine.  The only
> difference I have been able to determine, on the DR machine TCP/IP is unable
> to use the OSAs.  On the DR machine, TCP/IP issues EZA4342I error E080, when
> attempting to initialize the OSAs.  I suspect the network team has the network
> cable disconnected to ensure no once connects to the DR machine, thinking they
> are connected to a production LPAR.  I access the DR machine via the ICC, 
> which
> obviously has its cable connected.
> 
> 
> 
> "Confidentially doc, I am the wabbit."
> 
> Bugs Bunny
> 
> Sent with Proton Mail secure email.
> 
> On Tuesday, February 24th, 2026 at 1:51 AM, גדי בן אבי 
> <[email protected]> wrote:
> 
> > This is what AI says:
> > To create a daemon socket on z/OS using RACF, the user ID running the 
> > daemon must have a UID of 0, READ access to the BPX.DAEMON facility class 
> > profile, and potentially READ access to BPX.POE. Additionally, the daemon's 
> > user ID should have an OMVS segment defined.
> > Key RACF security requirements for daemon setup:
> > User ID Configuration: The user ID must have a UID of 0 (superuser).
> > BPX.DAEMON: PERMIT BPX.DAEMON CLASS(FACILITY) ID(daemon_userid) 
> > ACCESS(READ).
> > BPX.POE (if active): PERMIT BPX.POE CLASS(FACILITY) ID(daemon_userid) 
> > ACCESS(READ).
> > Started Class: The daemon should be defined in the STARTED class.
> > Program Control: If enabled, ensure the daemon program is protected.
> >
> > If the daemon is for special purposes (e.g., SSHD), the user ID running the 
> > main daemon should be different from the unprivileged user ID used for 
> > privilege separation.
> >
> > Gadi
> > ________________________________
> > From: IBM Mainframe Discussion List <[email protected]> on behalf of 
> > rpinion865 <[email protected]>
> > Sent: Tuesday, February 24, 2026 00:02
> > To: [email protected] <[email protected]>
> > Subject: IDZ 3.3 on z/OS 3.1
> >
> > I have IDZ 3.3 installed on a z/OS 3.1 system. On our non-DR TECH LPAR, 
> > IDZRSED fully initializes.
> > However, the exact same configuration running on our DR TECH LPAR does not 
> > initialize. I get
> > the message below. I cannot locate any documentation which explains why 
> > daemon socket cannot
> > be created.
> >
> > ISRBROBA /SYSTEM/var/zexpl/logs/server/rseserver.IDZRSED#20260223154438.log 
> > Line 0000000000 Col 013 144
> >
> > Command ===> Scroll ===> CSR
> >
> > *********************************************************** Top of Data 
> > ************************************************************
> >
> > 5:44:39:519 GMT-06:00 PID:83886590 THREAD:0FF4200000000001 TCB:00ACD958 
> > USER:STCRSED ERROR: RseDaemon:Error creating a daemon socket
> >
> > "Confidentially doc, I am the wabbit."
> >
> > Bugs Bunny
> >
> > Sent with [Proton Mail](https://proton.me/mail/home) secure email.
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO IBM-MAIN
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO IBM-MAIN
> >
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to