Re: LPAR to LPAR access

[Timothy Sipples]

Kees Vernooij wrote:
>Our DB2 experts confirm this, but think that you need a
>DB2/CONNECT license to make it working.

Good news: that's not correct. DB2 Connect licensing is not required when
the JDBC client is running on z/OS, when connecting to Db2 for z/OS. I'll
quote from IBM's Db2 Version 12 for z/OS announcement letter:

"Non-chargeable feature of DB2 12 for z/OS:
z/OS Application Connectivity to DB2 for z/OS consists of Universal
Database Driver for z/OS Java™ Edition, a pure Java type 4 JDBC driver. It
is designed to deliver high performance and scalable remote connectivity
for Java-based enterprise applications on z/OS to a remote DB2 for z/OS
database server."

So, just order the "z/OS Application Connectivity to DB2 for z/OS" feature,
a no additional charge part of Db2 for z/OS, and you're all set.

The Type 2 (intra LPAR) JDBC driver is included with base Db2 for z/OS, as
I recall, so that base should be well covered, too.

That said, I can think of a licensing-related caution. If you're running
Db2 Value Unit Edition (VUE), a Solution Edition involving Db2, Db2 in a
zNALC LPAR, or some other special Db2 license, then just be careful that
the clients connecting to that Db2 instance -- including z/OS clients --
are consistent with whatever Db2 license terms you have.

As always, "ask your friendly IBM representative" for the official answers.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: LPAR to LPAR access

[Vernooij, Kees (ITOPT1) - KLM]

Our DB2 experts confirm this, but think that you need a DB2/CONNECT license to 
make it working. 
This eliminates the need to install DB2 and pay the DB2 MSU license for that 
LPAR.

Probably there is experience on the DB2 with this setup.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: 25 September, 2017 20:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> My understanding is the JDBC "Type 4" (pure Java) client for DB2 has the
> DRDA protocol "built in", and thus no additional DB2 software is
> required on the client.  I don't know if I've ever actually tried this,
> however, so I may not be correct.
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Peter Hunkeler <p...@gmx.ch>
> Sent: Monday, September 25, 2017 8:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: LPAR to LPAR access
> 
> >You need DDF access to the DB2 that has the data and from
> Lunix/Unix/Windows this can be achieved by installing IBM Data Server
> Client and on z/OS you must install DB2 to facilitate this. This DB2
> does not need databases, datasharing or Sysplex, only IP connectivity to
> the DB2 with data, but it is the only DDF client for z/OS.
> 
> 
> I understand - but this my be wrong understaning - that Java programs
> can access data bases via JDBC, and this will connect through TCP/IP to
> a suitable DBRM on the remote host. Does our statement mean that running
> such a Java program on z/OS would need a local DB2?
> 
> 
> --
> Peter Hunkeler
> 
> 
> 
> 
> 
> --
> 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: LPAR to LPAR access

[Frank Swarbrick]

My understanding is the JDBC "Type 4" (pure Java) client for DB2 has the DRDA 
protocol "built in", and thus no additional DB2 software is required on the 
client.  I don't know if I've ever actually tried this, however, so I may not 
be correct.

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Peter Hunkeler <p...@gmx.ch>
Sent: Monday, September 25, 2017 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: LPAR to LPAR access

>You need DDF access to the DB2 that has the data and from Lunix/Unix/Windows 
>this can be achieved by installing IBM Data Server Client and on z/OS you must 
>install DB2 to facilitate this. This DB2 does not need databases, datasharing 
>or Sysplex, only IP connectivity to the DB2 with data, but it is the only DDF 
>client for z/OS.


I understand - but this my be wrong understaning - that Java programs can 
access data bases via JDBC, and this will connect through TCP/IP to a suitable 
DBRM on the remote host. Does our statement mean that running such a Java 
program on z/OS would need a local DB2?


--
Peter Hunkeler





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

AW: Re: LPAR to LPAR access

[Peter Hunkeler]

>You need DDF access to the DB2 that has the data and from Lunix/Unix/Windows 
>this can be achieved by installing IBM Data Server Client and on z/OS you must 
>install DB2 to facilitate this. This DB2 does not need databases, datasharing 
>or Sysplex, only IP connectivity to the DB2 with data, but it is the only DDF 
>client for z/OS.


I understand - but this my be wrong understaning - that Java programs can 
access data bases via JDBC, and this will connect through TCP/IP to a suitable 
DBRM on the remote host. Does our statement mean that running such a Java 
program on z/OS would need a local DB2?


--
Peter Hunkeler





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

Re: LPAR to LPAR access

[Vernooij, Kees (ITOPT1) - KLM]

I checked with my DB2 colleagues to avoid stating things that are not true: 
yes, you are right.

