DB2 z/OS DDF connection failure after upgrade to V12

Kirk Hampton

DB2 z/OS DDF connection failure after upgrade to V12
I'm sure I'm going to wind up opening a ticket with IBM, but I thought I
would give the list a try.

We're in the process of upgrading our last DB2 z/OS Production systems to
V12. After the upgrade of a 2-way datasharing group this week, one of
three other DB2's on other LPARS could not re-establish a DDF connection.
It happens to still be v11, of the other 2, one is v11 and one is v12, and
they both reconnected just fine.
A SPUFI query to the remote table returns the error
DSNT408I SQLCODE = -30082, ERROR: CONNECTION FAILED FOR SECURITY REASON
17.UNSUPPORTED FUNCTION ()
The same query executes fine from the other 2 DB2 subsystems.

We found that the DB2 requestor that is failing, had an entry for the other
DB2 in both the SYSIBM.LUNAMES and SYSIBM.IPNAMES, but to our knowledge we
have only ever used the VTAM lunames for LPAR-to-LPAR connectivity. We
have deleted the row from IPNAMES, but since we cannot restart DDF without
declaring an outage, there has been no change in the error.

We do have an upcoming outage to this requestor DB2, to perform the V12
upgrade there, so we can wait until then to regain the connection, as it is
only used by our DBA team and not be any Apps.

Does anyone know if DB2 now prefers a TCP/IP connection to a VTAM one ? Or
if having entries in both tables now confuses it, where it did not before ?



Thanks,

Kirk Hampton

James Campbell

DB2 z/OS DDF connection failure after upgrade to V12
(in response to Kirk Hampton)
"If the same name is in both SYSIBM.LUNAMES and SYSIBM.IPNAMES, TCP/IP is used."
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcd
b.html

And that wording has been unchanged since Db2 10.

It appears to me that your target Db2 has TCPALVER=NO (as all good systems should),
and the source Db was (until you deleted the row) trying to say "it's OK, I've verified this user"
(SYSIBM.IPNAMES.SECURITY_OUT='A').

Does the other member of the DS group have TCPALVER=YES? Were you "happening" to
connect to it in the past?

There is a vast range of things that can go wrong.

James Campbell


On 30 May 2020 at 15:55, Kirk Hampton wrote:

> I'm sure I'm going to wind up opening a ticket with IBM, but I thought I
> would give the list a try.
>
> We're in the process of upgrading our last DB2 z/OS Production systems to
> V12. After the upgrade of a 2-way datasharing group this week, one of
> three other DB2's on other LPARS could not re-establish a DDF connection.
> It happens to still be v11, of the other 2, one is v11 and one is v12, and
> they both reconnected just fine.
> A SPUFI query to the remote table returns the error
> DSNT408I SQLCODE = -30082, ERROR: CONNECTION FAILED FOR SECURITY REASON
> 17.UNSUPPORTED FUNCTION ()
> The same query executes fine from the other 2 DB2 subsystems.
>
> We found that the DB2 requestor that is failing, had an entry for the other
> DB2 in both the SYSIBM.LUNAMES and SYSIBM.IPNAMES, but to our knowledge we
> have only ever used the VTAM lunames for LPAR-to-LPAR connectivity. We
> have deleted the row from IPNAMES, but since we cannot restart DDF without
> declaring an outage, there has been no change in the error.
>
> We do have an upcoming outage to this requestor DB2, to perform the V12
> upgrade there, so we can wait until then to regain the connection, as it is
> only used by our DBA team and not be any Apps.
>
> Does anyone know if DB2 now prefers a TCP/IP connection to a VTAM one ? Or
> if having entries in both tables now confuses it, where it did not before ?
>
>
>
> Thanks,
>
> Kirk Hampton
>

--
This email has been checked for viruses by AVG.
https://www.avg.com

Kirk Hampton

DB2 z/OS DDF connection failure after upgrade to V12
(in response to James Campbell)
James, thank you for that information.
FYI,
we discovered that we inadvertently set TCPALVER to NO in our DS group,
even though it had been YES in v11.
All of our other DB2 subsystems have it set to YES.
We reassembled our ZPARMs for the DS group and did a -SET SYSPARM RELOAD,
and were then able to successfully conenct from the remote subsystem.

We will be looking into the recommendation that "all good systems should be
set to NO",
but for now, the applications are happy.

Thanks,

Kirk Hampton



On Sun, May 31, 2020 at 2:27 AM James Campbell <[login to unmask email]> wrote:

> "If the same name is in both SYSIBM.LUNAMES and SYSIBM.IPNAMES, TCP/IP is
> used."
>
> https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcd
> b.html
> https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcdb.html
>
> And that wording has been unchanged since Db2 10.
>
> It appears to me that your target Db2 has TCPALVER=NO (as all good systems
> should),
> and the source Db was (until you deleted the row) trying to say "it's OK,
> I've verified this user"
> (SYSIBM.IPNAMES.SECURITY_OUT='A').
>
> Does the other member of the DS group have TCPALVER=YES? Were you
> "happening" to
> connect to it in the past?
>
> There is a vast range of things that can go wrong.
>
> James Campbell
>
>
> On 30 May 2020 at 15:55, Kirk Hampton wrote:
>
> > I'm sure I'm going to wind up opening a ticket with IBM, but I thought I
> > would give the list a try.
> >
> > We're in the process of upgrading our last DB2 z/OS Production systems to
> > V12. After the upgrade of a 2-way datasharing group this week, one of
> > three other DB2's on other LPARS could not re-establish a DDF connection.
> > It happens to still be v11, of the other 2, one is v11 and one is v12,
> and
> > they both reconnected just fine.
> > A SPUFI query to the remote table returns the error
> > DSNT408I SQLCODE = -30082, ERROR: CONNECTION FAILED FOR SECURITY REASON
> > 17.UNSUPPORTED FUNCTION ()
> > The same query executes fine from the other 2 DB2 subsystems.
> >
> > We found that the DB2 requestor that is failing, had an entry for the
> other
> > DB2 in both the SYSIBM.LUNAMES and SYSIBM.IPNAMES, but to our knowledge
> we
> > have only ever used the VTAM lunames for LPAR-to-LPAR connectivity. We
> > have deleted the row from IPNAMES, but since we cannot restart DDF
> without
> > declaring an outage, there has been no change in the error.
> >
> > We do have an upcoming outage to this requestor DB2, to perform the V12
> > upgrade there, so we can wait until then to regain the connection, as it
> is
> > only used by our DBA team and not be any Apps.
> >
> > Does anyone know if DB2 now prefers a TCP/IP connection to a VTAM one ?
> Or
> > if having entries in both tables now confuses it, where it did not
> before ?
> >
> >
> >
> > Thanks,
> >
> > Kirk Hampton
> >
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
> -----End Original Message-----
>
>

James Campbell

DB2 z/OS DDF connection failure after upgrade to V12
(in response to Kirk Hampton)
If you have TCPALVER=YES and allow random systems access to your Db2 systems a
neferious person can claim to have userid SYSADM (or whatever) on the client - and hence
on the server, and then not-nice things can happen.

The way to allow mainframe Db2 for z/OSs to talk to each other without supplying a
password is to set up passtickets.

James Campbell


On 5 Jun 2020 at 13:38, Kirk Hampton wrote:

> James, thank you for that information.
> FYI,
> we discovered that we inadvertently set TCPALVER to NO in our DS group,
> even though it had been YES in v11.
> All of our other DB2 subsystems have it set to YES.
> We reassembled our ZPARMs for the DS group and did a -SET SYSPARM RELOAD,
> and were then able to successfully conenct from the remote subsystem.
>
> We will be looking into the recommendation that "all good systems should be
> set to NO",
> but for now, the applications are happy.
>
> Thanks,
>
> Kirk Hampton
>
>
>
> On Sun, May 31, 2020 at 2:27 AM James Campbell <[login to unmask email]> wrote:
>
> > "If the same name is in both SYSIBM.LUNAMES and SYSIBM.IPNAMES, TCP/IP is
> > used."
> >
> > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcd
> > b.html
> > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcdb.html
> >
> > And that wording has been unchanged since Db2 10.
> >
> > It appears to me that your target Db2 has TCPALVER=NO (as all good systems
> > should),
> > and the source Db was (until you deleted the row) trying to say "it's OK,
> > I've verified this user"
> > (SYSIBM.IPNAMES.SECURITY_OUT='A').
> >
> > Does the other member of the DS group have TCPALVER=YES? Were you
> > "happening" to
> > connect to it in the past?
> >
> > There is a vast range of things that can go wrong.
> >
> > James Campbell
> >
> >
> > On 30 May 2020 at 15:55, Kirk Hampton wrote:
> >
> > > I'm sure I'm going to wind up opening a ticket with IBM, but I thought I
> > > would give the list a try.
> > >
> > > We're in the process of upgrading our last DB2 z/OS Production systems to
> > > V12. After the upgrade of a 2-way datasharing group this week, one of
> > > three other DB2's on other LPARS could not re-establish a DDF connection.
> > > It happens to still be v11, of the other 2, one is v11 and one is v12,
> > and
> > > they both reconnected just fine.
> > > A SPUFI query to the remote table returns the error
> > > DSNT408I SQLCODE = -30082, ERROR: CONNECTION FAILED FOR SECURITY REASON
> > > 17.UNSUPPORTED FUNCTION ()
> > > The same query executes fine from the other 2 DB2 subsystems.
> > >
> > > We found that the DB2 requestor that is failing, had an entry for the
> > other
> > > DB2 in both the SYSIBM.LUNAMES and SYSIBM.IPNAMES, but to our knowledge
> > we
> > > have only ever used the VTAM lunames for LPAR-to-LPAR connectivity. We
> > > have deleted the row from IPNAMES, but since we cannot restart DDF
> > without
> > > declaring an outage, there has been no change in the error.
> > >
> > > We do have an upcoming outage to this requestor DB2, to perform the V12
> > > upgrade there, so we can wait until then to regain the connection, as it
> > is
> > > only used by our DBA team and not be any Apps.
> > >
> > > Does anyone know if DB2 now prefers a TCP/IP connection to a VTAM one ?
> > Or
> > > if having entries in both tables now confuses it, where it did not
> > before ?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Kirk Hampton
> > >

