DB2 ON LINUX Z SERIES/390

[smusunuri]

Right now we have DB2 on Z/OS, collecting information on putting DB2 on
Linux zseries. So that our company can save money on Z/OS cpu cycles(or
MIPS).

On our mainframe we have OMEGAMON,CICS,RACF,TSO and PLATINUM tools are
accessing DB2 database. If we do migrate to DB2UDB on LINUX zseries,
then how does the above tools can communicate to newer DB2UDB. Do we
need any product like DB2 Connect ? was this do able ? any known
problems ? I am looking for expertise advice on this.

Does still our old COBOL/CICS programs can still acess newer DB2UDB ?
Do we have to do any special binds ?
How was the DB2UDB performace on Linux z-series ?

We are looking for solution that can work seamless solution and no code
changes

[Philip Nelson]

sm*******@gmail.com wrote:

Right now we have DB2 on Z/OS, collecting information on putting DB2 on
Linux zseries. So that our company can save money on Z/OS cpu cycles(or
MIPS).

On our mainframe we have OMEGAMON,CICS,RACF,TSO and PLATINUM tools are
accessing DB2 database. If we do migrate to DB2UDB on LINUX zseries,
then how does the above tools can communicate to newer DB2UDB. Do we
need any product like DB2 Connect ? was this do able ? any known
problems ? I am looking for expertise advice on this.

Does still our old COBOL/CICS programs can still acess newer DB2UDB ?
Do we have to do any special binds ?
How was the DB2UDB performace on Linux z-series ?

We are looking for solution that can work seamless solution and no code
changes

Wow !!!! Not so fast !!!

I think what you may not have realised that DB2 on Linux on zSeries is, like
all DB2 on Linux flavours, part of the DB2 for Linux, UNIX and Windows
(LUW) family of products as also found on, for example, Linux for Intel,
AIX, Solaris and Windows (there are others). Is is significantly different
in both administration and function to DB2 for z/OS.

So your traditional mainframe tools will, in large part, not be useable.

All access to the DB2 on Linux system from the mainframe will be via DDF
(you don't need DB2 Connect to go outbound to DB2 for LUW, but you will
need DB2 Connect if you want to go from Linux to z/OS).

It is possible to get SPUFI working against a DB2 for LUW database, but it
is painful (and not everything can be run from it).

You definitely won't be able to attach a CICS or IMS/TM region to it.

So before you plan this move you really need to understand that you are
getting into : which is likely a rewrite of all your applications !!!

It would be a different story if you were moving apps currently pointing at
other DB2 for LUW platforms : they should in general move across cleanly.
Another great use for Linux on zSeries is as a consolidating platform for
DB2 Connect gateways. Also if you have z/OS Java / Websphere applications
they would be a lot easier to move to zLinux than traditional COBOL apps.

HTH

Phil Nelson
ScotDB Ltd.

[Frank Swarbrick]

Philip Nelson<te*****@scotdb.com12/20/06 2:37 PM >>>

>sm*******@gmail.com wrote:

>Right now we have DB2 on Z/OS, collecting information on putting DB2 on
Linux zseries. So that our company can save money on Z/OS cpu cycles(or
MIPS).

On our mainframe we have OMEGAMON,CICS,RACF,TSO and PLATINUM tools are
accessing DB2 database. If we do migrate to DB2UDB on LINUX zseries,
then how does the above tools can communicate to newer DB2UDB. Do we
need any product like DB2 Connect ? was this do able ? any known
problems ? I am looking for expertise advice on this.

Does still our old COBOL/CICS programs can still acess newer DB2UDB ?
Do we have to do any special binds ?
How was the DB2UDB performace on Linux z-series ?

We are looking for solution that can work seamless solution and no code
changes

Wow !!!! Not so fast !!!

I think what you may not have realised that DB2 on Linux on zSeries is,

like

>all DB2 on Linux flavours, part of the DB2 for Linux, UNIX and Windows
(LUW) family of products as also found on, for example, Linux for Intel,
AIX, Solaris and Windows (there are others). Is is significantly

different

>in both administration and function to DB2 for z/OS.

So your traditional mainframe tools will, in large part, not be useable.

All access to the DB2 on Linux system from the mainframe will be via DDF
(you don't need DB2 Connect to go outbound to DB2 for LUW, but you will
need DB2 Connect if you want to go from Linux to z/OS).

It is possible to get SPUFI working against a DB2 for LUW database, but it
is painful (and not everything can be run from it).

You definitely won't be able to attach a CICS or IMS/TM region to it.

Well, this is not entirely true. Speaking for VSE, and not z/OS, we are (in
test only, so far) using the DB2/VSE application requestor functionality to
connect a VSE CICS region to DB2/LUW servers (one on zSeries and one on
Intel). (This also works for VSE batch jobs.) The deal here is we have the
entire product "DB2 Server for VSE". We simply don't use the "server"
portion of it. In other words, we have no DB2/VSE databases.