You need DDF access to the DB2 that has the data and from Lunix/Unix/Windows 
this can be achieved by installing IBM Data Server Client and on z/OS you must 
install DB2 to facilitate this. This DB2 does not need databases, datasharing 
or Sysplex, only IP connectivity to the DB2 with data, but it is the only DDF 
client for z/OS.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: 22 September, 2017 18:51
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> I'm confused.  If both the "one and only" DB2 (the database server) and
> the "remote" system are z/OS systems, then as far as I know "DB2 for
> z/OS" has to be set up on both systems.  Are you saying this is not the
> case?
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com>
> Sent: Friday, September 22, 2017 12:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Not on the remote system, if that is what you mean. The remote system
> connects via DDF to 'the one and only' DB2.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Frank Swarbrick
> > Sent: 21 September, 2017 20:35
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: LPAR to LPAR access
> >
> > Still requires the entire DB2 for z/OS setup, and associated started
> > tasks.
> > 
> > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on
> behalf
> > of Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com>
> > Sent: Thursday, September 21, 2017 12:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: LPAR to LPAR access
> >
> > > -----Original Message-----
> > > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On
> > > Behalf Of Peter Hunkeler
> > > Sent: 20 September, 2017 19:56
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: AW: Re: LPAR to LPAR access
> > >
> > >
> > > >Db2 Data sharing isn't the only way to get 2 Db2 subsystems on
> > > different LPAR's to talk to each other. As long as the 2 LPAR's have
> > > some connectivity, TCP/IP etc. in common, it is possible to use Db2
> > > distributed data facility to allow the 2 subsystems to communicate.
> > >
> > >
> > >
> > > But they do *not* currently have Db2 on both LPARs, I understand.
> > She's
> > > looking for options to have Db2 data shipped over to the non-Db2
> LPAR.
> > >
> > >
> >
> > That is what DDF is for, connect to DB2 from a remote system. We use
> it
> > to connect to DB2 from Windows and Linux systems. From other z/OS
> > systems should be similar.
> >
> > Kees.
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> If
> > you are not the addressee, you are notified that no part of the e-mail
> > or any attachment may be disclosed, copied or distributed, and that
> any
> > other action related to this e-mail or attachment is strictly
> > prohibited, and may be unlawful. If you have received this e-mail by
> > error, please notify the sender immediately by return e-mail, and
> delete
> > this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission of this e-mail or any attachments, nor responsible for
> any
> > delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> registered
> > number 33014286
> > 
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM

Re: LPAR to LPAR access

[Frank Swarbrick]

I'm confused.  If both the "one and only" DB2 (the database server) and the 
"remote" system are z/OS systems, then as far as I know "DB2 for z/OS" has to 
be set up on both systems.  Are you saying this is not the case?

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com>
Sent: Friday, September 22, 2017 12:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Not on the remote system, if that is what you mean. The remote system connects 
via DDF to 'the one and only' DB2.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: 21 September, 2017 20:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
>
> Still requires the entire DB2 for z/OS setup, and associated started
> tasks.
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com>
> Sent: Thursday, September 21, 2017 12:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Peter Hunkeler
> > Sent: 20 September, 2017 19:56
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: AW: Re: LPAR to LPAR access
> >
> >
> > >Db2 Data sharing isn't the only way to get 2 Db2 subsystems on
> > different LPAR's to talk to each other. As long as the 2 LPAR's have
> > some connectivity, TCP/IP etc. in common, it is possible to use Db2
> > distributed data facility to allow the 2 subsystems to communicate.
> >
> >
> >
> > But they do *not* currently have Db2 on both LPARs, I understand.
> She's
> > looking for options to have Db2 data shipped over to the non-Db2 LPAR.
> >
> >
>
> That is what DDF is for, connect to DB2 from a remote system. We use it
> to connect to DB2 from Windows and Linux systems. From other z/OS
> systems should be similar.
>
> Kees.
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail
> or any attachment may be disclosed, copied or distributed, and that any
> other action related to this e-mail or attachment is strictly
> prohibited, and may be unlawful. If you have received this e-mail by
> error, please notify the sender immediately by return e-mail, and delete
> this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for any
> delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
> --
> 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286
***

Re: LPAR to LPAR access

[Vernooij, Kees (ITOPT1) - KLM]

Not on the remote system, if that is what you mean. The remote system connects 
via DDF to 'the one and only' DB2.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: 21 September, 2017 20:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Still requires the entire DB2 for z/OS setup, and associated started
> tasks.
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com>
> Sent: Thursday, September 21, 2017 12:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Peter Hunkeler
> > Sent: 20 September, 2017 19:56
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: AW: Re: LPAR to LPAR access
> >
> >
> > >Db2 Data sharing isn't the only way to get 2 Db2 subsystems on
> > different LPAR's to talk to each other. As long as the 2 LPAR's have
> > some connectivity, TCP/IP etc. in common, it is possible to use Db2
> > distributed data facility to allow the 2 subsystems to communicate.
> >
> >
> >
> > But they do *not* currently have Db2 on both LPARs, I understand.
> She's
> > looking for options to have Db2 data shipped over to the non-Db2 LPAR.
> >
> >
> 
> That is what DDF is for, connect to DB2 from a remote system. We use it
> to connect to DB2 from Windows and Linux systems. From other z/OS
> systems should be similar.
> 
> Kees.
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail
> or any attachment may be disclosed, copied or distributed, and that any
> other action related to this e-mail or attachment is strictly
> prohibited, and may be unlawful. If you have received this e-mail by
> error, please notify the sender immediately by return e-mail, and delete
> this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for any
> delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> --
> 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: LPAR to LPAR access