--
This email has been checked for viruses by AVG.
https://www.avg.com

Colin Raybould

RE: DB2 z/OS DDF connection failure after upgrade to V12
(in response to James Campbell)

Hi Kirk,

I recommend that you follow the advise of James Campbell and implement Pass Tickets & set TCPALVER=NO to secure your DB2 system.  Your DB2 data is very exposed until you do.

Regards,

Colin Raybould
In Reply to James Campbell:

If you have TCPALVER=YES and allow random systems access to your Db2 systems a
neferious person can claim to have userid SYSADM (or whatever) on the client - and hence
on the server, and then not-nice things can happen.

The way to allow mainframe Db2 for z/OSs to talk to each other without supplying a
password is to set up passtickets.

James Campbell


On 5 Jun 2020 at 13:38, Kirk Hampton wrote:

> James, thank you for that information.
> FYI,
> we discovered that we inadvertently set TCPALVER to NO in our DS group,
> even though it had been YES in v11.
> All of our other DB2 subsystems have it set to YES.
> We reassembled our ZPARMs for the DS group and did a -SET SYSPARM RELOAD,
> and were then able to successfully conenct from the remote subsystem.
>
> We will be looking into the recommendation that "all good systems should be
> set to NO",
> but for now, the applications are happy.
>
> Thanks,
>
> Kirk Hampton
>
>
>
> On Sun, May 31, 2020 at 2:27 AM James Campbell <[login to unmask email]> wrote:
>
> > "If the same name is in both SYSIBM.LUNAMES and SYSIBM.IPNAMES, TCP/IP is
> > used."
> >
> > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcd
> > b.html
> > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/inst/src/tpc/db2z_roleofcdb.html
> >
> > And that wording has been unchanged since Db2 10.
> >
> > It appears to me that your target Db2 has TCPALVER=NO (as all good systems
> > should),
> > and the source Db was (until you deleted the row) trying to say "it's OK,
> > I've verified this user"
> > (SYSIBM.IPNAMES.SECURITY_OUT='A').
> >
> > Does the other member of the DS group have TCPALVER=YES? Were you
> > "happening" to
> > connect to it in the past?
> >
> > There is a vast range of things that can go wrong.
> >
> > James Campbell
> >
> >
> > On 30 May 2020 at 15:55, Kirk Hampton wrote:
> >
> > > I'm sure I'm going to wind up opening a ticket with IBM, but I thought I
> > > would give the list a try.
> > >
> > > We're in the process of upgrading our last DB2 z/OS Production systems to
> > > V12. After the upgrade of a 2-way datasharing group this week, one of
> > > three other DB2's on other LPARS could not re-establish a DDF connection.
> > > It happens to still be v11, of the other 2, one is v11 and one is v12,
> > and
> > > they both reconnected just fine.
> > > A SPUFI query to the remote table returns the error
> > > DSNT408I SQLCODE = -30082, ERROR: CONNECTION FAILED FOR SECURITY REASON
> > > 17.UNSUPPORTED FUNCTION ()
> > > The same query executes fine from the other 2 DB2 subsystems.
> > >
> > > We found that the DB2 requestor that is failing, had an entry for the
> > other
> > > DB2 in both the SYSIBM.LUNAMES and SYSIBM.IPNAMES, but to our knowledge
> > we
> > > have only ever used the VTAM lunames for LPAR-to-LPAR connectivity. We
> > > have deleted the row from IPNAMES, but since we cannot restart DDF
> > without
> > > declaring an outage, there has been no change in the error.
> > >
> > > We do have an upcoming outage to this requestor DB2, to perform the V12
> > > upgrade there, so we can wait until then to regain the connection, as it
> > is
> > > only used by our DBA team and not be any Apps.
> > >
> > > Does anyone know if DB2 now prefers a TCP/IP connection to a VTAM one ?
> > Or
> > > if having entries in both tables now confuses it, where it did not
> > before ?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Kirk Hampton
> > >