I imagine that you can do the same for z/OS. Just remember, with DB2 for
z/OS you can access remote databases. So this is simply a case of *all* of
the databases being remote databases.

The major caveat being that I don't know if, as with VSE, you have to have
the entire DB2 for z/OS product. With VSE there is a special PRPQ pricing
where you can get a big (?) price break on DB2 Server for VSE if you intend
to only use the "client" (application requestor) functionality, and not have
DB2 databases reside on VSE. I have no idea whether or not this special
pricing is availble for z/OS. Or if, perhaps, z/OS has a separate "client
only" package that you can buy.

But in the end, the point is that you must have the client "piece" in order
to get from the mainframe to an LUW server. But it can be done.

Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

[Philip Nelson]

Frank Swarbrick wrote:

Philip Nelson<te*****@scotdb.com12/20/06 2:37 PM >>>

>>sm*******@gmail.com wrote:

>>Right now we have DB2 on Z/OS, collecting information on putting DB2 on
Linux zseries. So that our company can save money on Z/OS cpu cycles(or
MIPS).

On our mainframe we have OMEGAMON,CICS,RACF,TSO and PLATINUM tools are
accessing DB2 database. If we do migrate to DB2UDB on LINUX zseries,
then how does the above tools can communicate to newer DB2UDB. Do we
need any product like DB2 Connect ? was this do able ? any known
problems ? I am looking for expertise advice on this.

Does still our old COBOL/CICS programs can still acess newer DB2UDB ?
Do we have to do any special binds ?
How was the DB2UDB performace on Linux z-series ?

We are looking for solution that can work seamless solution and no code
changes

Wow !!!! Not so fast !!!

I think what you may not have realised that DB2 on Linux on zSeries is,

like

>>all DB2 on Linux flavours, part of the DB2 for Linux, UNIX and Windows
(LUW) family of products as also found on, for example, Linux for Intel,
AIX, Solaris and Windows (there are others). Is is significantly

different

>>in both administration and function to DB2 for z/OS.

So your traditional mainframe tools will, in large part, not be useable.

All access to the DB2 on Linux system from the mainframe will be via DDF
(you don't need DB2 Connect to go outbound to DB2 for LUW, but you will
need DB2 Connect if you want to go from Linux to z/OS).

It is possible to get SPUFI working against a DB2 for LUW database, but it
is painful (and not everything can be run from it).

You definitely won't be able to attach a CICS or IMS/TM region to it.

Well, this is not entirely true. Speaking for VSE, and not z/OS, we are
(in test only, so far) using the DB2/VSE application requestor
functionality to connect a VSE CICS region to DB2/LUW servers (one on
zSeries and one on
Intel). (This also works for VSE batch jobs.) The deal here is we have
the
entire product "DB2 Server for VSE". We simply don't use the "server"
portion of it. In other words, we have no DB2/VSE databases.

I imagine that you can do the same for z/OS. Just remember, with DB2 for
z/OS you can access remote databases. So this is simply a case of *all*
of the databases being remote databases.

The major caveat being that I don't know if, as with VSE, you have to have
the entire DB2 for z/OS product. With VSE there is a special PRPQ pricing
where you can get a big (?) price break on DB2 Server for VSE if you
intend to only use the "client" (application requestor) functionality, and
not have
DB2 databases reside on VSE. I have no idea whether or not this special
pricing is availble for z/OS. Or if, perhaps, z/OS has a separate "client
only" package that you can buy.

But in the end, the point is that you must have the client "piece" in
order
to get from the mainframe to an LUW server. But it can be done.

Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Frank,

I agree that you can run programs on z/OS which access DB2 for LUW : we do
this with both COBOL and REXX under limited circumstances. In these cases
you are, as you say, using DB2 for z/OS as your AR (client) to the DB2 for
LUW server : probably the most expensive client ever <G!!!

Every time you add a new LUW database you have to add the connection details
into the tables in SYSDDF and recycle DDF to bring these in. And all your
applications are then talking to remote locations, with all the challenges
for binding, security and distributed transaction management.

I'm not sure how well IMS/TM or CICS/TM transactions will run in this setup
(if at all). I guess it can be done. We do have batch jobs which access
both IMS databases on z/OS and DB2 for AIX databases. I don't think we
have ever done it in a transaction or BMP however.

But really all these scenarios are only where you have data on both z/OS and
LUW which you want to access together : and even then it is probably better
done with Information Integrator. For a site going into wholesale use of
DB2 on zLinux as their DBMS of choice, I really think they need to get used
to developing applications outside the CICS/COBOL comfort zone. Not only
because it will be easier in the long run, but also because of performance
reasons.

Phil