[Frank Swarbrick]

Still requires the entire DB2 for z/OS setup, and associated started tasks.

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com>
Sent: Thursday, September 21, 2017 12:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: 20 September, 2017 19:56
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: LPAR to LPAR access
>
>
> >Db2 Data sharing isn't the only way to get 2 Db2 subsystems on
> different LPAR's to talk to each other. As long as the 2 LPAR's have
> some connectivity, TCP/IP etc. in common, it is possible to use Db2
> distributed data facility to allow the 2 subsystems to communicate.
>
>
>
> But they do *not* currently have Db2 on both LPARs, I understand. She's
> looking for options to have Db2 data shipped over to the non-Db2 LPAR.
>
>

That is what DDF is for, connect to DB2 from a remote system. We use it to 
connect to DB2 from Windows and Linux systems. From other z/OS systems should 
be similar.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
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: LPAR to LPAR access

[Frank Swarbrick]

Yes, a client-only license would be a "non technical" resolution.  However it 
still requires an entire DB2 server setup on the LPAR, even if no "local 
databases" (other than the communications database and other "system" 
databases) are ever used.

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Timothy Sipples <sipp...@sg.ibm.com>
Sent: Wednesday, September 20, 2017 11:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Frank Swarbrick wrote:
>Does anyone have any insight into the possibility that an RFE to
>have 'client only' code on z/OS would be accepted?

Or a Db2 for z/OS client only license? No idea, but it probably doesn't
hurt to ask.

"Best guess" is that such a construction wouldn't be relevant to Judith's
case. She has Db2 already, so adding Db2 to another LPAR would be
incremental Db2 MSUs, comparatively affordable. (Or maybe not even
incremental MSUs, depending on 4HRA peaks.) Hypothetical client only Db2
code/licensing would presumably be a separate license. Also (and repeating
myself), it's important to compare Db2 data sharing with any other options
on the table, on an "all in" basis. "Don't assume."


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
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: LPAR to LPAR access

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: 20 September, 2017 19:56
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: LPAR to LPAR access
> 
> 
> >Db2 Data sharing isn't the only way to get 2 Db2 subsystems on
> different LPAR's to talk to each other. As long as the 2 LPAR's have
> some connectivity, TCP/IP etc. in common, it is possible to use Db2
> distributed data facility to allow the 2 subsystems to communicate.
> 
> 
> 
> But they do *not* currently have Db2 on both LPARs, I understand. She's
> looking for options to have Db2 data shipped over to the non-Db2 LPAR.
> 
> 

That is what DDF is for, connect to DB2 from a remote system. We use it to 
connect to DB2 from Windows and Linux systems. From other z/OS systems should 
be similar.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: LPAR to LPAR access

[Timothy Sipples]

Frank Swarbrick wrote:
>Does anyone have any insight into the possibility that an RFE to
>have 'client only' code on z/OS would be accepted?

Or a Db2 for z/OS client only license? No idea, but it probably doesn't
hurt to ask.

"Best guess" is that such a construction wouldn't be relevant to Judith's
case. She has Db2 already, so adding Db2 to another LPAR would be
incremental Db2 MSUs, comparatively affordable. (Or maybe not even
incremental MSUs, depending on 4HRA peaks.) Hypothetical client only Db2
code/licensing would presumably be a separate license. Also (and repeating
myself), it's important to compare Db2 data sharing with any other options
on the table, on an "all in" basis. "Don't assume."


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: LPAR to LPAR access

[Frank Swarbrick]

I am of the opinion that DB2 (or Db2) on z/OS should separate the "client" 
functions from the server functions.  They do this on almost all of their other 
OS platforms, including VSE.  (Not sure about DB2 for i.)
By doing this one could have DB2 for z/OS run on a single LPAR (as in the 
current example) and be able to access it from other LPARs having only the 
client (DRDA) code.
One could even use it to access off platform DB2 servers without a requirement 
for any DB2 for z/OS server instances.  This would be ideal for us, because 
this is how we are set up.  We used to be a VSE shop and we didn't want to get 
DB2 for VSE (server) because its so "back level" compared to other platforms.  
Instead we purchased only "DB2 Client for VSE", and we had (and have) DB2 
(server) running on Intel Linux.  So the need to run DB2 "server stuff" on z/OS 
when we migrated to z/OS is onerous...  While I would guess there are few if 
any other shops using this particular paradigm, apparently there is at least 
one (!!) who only wants to run DB2 (server) on one LPAR.
Does anyone have any insight into the possibility that an RFE to have 'client 
only' code on z/OS would be accepted?
Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Peter Hunkeler <p...@gmx.ch>
Sent: Wednesday, September 20, 2017 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: LPAR to LPAR access


>Db2 Data sharing isn't the only way to get 2 Db2 subsystems on different 
>LPAR's to talk to each other. As long as the 2 LPAR's have some connectivity, 
>TCP/IP etc. in common, it is possible to use Db2 distributed data facility to 
>allow the 2 subsystems to communicate.



But they do *not* currently have Db2 on both LPARs, I understand. She's looking 
for options to have Db2 data shipped over to the non-Db2 LPAR.