--
This email has been checked for viruses by AVG.
https://www.avg.com

Horacio Villa

DB2 z/OS DDF connection failure after upgrade to V12
(in response to James Campbell)
Hi,

is anywhere some clear explanation on how to set up passtickets?
I tried some time ago with no success.

Horacio

Aurora Emanuela Dellanno

RE: DB2 z/OS DDF connection failure after upgrade to V12
(in response to Horacio Villa)

Hi Horacio,

 

CA (beg pardon, Broadcom) have the best description of how to create passtickets, scattered through their product documentation, than any I know - see a good example here:

 

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/performance-and-storage/ca-cross-enterprise-application-performance-management/10-6/additional-resources/how-to-configure-passtickets-for-ca-sysview-for-db2.html

 

HTH.

 

Thanks.

 

Aurora

Colin Raybould

RE: DB2 z/OS DDF connection failure after upgrade to V12
(in response to Aurora Emanuela Dellanno)

Hi Aurora,

I did not found any DB2 specifics for implementing PassTickets in the CA manuals.

I also do not have a good writeup of how to implement PassTickets for DB2, but I do have a diagram for reference.

The best general introduction to PassTickets I have found is the beginning of chapter 6 of the Redbook “Java Security on z/OS - The Complete View”.

Before starting implementing PassTickets for DB2 you should collect and report on IFCID 319 data to identify where the userid only logons are coming from.

Be prepared to spend time aligning DB2 z server BSDS DDF definitions with the Communication Database tables in all the DB2 z clients.

Other than that it is a slog through Chapter 3 of the DB2 Managing Security manual.

Regards,

Colin Raybould.



In Reply to Aurora Emanuela Dellanno:

Hi Horacio,

 

CA (beg pardon, Broadcom) have the best description of how to create passtickets, scattered through their product documentation, than any I know - see a good example here:

 

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/performance-and-storage/ca-cross-enterprise-application-performance-management/10-6/additional-resources/how-to-configure-passtickets-for-ca-sysview-for-db2.html

 

HTH.

 

Thanks.

 

Aurora

Attachments

  • PassTicket Diagram.pdf (266.8k)

Marcus Davage

DB2 z/OS DDF connection failure after upgrade to V12
(in response to Colin Raybould)
Hmmm….. I feel a Redbook™ coming on, Colin.

Regards,
Marcus Davage CITP MBCS
Lead Product Developer
AMI-DevOps for Db2 – SQL Performance
Direct

+44 118 921 8517