OT: Did IBM marketing morons rebrand DB2 into Db2 to make it easier to type it 
without errors on smartphone and tablet virtual keyboards? But then, they 
should have made it IBM z instead of IBM Z ;-)





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

AW: Re: LPAR to LPAR access

[Peter Hunkeler]

>Db2 Data sharing isn't the only way to get 2 Db2 subsystems on different 
>LPAR's to talk to each other. As long as the 2 LPAR's have some connectivity, 
>TCP/IP etc. in common, it is possible to use Db2 distributed data facility to 
>allow the 2 subsystems to communicate.



But they do *not* currently have Db2 on both LPARs, I understand. She's looking 
for options to have Db2 data shipped over to the non-Db2 LPAR.


OT: Did IBM marketing morons rebrand DB2 into Db2 to make it easier to type it 
without errors on smartphone and tablet virtual keyboards? But then, they 
should have made it IBM z instead of IBM Z ;-)





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

Re: LPAR to LPAR access

[Wayne Driscoll]

Db2 Data sharing isn't the only way to get 2 Db2 subsystems on different LPAR's 
to talk to each other. As long as the 2 LPAR's have some connectivity, TCP/IP 
etc. in common, it is possible to use Db2 distributed data facility to allow 
the 2 subsystems to communicate.
Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Wednesday, September 20, 2017 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Thank you Kees for letting me know. :)

No good way to go for me. :(

Judith Nelson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Wednesday, September 20, 2017 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

If you are referring to Timothy's "DB2 data Sharing", this requires a Parallel 
Sysplex.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Nelson, Judith
> Sent: 20 September, 2017 16:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
>
> Hi Timothy,
> Adding DB2 to the other LPAR sounds more and more the way to go.
>
> Thanks for your response.
>
> Judith Nelson
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Timothy Sipples
> Sent: Wednesday, September 20, 2017 12:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
>
> You can configure your CICS "File Owning Region" (FOR) in CICS TS in
> the LPAR with DB2, then access that FOR from any interconnected CICS
> regions
> -- and from interconnected TXSeries, for that matter. The folks in the
> CICS-L mailing list likely can provide more details if you need them.
> Basically, just put the CICS programs that make DB2 calls in CICS in
> the
> DB2 LPAR, then run whatever non-DB2 CICS programs (that call the DB2-
> related CICS
> programs) you want in your other CICS LPAR(s). It's classic, tried and
> true "TOR/AOR/FOR" separation. (As an aside, nowadays there are also
> "Rules Owning Regions," "Channel Owning Regions," "Mobile Owning
> Regions," and whatever other "owning" regions you want to have as
> architectural best
> practices.)
>
> For batch, CICS's EXCI (external call interface) works via the same
> path.
> If you're using Java (or mixed Java) batch then you can use the JDBC
> Type 4 driver, to pick another example.
>
> HiperSockets and SMC-D LPAR-to-LPAR connectivities are recommended, if
> you can.
>
> It's best if you do some careful analysis to determine whether
> avoiding adding DB2 to this particular LPAR is the right approach. For
> "occasional"
> DB2 access, it's probably OK. For more intensive DB2 access, DB2 data
> sharing is likely going to perform better and be more cost efficient.
>
> --
> --
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected
> from disclosure and may be legally privileged.  If the reader of this
> message is not the intended recipient or an employee or agent
> responsible for delivering this message to the intended recipient, you
> are hereby notified that any disclosure, distribution, copying, or any
> action taken or action omitted in reliance on it, is strictly
> prohibited and may be unlawful.  If you have received this
> communication in error, please notify us immediately by replying to
> this message and destroy the material in its entirety, whether in electronic 
> or hard copy format.
> Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
d

Re: LPAR to LPAR access

[Nelson, Judith]

Thank you Kees for letting me know. :)