[cid:[login to unmask email]



Mobile

+44 7840 023 560



Email

[login to unmask email]<mailto:[login to unmask email]>



E2, Eskdale Road, Winnersh, Berkshire, United Kingdom RG41 5TS
10431 Morado Circle, Austin, Texas 78759, USA

From: Colin Raybould <[login to unmask email]>
Sent: 11 June 2020 07:55
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: DB2 z/OS DDF connection failure after upgrade to V12


Hi Aurora,

I did not found any DB2 specifics for implementing PassTickets in the CA manuals.

I also do not have a good writeup of how to implement PassTickets for DB2, but I do have a diagram for reference.

The best general introduction to PassTickets I have found is the beginning of chapter 6 of the Redbook “Java Security on z/OS - The Complete View”.

Before starting implementing PassTickets for DB2 you should collect and report on IFCID 319 data to identify where the userid only logons are coming from.

Be prepared to spend time aligning DB2 z server BSDS DDF definitions with the Communication Database tables in all the DB2 z clients.

Other than that it is a slog through Chapter 3 of the DB2 Managing Security manual.

Regards,

Colin Raybould.


In Reply to Aurora Emanuela Dellanno:

Hi Horacio,



CA (beg pardon, Broadcom) have the best description of how to create passtickets, scattered through their product documentation, than any I know - see a good example here:



https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/performance-and-storage/ca-cross-enterprise-application-performance-management/10-6/additional-resources/how-to-configure-passtickets-for-ca-sysview-for-db2.html https://urldefense.proofpoint.com/v2/url?u=https-3A__techdocs.broadcom.com_content_broadcom_techdocs_us_en_ca-2Dmainframe-2Dsoftware_performance-2Dand-2Dstorage_ca-2Dcross-2Denterprise-2Dapplication-2Dperformance-2Dmanagement_10-2D6_additional-2Dresources_how-2Dto-2Dconfigure-2Dpasstickets-2Dfor-2Dca-2Dsysview-2Dfor-2Ddb2.html&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=TWIWvBTL_6eRknj-K-VTPl9fKzDdMa-BPXPFLTNNamU&e=



HTH.



Thanks.



Aurora

________________________________
Attachment Links: PassTicket Diagram.pdf (273 k) https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_do_-3Fdownload-3D1-26fid-3D12259&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=bbOOKaIv66qq87g72wJEolFBZVwwUUnB4NkdqQ-_P3Q&e=
Site Links: View post online https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_st_-3Fpost-3D192630-26anc-3Dp192630-23p192630&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=nZw45hy8XLBLjyMNG1--8_mOZ13D-DC6AvSn0U2chbo&e= View mailing list online https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_si_-3Ftopic-3D19&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=CXiO3zYFXKUjcmzJZ1p9cHa8gqYY2jgK5DrFQXKuDLA&e= Start new thread via email<mailto:[login to unmask email]> Unsubscribe from this mailing list<mailto:[login to unmask email]?Subject=Unsubscribe> Manage your subscription https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_us_to_&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=G1FUMYKQsc3f8IYHe5CEDtG96z5Kz-AdCx18z-GKyyA&e=

This email has been sent to: [login to unmask email]<mailto:[login to unmask email]>

Try BCV5, the BCV5 Masking Tool, & XDM a rapid Refresh/Clone/TDM Suite for Db2 z & distributed.
DBARS -Audit,record,& block Db2 accesses to sensitive data real-time, NO audit trace or log required
http://www.ESAIGroup.com/IDUG https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ESAIGroup.com_IDUG&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=2qlErMg0XHeLZSySJaeyMWNRNMJc31T7l4QhtaBDwVQ&e=

Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.idug.org_p_cm_ld_fid-3D2&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=mhV0yJKfitu0qAYB_odGUoLWNP8v4L54s7lNo_VjYxo&m=I9jlHbObr4LZCBz2bQh5MheH7_5OBr0A259XDXdKLAM&s=eMQ1i3QKjgDLmDnuOhRtXCQoPHmKC-GjTTaqv7PZFRY&e=

________________________________
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image002.png (12.8k)

Chris Tee

DB2 z/OS DDF connection failure after upgrade to V12
(in response to Horacio Villa)
Horacio

Try the V12 Managing Security manual, chapter 3 page 177. Are you using SNA or TCP/IP between your subsystems? DSGs or standalone subsystems?

regards

Chris

________________________________
From: Horacio Villa <[login to unmask email]>
Sent: 08 June 2020 20:04
To: [login to unmask email] <[login to unmask email]>
Subject: [DB2-L] - RE: DB2 z/OS DDF connection failure after upgrade to V12

Hi,

is anywhere some clear explanation on how to set up passtickets?
I tried some time ago with no success.

Horacio

-----End Original Message-----

Horacio Villa

DB2 z/OS DDF connection failure after upgrade to V12
(in response to Aurora Emanuela Dellanno)
Thks Aurora.
I'm not sure that would be helpful to my needs, but thanks.

Horacio

Horacio Villa

DB2 z/OS DDF connection failure after upgrade to V12
(in response to Chris Tee)
Hi Chris,
...............................................................................................................................................................
Are you using SNA or TCP/IP between your subsystems? DSGs or standalone
subsystems?
...............................................................................................................................................................
thanks for your tips.
We are using TCP/IP, DSGs and standalone subsystems.
Horacio

Aurora Emanuela Dellanno

RE: DB2 z/OS DDF connection failure after upgrade to V12
(in response to Colin Raybould)

Hi Colin,

 

well, you would not find any DB2-specifics about pastickets because they are nothing to do with DB2 - the configuration is done at a different level and it's totally transparent to DB2, as it happens (aside from one single task, which is ensuring the correct entries in LUNAMES/IPNAMES, i.e. 'R' in the SECURITY_OUT column of the SYSIBM.IPNAMES or SYSIBM.LUNAMES table).

 

Yes, the redbook you mention is very good for concepts - the CA manuals actually have very good examples with actual syntax (I helped to write these parts years ago because I was helping customers with these and I'm no security person and needed it spelled out in nice and simple and descriptive terms, so I know ;)

 

Have a good weekend y'all.

 

Aurora

 

PS stay safe and healthy

NB black lives matter