No good way to go for me. :( 

Judith Nelson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Wednesday, September 20, 2017 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

If you are referring to Timothy's "DB2 data Sharing", this requires a Parallel 
Sysplex.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Nelson, Judith
> Sent: 20 September, 2017 16:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Hi Timothy,
> Adding DB2 to the other LPAR sounds more and more the way to go.
> 
> Thanks for your response.
> 
> Judith Nelson
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Timothy Sipples
> Sent: Wednesday, September 20, 2017 12:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> You can configure your CICS "File Owning Region" (FOR) in CICS TS in 
> the LPAR with DB2, then access that FOR from any interconnected CICS 
> regions
> -- and from interconnected TXSeries, for that matter. The folks in the 
> CICS-L mailing list likely can provide more details if you need them.
> Basically, just put the CICS programs that make DB2 calls in CICS in 
> the
> DB2 LPAR, then run whatever non-DB2 CICS programs (that call the DB2- 
> related CICS
> programs) you want in your other CICS LPAR(s). It's classic, tried and 
> true "TOR/AOR/FOR" separation. (As an aside, nowadays there are also 
> "Rules Owning Regions," "Channel Owning Regions," "Mobile Owning 
> Regions," and whatever other "owning" regions you want to have as 
> architectural best
> practices.)
> 
> For batch, CICS's EXCI (external call interface) works via the same 
> path.
> If you're using Java (or mixed Java) batch then you can use the JDBC 
> Type 4 driver, to pick another example.
> 
> HiperSockets and SMC-D LPAR-to-LPAR connectivities are recommended, if 
> you can.
> 
> It's best if you do some careful analysis to determine whether 
> avoiding adding DB2 to this particular LPAR is the right approach. For 
> "occasional"
> DB2 access, it's probably OK. For more intensive DB2 access, DB2 data 
> sharing is likely going to perform better and be more cost efficient.
> 
> --
> --
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> The information contained in this message is confidential, protected 
> from disclosure and may be legally privileged.  If the reader of this 
> message is not the intended recipient or an employee or agent 
> responsible for delivering this message to the intended recipient, you 
> are hereby notified that any disclosure, distribution, copying, or any 
> action taken or action omitted in reliance on it, is strictly 
> prohibited and may be unlawful.  If you have received this 
> communication in error, please notify us immediately by replying to 
> this message and destroy the material in its entirety, whether in electronic 
> or hard copy format.
> Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also k

Re: LPAR to LPAR access

[Vernooij, Kees (ITOPT1) - KLM]

Judith,

If you are referring to Timothy's "DB2 data Sharing", this requires a Parallel 
Sysplex.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nelson, Judith
> Sent: 20 September, 2017 16:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Hi Timothy,
> Adding DB2 to the other LPAR sounds more and more the way to go.
> 
> Thanks for your response.
> 
> Judith Nelson
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Timothy Sipples
> Sent: Wednesday, September 20, 2017 12:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> You can configure your CICS "File Owning Region" (FOR) in CICS TS in the
> LPAR with DB2, then access that FOR from any interconnected CICS regions
> -- and from interconnected TXSeries, for that matter. The folks in the
> CICS-L mailing list likely can provide more details if you need them.
> Basically, just put the CICS programs that make DB2 calls in CICS in the
> DB2 LPAR, then run whatever non-DB2 CICS programs (that call the DB2-
> related CICS
> programs) you want in your other CICS LPAR(s). It's classic, tried and
> true "TOR/AOR/FOR" separation. (As an aside, nowadays there are also
> "Rules Owning Regions," "Channel Owning Regions," "Mobile Owning
> Regions," and whatever other "owning" regions you want to have as
> architectural best
> practices.)
> 
> For batch, CICS's EXCI (external call interface) works via the same
> path.
> If you're using Java (or mixed Java) batch then you can use the JDBC
> Type 4 driver, to pick another example.
> 
> HiperSockets and SMC-D LPAR-to-LPAR connectivities are recommended, if
> you can.
> 
> It's best if you do some careful analysis to determine whether avoiding
> adding DB2 to this particular LPAR is the right approach. For
> "occasional"
> DB2 access, it's probably OK. For more intensive DB2 access, DB2 data
> sharing is likely going to perform better and be more cost efficient.
> 
> 
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> The information contained in this message is confidential, protected
> from disclosure and may be legally privileged.  If the reader of this
> message is not the intended recipient or an employee or agent
> responsible for delivering this message to the intended recipient, you
> are hereby notified that any disclosure, distribution, copying, or any
> action taken or action omitted in reliance on it, is strictly prohibited
> and may be unlawful.  If you have received this communication in error,
> please notify us immediately by replying to this message and destroy the
> material in its entirety, whether in electronic or hard copy format.
> Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: LPAR to LPAR access

[Nelson, Judith]

Hi Timothy, 
Adding DB2 to the other LPAR sounds more and more the way to go. 

Thanks for your response. 

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Wednesday, September 20, 2017 12:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

You can configure your CICS "File Owning Region" (FOR) in CICS TS in the LPAR 
with DB2, then access that FOR from any interconnected CICS regions -- and from 
interconnected TXSeries, for that matter. The folks in the CICS-L mailing list 
likely can provide more details if you need them. Basically, just put the CICS 
programs that make DB2 calls in CICS in the DB2 LPAR, then run whatever non-DB2 
CICS programs (that call the DB2-related CICS
programs) you want in your other CICS LPAR(s). It's classic, tried and true 
"TOR/AOR/FOR" separation. (As an aside, nowadays there are also "Rules Owning 
Regions," "Channel Owning Regions," "Mobile Owning Regions," and whatever other 
"owning" regions you want to have as architectural best
practices.)

For batch, CICS's EXCI (external call interface) works via the same path.
If you're using Java (or mixed Java) batch then you can use the JDBC Type 4 
driver, to pick another example.

HiperSockets and SMC-D LPAR-to-LPAR connectivities are recommended, if you can.

It's best if you do some careful analysis to determine whether avoiding adding 
DB2 to this particular LPAR is the right approach. For "occasional"
DB2 access, it's probably OK. For more intensive DB2 access, DB2 data sharing 
is likely going to perform better and be more cost efficient.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: LPAR to LPAR access

[Nelson, Judith]

Hi Roger, 
Thanks for the head's-up. We are not in a Sysplex. 

Judith Nelson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Lowe
Sent: Tuesday, September 19, 2017 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith/Jerry,
 BMC's product (Subsystem Optimizer for zEnterprise "Subzero") 
requires a BASIC or PARALLEL Sysplex environment. 

Roger

On Tue, 19 Sep 2017 23:30:13 +, Edgington, Jerry 
<jerry.edging...@kroger.com> wrote:

>Yes, Judith. That is correct. I missed that in your email.  However, I believe 
>the BMC tool allows you to connect CICS and maybe batch on one LPAR to DB2 on 
>another LPAR.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 5:43 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Hi Jerry,
>I have looked into the link to the remote database. As far as I 
>understand this is that requires a db2 instance on both LPAR's. :(
>
>Thank you,
>
>Judith Nelson
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 12:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Thank you Jerry!
>
>Judith Nelson
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Edgington, Jerry
>Sent: Tuesday, September 19, 2017 11:25 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Sorry Judith,
>
>Our email system modifies the URL.
>
>I think this link should help with the setup of remote database from DB2 on 
>z/OS.
>www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2
>z_sysibmlocationsds.html,
>
>Here is the BMC tool
>www.bmc.com/it-solutions/subsystem-optimizer.html
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Edgington, Jerry
>Sent: Tuesday, September 19, 2017 12:23 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Judith,
>
>I think this link should help with the setup of remote database from DB2 on 
>z/OS.
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_suppor
>t_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocati
>onsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY
>-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6
>i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=
>
>Here is the BMC tool
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dso
>lutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4
>WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qv
>jC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1
>ldLc-jEYbQmIgw=
>
>Jerry
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 11:53 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Hi Jerry,
>You are correct with your assumption. :)
>
>If I set up the database as remote, wouldn't I still need some kind of a 
>client to connect to it?
>Could you let me know which product from BMC would do this?
>
>Thank you,
>
>Judith Nelson
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Edgington, Jerry
>Sent: Tuesday, September 19, 2017 9:17 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Judith,
>
>I know of a couple of ways to get batch and CICS to access a remote DB2, which 
>is what you are asking, I believe, because you don't want to setup a DB2 data 
>sharing.
>
>1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
>to do this.
>2) BMC has a product that would allow CICS/Batch to connect to a remote 
>DB2, like it is locally attached
>
>
>Jerry
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 10:14 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: LPAR to LPAR access
>
>Hi,
>I am trying to find the best solution for the following problem.
>
>We have two LPARs, one of them has DB2 running, the other one hasn't. We do 
>not have a SYSPLEX.
>We now want to access DB2 data in batch and

Re: LPAR to LPAR access

[Nelson, Judith]

Hi Jerry, 
I'll let my boss talk to them to see if it is affordable. It sure looks like it 
can do what I want. :) 

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 6:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Yes, Judith. That is correct. I missed that in your email.  However, I believe 
the BMC tool allows you to connect CICS and maybe batch on one LPAR to DB2 on 
another LPAR.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
I have looked into the link to the remote database. As far as I understand this 
is that requires a db2 instance on both LPAR's. :(

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Thank you Jerry!

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Sorry Judith,

Our email system modifies the URL.

I think this link should help with the setup of remote database from DB2 on 
z/OS.
www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html,

Here is the BMC tool
www.bmc.com/it-solutions/subsystem-optimizer.html


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I think this link should help with the setup of remote database from DB2 on 
z/OS.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=

Here is the BMC tool
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dsolutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=

Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it?
Could you let me know which product from BMC would do this?

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or

Re: LPAR to LPAR access

[Timothy Sipples]

You can configure your CICS "File Owning Region" (FOR) in CICS TS in the
LPAR with DB2, then access that FOR from any interconnected CICS regions --
and from interconnected TXSeries, for that matter. The folks in the CICS-L
mailing list likely can provide more details if you need them. Basically,
just put the CICS programs that make DB2 calls in CICS in the DB2 LPAR,
then run whatever non-DB2 CICS programs (that call the DB2-related CICS
programs) you want in your other CICS LPAR(s). It's classic, tried and true
"TOR/AOR/FOR" separation. (As an aside, nowadays there are also "Rules
Owning Regions," "Channel Owning Regions," "Mobile Owning Regions," and
whatever other "owning" regions you want to have as architectural best
practices.)

For batch, CICS's EXCI (external call interface) works via the same path.
If you're using Java (or mixed Java) batch then you can use the JDBC Type 4
driver, to pick another example.

HiperSockets and SMC-D LPAR-to-LPAR connectivities are recommended, if you
can.

It's best if you do some careful analysis to determine whether avoiding
adding DB2 to this particular LPAR is the right approach. For "occasional"
DB2 access, it's probably OK. For more intensive DB2 access, DB2 data
sharing is likely going to perform better and be more cost efficient.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: LPAR to LPAR access

[Roger Lowe]

Judith/Jerry,
 BMC's product (Subsystem Optimizer for zEnterprise "Subzero") 
requires a BASIC or PARALLEL Sysplex environment. 

Roger

On Tue, 19 Sep 2017 23:30:13 +, Edgington, Jerry 
<jerry.edging...@kroger.com> wrote:

>Yes, Judith. That is correct. I missed that in your email.  However, I believe 
>the BMC tool allows you to connect CICS and maybe batch on one LPAR to DB2 on 
>another LPAR.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 5:43 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Hi Jerry,
>I have looked into the link to the remote database. As far as I understand 
>this is that requires a db2 instance on both LPAR's. :(
>
>Thank you,
>
>Judith Nelson
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 12:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Thank you Jerry!
>
>Judith Nelson
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Edgington, Jerry
>Sent: Tuesday, September 19, 2017 11:25 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Sorry Judith,
>
>Our email system modifies the URL.
>
>I think this link should help with the setup of remote database from DB2 on 
>z/OS.
>www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html,
>
>Here is the BMC tool
>www.bmc.com/it-solutions/subsystem-optimizer.html
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Edgington, Jerry
>Sent: Tuesday, September 19, 2017 12:23 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Judith,
>
>I think this link should help with the setup of remote database from DB2 on 
>z/OS.
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=
>
>Here is the BMC tool
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dsolutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=
>
>Jerry
>
>-----Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 11:53 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Hi Jerry,
>You are correct with your assumption. :)
>
>If I set up the database as remote, wouldn't I still need some kind of a 
>client to connect to it?
>Could you let me know which product from BMC would do this?
>
>Thank you,
>
>Judith Nelson
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Edgington, Jerry
>Sent: Tuesday, September 19, 2017 9:17 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPAR to LPAR access
>
>Judith,
>
>I know of a couple of ways to get batch and CICS to access a remote DB2, which 
>is what you are asking, I believe, because you don't want to setup a DB2 data 
>sharing.
>
>1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
>to do this.
>2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
>like it is locally attached
>
>
>Jerry
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nelson, Judith
>Sent: Tuesday, September 19, 2017 10:14 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: LPAR to LPAR access
>
>Hi,
>I am trying to find the best solution for the following problem.
>
>We have two LPARs, one of them has DB2 running, the other one hasn't. We do 
>not have a SYSPLEX.
>We now want to access DB2 data in batch and through CICS, from the LPAR that 
>doesn't have DB2 on it.
>
>For the batch side, I looked at ODBC, but I couldn't find anything how to set 
>this up from another z/OS.
>
>I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
>The CICS's are talking. :)
>
>Does anyone have any ideas that could

Re: LPAR to LPAR access

[Edgington, Jerry]

Yes, Judith. That is correct. I missed that in your email.  However, I believe 
the BMC tool allows you to connect CICS and maybe batch on one LPAR to DB2 on 
another LPAR.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
I have looked into the link to the remote database. As far as I understand this 
is that requires a db2 instance on both LPAR's. :(

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Thank you Jerry!

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Sorry Judith,

Our email system modifies the URL.

I think this link should help with the setup of remote database from DB2 on 
z/OS.
www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html,

Here is the BMC tool
www.bmc.com/it-solutions/subsystem-optimizer.html


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I think this link should help with the setup of remote database from DB2 on 
z/OS.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=

Here is the BMC tool
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dsolutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=

Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it?
Could you let me know which product from BMC would do this?

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the ma

Re: LPAR to LPAR access

[Lizette Koehler]

There are also lists that are specific to CICS and DB2 that may be helpful
should you have more questions

To join, if you have not done, go to these URLs.


For DB2 - www.idug.org  

CICShttp://www.listserv.uga.edu/archives/cics-l.html



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nelson, Judith
> Sent: Tuesday, September 19, 2017 10:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Thank you Jerry!
> 
> Judith Nelson
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Edgington, Jerry
> Sent: Tuesday, September 19, 2017 11:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Sorry Judith,
> 
> Our email system modifies the URL.
> 
> I think this link should help with the setup of remote database from DB2 on
> z/OS.
> www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysi
> bmlocationsds.html,
> 
> Here is the BMC tool
> www.bmc.com/it-solutions/subsystem-optimizer.html
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Edgington, Jerry
> Sent: Tuesday, September 19, 2017 12:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Judith,
> 
> I think this link should help with the setup of remote database from DB2 on
> z/OS.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-
> 5F11.0.0_dshare_src_tpc_db2z-
> 5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7yd
> PE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-
> yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=
> 
> Here is the BMC tool
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-
> 2Dsolutions_subsystem-
> 2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY
> -_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-
> yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=
> 
> Jerry
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nelson, Judith
> Sent: Tuesday, September 19, 2017 11:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Hi Jerry,
> You are correct with your assumption. :)
> 
> If I set up the database as remote, wouldn't I still need some kind of a
> client to connect to it?
> Could you let me know which product from BMC would do this?
> 
> Thank you,
> 
> Judith Nelson
> 
> 
> -----Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Edgington, Jerry
> Sent: Tuesday, September 19, 2017 9:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LPAR to LPAR access
> 
> Judith,
> 
> I know of a couple of ways to get batch and CICS to access a remote DB2,
> which is what you are asking, I believe, because you don't want to setup a
> DB2 data sharing.
> 
> 1) Within DB2, you can setup a database as a remote. DB2 admin should know
> how to do this.
> 2) BMC has a product that would allow CICS/Batch to connect to a remote DB2,
> like it is locally attached
> 
> 
> Jerry
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nelson, Judith
> Sent: Tuesday, September 19, 2017 10:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LPAR to LPAR access
> 
> Hi,
> I am trying to find the best solution for the following problem.
> 
> We have two LPARs, one of them has DB2 running, the other one hasn't. We do
> not have a SYSPLEX.
> We now want to access DB2 data in batch and through CICS, from the LPAR that
> doesn't have DB2 on it.
> 
> For the batch side, I looked at ODBC, but I couldn't find anything how to set
> this up from another z/OS.
> 
> I have set up a simple IPIC connection to connect CICS - CICS across LPAR's.
> The CICS's are talking. :)
> 
> Does anyone have any ideas that could help me?
> 
> Judith Nelson  | Senior Systems Programmer
> Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls,
> SD 57193
> Phone: (605) 373-2321
> jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>
> 
> 
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for delivering
> this message to t

Re: LPAR to LPAR access

[Nelson, Judith]

Hi Jerry, 
I have looked into the link to the remote database. As far as I understand this 
is that requires a db2 instance on both LPAR's. :( 

Thank you, 

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Thank you Jerry! 

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Sorry Judith,

Our email system modifies the URL.

I think this link should help with the setup of remote database from DB2 on 
z/OS.
www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html,

Here is the BMC tool
www.bmc.com/it-solutions/subsystem-optimizer.html


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I think this link should help with the setup of remote database from DB2 on 
z/OS.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=

Here is the BMC tool
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dsolutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=

Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it?
Could you let me know which product from BMC would do this?

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
in

Re: LPAR to LPAR access

[Nelson, Judith]

Thank you Jerry! 

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Sorry Judith,

Our email system modifies the URL.

I think this link should help with the setup of remote database from DB2 on 
z/OS.
www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html,

Here is the BMC tool
www.bmc.com/it-solutions/subsystem-optimizer.html


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I think this link should help with the setup of remote database from DB2 on 
z/OS.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=

Here is the BMC tool
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dsolutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=

Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it?
Could you let me know which product from BMC would do this?

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

--
For IB

Re: LPAR to LPAR access

[Edgington, Jerry]

Sorry Judith,

Our email system modifies the URL.

I think this link should help with the setup of remote database from DB2 on 
z/OS.
www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html,

Here is the BMC tool
www.bmc.com/it-solutions/subsystem-optimizer.html


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I think this link should help with the setup of remote database from DB2 on 
z/OS.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEPEK-5F11.0.0_dshare_src_tpc_db2z-5Fsysibmlocationsds.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=sJBowoFLA-8ocnbEpqCKvSdFmT2s355DrFGS5qkZq7M=

Here is the BMC tool
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bmc.com_it-2Dsolutions_subsystem-2Doptimizer.html=DwIFAg=WUZzGzAb7_N4DvMsVhUlFrsw4WYzLoMP5bgx2U7ydPE=gEY-_N3_t4QXFrS5e-OgAibMMWGnLPFFfmDVHG_3lz4=Q2qvjC85EobRWAgHVl-yX2v319f6i9cuTloWg-wjmsE=8dcWbFRJZ5UFFIwGKMcoOv5gW9_-1ldLc-jEYbQmIgw=

Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it?
Could you let me know which product from BMC would do this?

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the 

Re: LPAR to LPAR access

[Edgington, Jerry]

Judith,

I think this link should help with the setup of remote database from DB2 on 
z/OS.
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/dshare/src/tpc/db2z_sysibmlocationsds.html

Here is the BMC tool
http://www.bmc.com/it-solutions/subsystem-optimizer.html

Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Hi Jerry,
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it?
Could you let me know which product from BMC would do this?

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distri

Re: LPAR to LPAR access

[Nelson, Judith]

Hi Jerry, 
You are correct with your assumption. :)

If I set up the database as remote, wouldn't I still need some kind of a client 
to connect to it? 
Could you let me know which product from BMC would do this? 

Thank you,

Judith Nelson


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, September 19, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LPAR to LPAR access

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com<mailto:jnel...@sfgmembers.com>


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: LPAR to LPAR access

[Edgington, Jerry]

Judith,

I know of a couple of ways to get batch and CICS to access a remote DB2, which 
is what you are asking, I believe, because you don't want to setup a DB2 data 
sharing.

1) Within DB2, you can setup a database as a remote. DB2 admin should know how 
to do this.
2) BMC has a product that would allow CICS/Batch to connect to a remote DB2, 
like it is locally attached


Jerry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nelson, Judith
Sent: Tuesday, September 19, 2017 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LPAR to LPAR access

Hi,
I am trying to find the best solution for the following problem.

We have two LPARs, one of them has DB2 running, the other one hasn't. We do not 
have a SYSPLEX.
We now want to access DB2 data in batch and through CICS, from the LPAR that 
doesn't have DB2 on it.

For the batch side, I looked at ODBC, but I couldn't find anything how to set 
this up from another z/OS.

I have set up a simple IPIC connection to connect CICS - CICS across LPAR's. 
The CICS's are talking. :)

Does anyone have any ideas that could help me?

Judith Nelson  | Senior Systems Programmer
Sammons(r) Financial Group Member Companies One Sammons Plaza  | Sioux Falls, 
SD 57193
Phone: (605) 373-2321
jnel...@sfgmembers.com


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

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