Access SQLServer from z/OS: And a word on DB2 - SQLServer performance.

Hello,

Does anyone know of a method to access SQLServer from the z/OS
environment.

One suggestion was a direct ODBC connection via "mainframe" DB2Connect -
but I am unfamiliar with such a beast at this point.
Second option was to use "Websphere Information Integrator. Basic steps
involve installing Websphere II, federate to SQL Server, then you can
access from z/OS just like the data was on DB2 UDB using DRDA calls. You
could also do bidirectional replication between the DB2/390 and SQL
Server. " I have never done this - but has anyone else.
-------------------

<ramblings>
As an aside - why am I doing this:
It looks like we are moving some data from the DB2 z/OS onto
SQLServer2005 but still need to access some SQLServer data for mainframe
applications. At first I said the performance would not be as good as
our mainframe. Then to prove it I executed tests on SQLServer and z/OS
DB2 with same volume of data - 11 million, 60 mill, 130M million row
tables - table layouts etc and used various queries ... SQLServer
pretty much won the day.

I had to rethink things. How could my DB2-mainframe be out-performed by
the SQLServer box. I did tests on the mainframe on many Sundays with
the machine at about 8% CPU usage ... i.e. the machine was all mine. And
SQLServer still was faster. I did multiple tests to prime buffer pools
etc.

My tests were along the lines of ...
1. Fetch 10 millions rows of data. Force a TS-scan from a single table
to 5 table join with predicates. Tests getting data
2. Count(*) 10-million rows of data varying from a single table to 5
table join with predicates. Test the engine without having to return
data to application. (Hoping the raw M/F power would win the day).

All up I had about 20 tests ...

The mainframe is a 2-engine with a total of 210mips.
The server is a 4GB dual Pentium 3.2GHz. (Each a dual-inline chip to
look like 4-cpu's)

Has anyone else been down this path of comparison and had similar
results.
Perhaps dual Pentiums actually outclass our mainframe CPU - I admit I do
not have a feel for how the chips/cpu-s relate to each other in Intel -
IBM M/F world. Maybe I am comparing a 4-cylinder mainframe with a
V8-Intel. I really do not know. Anyone else?


I never did any real heavy load stress tests - but I did manage about 10
users on SQLServer and things seemed OK. Our particular application is
Data warehouse and the access is by a few people pulling data into
cognos type applications which will rarely visit the database after
that. They then stay in cognos and slice-dice data.



More off topic:
The reason we got down path is that for our data warehouse application,
we needed more DASD. In the meantime we setup UDB on Linux on Intel box
to keep things moving - knowing that it would not be a real option. Got
the DASD in a day so to speak (compare months for M/F). Did some tests
and it was better than M/F. Boss said try SQLServer - yeah right - that
will be a laugh ... and he is still laughing :)...

</ramblings>


Anyway my questions were in the first few lines of this post ...



Thanks
DBA
Glenn Mackey
GuideOne Insurance
Phone: 515.267.5767
Pager: 515.241.1627
Mail Stop: AB1
-----------------------------------------------------------------------




DISCLAIMER:
This message and accompanying documents are covered by the Electronic Communications Privacy Act, 18 U.S.C. ?? 2510-2521, and contains information intended for the specified individual(s) only. This information is confidential. If you are not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, copying, or the taking of any action based on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

We currently use Information Integrator to access SQLServer data from
z/OS applications and it works well. I don't know all the details of
setting up the II instance, as I do the DB2 z/OS support and not the
LUW, but yes, if you set up the nicknames in the II instance to point to
the SQLServer data, then you can access that data from z/OS just as if
it was data in a DB2 LUW instance. I get involved in this because I put
the location information in the z/OS DDF tables to point down to the II
instance.

________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Mackey, Glenn
Sent: Thursday, January 05, 2006 7:46 AM
To: [login to unmask email]
Subject: [DB2-L] Access SQLServer from z/OS: And a word on DB2 -
SQLServer performance.





Hello,

Does anyone know of a method to access SQLServer from the z/OS
environment.

One suggestion was a direct ODBC connection via "mainframe" DB2Connect -
but I am unfamiliar with such a beast at this point.

Second option was to use "Websphere Information Integrator. Basic steps
involve installing Websphere II, federate to SQL Server, then you can
access from z/OS just like the data was on DB2 UDB using DRDA calls. You
could also do bidirectional replication between the DB2/390 and SQL
Server. " I have never done this - but has anyone else.

-------------------

<ramblings>
As an aside - why am I doing this:
It looks like we are moving some data from the DB2 z/OS onto
SQLServer2005 but still need to access some SQLServer data for mainframe
applications. At first I said the performance would not be as good as
our mainframe. Then to prove it I executed tests on SQLServer and z/OS
DB2 with same volume of data - 11 million, 60 mill, 130M million row
tables - table layouts etc and used various queries ... SQLServer
pretty much won the day.

I had to rethink things. How could my DB2-mainframe be out-performed by
the SQLServer box. I did tests on the mainframe on many Sundays with
the machine at about 8% CPU usage ... i.e. the machine was all mine. And
SQLServer still was faster. I did multiple tests to prime buffer pools
etc.

My tests were along the lines of ...
1. Fetch 10 millions rows of data. Force a TS-scan from a single table
to 5 table join with predicates. Tests getting data

2. Count(*) 10-million rows of data varying from a single table to 5
table join with predicates. Test the engine without having to return
data to application. (Hoping the raw M/F power would win the day).

All up I had about 20 tests ...

The mainframe is a 2-engine with a total of 210mips.
The server is a 4GB dual Pentium 3.2GHz. (Each a dual-inline chip to
look like 4-cpu's)

Has anyone else been down this path of comparison and had similar
results.
Perhaps dual Pentiums actually outclass our mainframe CPU - I admit I do
not have a feel for how the chips/cpu-s relate to each other in Intel -
IBM M/F world. Maybe I am comparing a 4-cylinder mainframe with a
V8-Intel. I really do not know. Anyone else?


I never did any real heavy load stress tests - but I did manage about 10
users on SQLServer and things seemed OK. Our particular application is
Data warehouse and the access is by a few people pulling data into
cognos type applications which will rarely visit the database after
that. They then stay in cognos and slice-dice data.



More off topic:
The reason we got down path is that for our data warehouse application,
we needed more DASD. In the meantime we setup UDB on Linux on Intel box
to keep things moving - knowing that it would not be a real option. Got
the DASD in a day so to speak (compare months for M/F). Did some tests
and it was better than M/F. Boss said try SQLServer - yeah right - that
will be a laugh ... and he is still laughing :)...

</ramblings>


Anyway my questions were in the first few lines of this post ...



Thanks
DBA
Glenn Mackey
GuideOne Insurance
Phone: 515.267.5767
Pager: 515.241.1627
Mail Stop: AB1
-----------------------------------------------------------------------


DISCLAIMER:
This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. ?? 2510-2521, and contains
information intended for the specified individual(s) only. This
information is confidential. If you are not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, copying, or the taking of any action based on
the contents of this information is strictly prohibited. If you have
received this communication in error, please notify us immediately by
e-mail, and delete the original message.
------------------------------------------------------------------------
--------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the
archives and home page at http://www.idugdb2-l.org/archives/db2-l.html.
From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Barbara,
Do you know does II support two phase commit between z/OS DB2 v7.1 and SQL Server 2000 or SQL Server 2005?

Serdar

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Barbara Koenen
Sent: Thursday, January 05, 2006 5:31 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Access SQLServer from z/OS: And a word on DB2 - SQLServer performance.


We currently use Information Integrator to access SQLServer data from z/OS applications and it works well. I don't know all the details of setting up the II instance, as I do the DB2 z/OS support and not the LUW, but yes, if you set up the nicknames in the II instance to point to the SQLServer data, then you can access that data from z/OS just as if it was data in a DB2 LUW instance. I get involved in this because I put the location information in the z/OS DDF tables to point down to the II instance.

_____

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Mackey, Glenn
Sent: Thursday, January 05, 2006 7:46 AM
To: [login to unmask email]
Subject: [DB2-L] Access SQLServer from z/OS: And a word on DB2 - SQLServer performance.





Hello,

Does anyone know of a method to access SQLServer from the z/OS environment.

One suggestion was a direct ODBC connection via "mainframe" DB2Connect - but I am unfamiliar with such a beast at this point.

Second option was to use "Websphere Information Integrator. Basic steps involve installing Websphere II, federate to SQL Server, then you can access from z/OS just like the data was on DB2 UDB using DRDA calls. You could also do bidirectional replication between the DB2/390 and SQL Server. " I have never done this - but has anyone else.

-------------------

<ramblings>
As an aside - why am I doing this:
It looks like we are moving some data from the DB2 z/OS onto SQLServer2005 but still need to access some SQLServer data for mainframe applications. At first I said the performance would not be as good as our mainframe. Then to prove it I executed tests on SQLServer and z/OS DB2 with same volume of data - 11 million, 60 mill, 130M million row tables - table layouts etc and used various queries ... SQLServer pretty much won the day.

I had to rethink things. How could my DB2-mainframe be out-performed by the SQLServer box. I did tests on the mainframe on many Sundays with the machine at about 8% CPU usage ... i.e. the machine was all mine. And SQLServer still was faster. I did multiple tests to prime buffer pools etc.

My tests were along the lines of ...
1. Fetch 10 millions rows of data. Force a TS-scan from a single table to 5 table join with predicates. Tests getting data

2. Count(*) 10-million rows of data varying from a single table to 5 table join with predicates. Test the engine without having to return data to application. (Hoping the raw M/F power would win the day).

All up I had about 20 tests ...

The mainframe is a 2-engine with a total of 210mips.
The server is a 4GB dual Pentium 3.2GHz. (Each a dual-inline chip to look like 4-cpu's)

Has anyone else been down this path of comparison and had similar results.
Perhaps dual Pentiums actually outclass our mainframe CPU - I admit I do not have a feel for how the chips/cpu-s relate to each other in Intel - IBM M/F world. Maybe I am comparing a 4-cylinder mainframe with a V8-Intel. I really do not know. Anyone else?


I never did any real heavy load stress tests - but I did manage about 10 users on SQLServer and things seemed OK. Our particular application is Data warehouse and the access is by a few people pulling data into cognos type applications which will rarely visit the database after that. They then stay in cognos and slice-dice data.



More off topic:
The reason we got down path is that for our data warehouse application, we needed more DASD. In the meantime we setup UDB on Linux on Intel box to keep things moving - knowing that it would not be a real option. Got the DASD in a day so to speak (compare months for M/F). Did some tests and it was better than M/F. Boss said try SQLServer - yeah right - that will be a laugh ... and he is still laughing :)...

</ramblings>


Anyway my questions were in the first few lines of this post ...



Thanks
DBA
Glenn Mackey
GuideOne Insurance
Phone: 515.267.5767
Pager: 515.241.1627
Mail Stop: AB1
-----------------------------------------------------------------------




DISCLAIMER:
This message and accompanying documents are covered by the Electronic Communications Privacy Act, 18 U.S.C. ?? 2510-2521, and contains information intended for the specified individual(s) only. This information is confidential. If you are not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, copying, or the taking of any action based on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. --------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm























*************************************************************************************


Bu e-posta ve muhtemel eklerinde verilen bilgiler kiþiye özel ve gizli olup, yalnýzca mesajda belirlenen alýcý ile ilgilidir.Size yanlýþlýkla ulaþmýþsa lütfen göndericiye bilgi veriniz, mesajý siliniz ve içeriðini baþka bir kiþiye açýklamayýnýz, herhangi bir ortama kopyalamayýnýz. Bu mesaj aksi sözleþme ile belirtilmedikçe herhangi bir finansal iþlem teklifi, alýmý, satýmý veya herhangi bir havalenin teyidi gibi bankacýlýk iþlemi yapýlmasý amacýný taþýmamaktadýr.Verilen tüm bilgilerin doðruluðu ve bütünlüðünün garantisi verilmemekte olup, önceden bildirilmeksizin deðiþtirilebilecektir.Bu mesajýn içeriði Bankamýzýn resmi görüþlerini yansýtmayabileceðinden Akbank T.A.Þ. hiçbir hukuki sorumluluðu kabul etmez.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Another lister asked if II supports two phase commit between DB2 on z/OS
and SQLServer. My sources say no, but I would assume the manuals for II
would verify that.

________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Mackey, Glenn
Sent: Thursday, January 05, 2006 7:46 AM
To: [login to unmask email]
Subject: [DB2-L] Access SQLServer from z/OS: And a word on DB2 -
SQLServer performance.





Hello,

Does anyone know of a method to access SQLServer from the z/OS
environment.

One suggestion was a direct ODBC connection via "mainframe" DB2Connect -
but I am unfamiliar with such a beast at this point.

Second option was to use "Websphere Information Integrator. Basic steps
involve installing Websphere II, federate to SQL Server, then you can
access from z/OS just like the data was on DB2 UDB using DRDA calls. You
could also do bidirectional replication between the DB2/390 and SQL
Server. " I have never done this - but has anyone else.

-------------------

<ramblings>
As an aside - why am I doing this:
It looks like we are moving some data from the DB2 z/OS onto
SQLServer2005 but still need to access some SQLServer data for mainframe
applications. At first I said the performance would not be as good as
our mainframe. Then to prove it I executed tests on SQLServer and z/OS
DB2 with same volume of data - 11 million, 60 mill, 130M million row
tables - table layouts etc and used various queries ... SQLServer
pretty much won the day.

I had to rethink things. How could my DB2-mainframe be out-performed by
the SQLServer box. I did tests on the mainframe on many Sundays with
the machine at about 8% CPU usage ... i.e. the machine was all mine. And
SQLServer still was faster. I did multiple tests to prime buffer pools
etc.

My tests were along the lines of ...
1. Fetch 10 millions rows of data. Force a TS-scan from a single table
to 5 table join with predicates. Tests getting data

2. Count(*) 10-million rows of data varying from a single table to 5
table join with predicates. Test the engine without having to return
data to application. (Hoping the raw M/F power would win the day).

All up I had about 20 tests ...

The mainframe is a 2-engine with a total of 210mips.
The server is a 4GB dual Pentium 3.2GHz. (Each a dual-inline chip to
look like 4-cpu's)

Has anyone else been down this path of comparison and had similar
results.
Perhaps dual Pentiums actually outclass our mainframe CPU - I admit I do
not have a feel for how the chips/cpu-s relate to each other in Intel -
IBM M/F world. Maybe I am comparing a 4-cylinder mainframe with a
V8-Intel. I really do not know. Anyone else?


I never did any real heavy load stress tests - but I did manage about 10
users on SQLServer and things seemed OK. Our particular application is
Data warehouse and the access is by a few people pulling data into
cognos type applications which will rarely visit the database after
that. They then stay in cognos and slice-dice data.



More off topic:
The reason we got down path is that for our data warehouse application,
we needed more DASD. In the meantime we setup UDB on Linux on Intel box
to keep things moving - knowing that it would not be a real option. Got
the DASD in a day so to speak (compare months for M/F). Did some tests
and it was better than M/F. Boss said try SQLServer - yeah right - that
will be a laugh ... and he is still laughing :)...

</ramblings>


Anyway my questions were in the first few lines of this post ...



Thanks
DBA
Glenn Mackey
GuideOne Insurance
Phone: 515.267.5767
Pager: 515.241.1627
Mail Stop: AB1
-----------------------------------------------------------------------


DISCLAIMER:
This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. ?? 2510-2521, and contains
information intended for the specified individual(s) only. This
information is confidential. If you are not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, copying, or the taking of any action based on
the contents of this information is strictly prohibited. If you have
received this communication in error, please notify us immediately by
e-mail, and delete the original message.
------------------------------------------------------------------------
--------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the
archives and home page at http://www.idugdb2-l.org/archives/db2-l.html.
From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Glenn,

I was looking for similar information for a project
coming up and found this article
http://www.databasejournal.com/features/mssql/article.php/10894_1756161_1
. I haven't had a chance to try it out yet, and the
date looks a little old, but it may offer some
insights.


--- "Mackey, Glenn" <[login to unmask email]> wrote:

>
>
> Hello,
>
> Does anyone know of a method to access SQLServer
> from the z/OS
> environment.
>
> One suggestion was a direct ODBC connection via
> "mainframe" DB2Connect -
> but I am unfamiliar with such a beast at this point.
> Second option was to use "Websphere Information
> Integrator. Basic steps
> involve installing Websphere II, federate to SQL
> Server, then you can
> access from z/OS just like the data was on DB2 UDB
> using DRDA calls. You
> could also do bidirectional replication between the
> DB2/390 and SQL
> Server. " I have never done this - but has anyone
> else.
> -------------------
>
> <ramblings>
> As an aside - why am I doing this:
> It looks like we are moving some data from the DB2
> z/OS onto
> SQLServer2005 but still need to access some
> SQLServer data for mainframe
> applications. At first I said the performance would
> not be as good as
> our mainframe. Then to prove it I executed tests on
> SQLServer and z/OS
> DB2 with same volume of data - 11 million, 60 mill,
> 130M million row
> tables - table layouts etc and used various queries
> ... SQLServer
> pretty much won the day.
>
> I had to rethink things. How could my DB2-mainframe
> be out-performed by
> the SQLServer box. I did tests on the mainframe on
> many Sundays with
> the machine at about 8% CPU usage ... i.e. the
> machine was all mine. And
> SQLServer still was faster. I did multiple tests to
> prime buffer pools
> etc.
>
> My tests were along the lines of ...
> 1. Fetch 10 millions rows of data. Force a TS-scan
> from a single table
> to 5 table join with predicates. Tests getting data
> 2. Count(*) 10-million rows of data varying from a
> single table to 5
> table join with predicates. Test the engine without
> having to return
> data to application. (Hoping the raw M/F power would
> win the day).
>
> All up I had about 20 tests ...
>
> The mainframe is a 2-engine with a total of 210mips.
> The server is a 4GB dual Pentium 3.2GHz. (Each a
> dual-inline chip to
> look like 4-cpu's)
>
> Has anyone else been down this path of comparison
> and had similar
> results.
> Perhaps dual Pentiums actually outclass our
> mainframe CPU - I admit I do
> not have a feel for how the chips/cpu-s relate to
> each other in Intel -
> IBM M/F world. Maybe I am comparing a 4-cylinder
> mainframe with a
> V8-Intel. I really do not know. Anyone else?
>
>
> I never did any real heavy load stress tests - but I
> did manage about 10
> users on SQLServer and things seemed OK. Our
> particular application is
> Data warehouse and the access is by a few people
> pulling data into
> cognos type applications which will rarely visit the
> database after
> that. They then stay in cognos and slice-dice data.
>
>
>
> More off topic:
> The reason we got down path is that for our data
> warehouse application,
> we needed more DASD. In the meantime we setup UDB on
> Linux on Intel box
> to keep things moving - knowing that it would not be
> a real option. Got
> the DASD in a day so to speak (compare months for
> M/F). Did some tests
> and it was better than M/F. Boss said try SQLServer
> - yeah right - that
> will be a laugh ... and he is still laughing :)...
>
> </ramblings>
>
>
> Anyway my questions were in the first few lines of
> this post ...
>
>
>
> Thanks
> DBA
> Glenn Mackey
> GuideOne Insurance
> Phone: 515.267.5767
> Pager: 515.241.1627
> Mail Stop: AB1
>
-----------------------------------------------------------------------
>
>
>
>
> DISCLAIMER:
> This message and accompanying documents are covered
> by the Electronic Communications Privacy Act, 18
> U.S.C. ?? 2510-2521, and contains information
> intended for the specified individual(s) only. This
> information is confidential. If you are not the
> intended recipient or an agent responsible for
> delivering it to the intended recipient, you are
> hereby notified that you have received this document
> in error and that any review, dissemination,
> copying, or the taking of any action based on the
> contents of this information is strictly prohibited.
> If you have received this communication in error,
> please notify us immediately by e-mail, and delete
> the original message.
>
>
---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go
> to the archives and home page at
> http://www.idugdb2-l.org/archives/db2-l.html. From
> that page select "Join or Leave the list". The IDUG
> DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG
> List Admins can be reached at
> [login to unmask email] Find out the latest
> on IDUG conferences at
> http://conferences.idug.org/index.cfm
>


Regards,
Tony

Send instant messages to your online friends http://au.messenger.yahoo.com

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Just a minor comment on the performance. We don't optimize much for
single thread performance, but rather for the more typical load of
hundreds of tasks, with robust integrity and instrumentation. The power
and value of a mainframe is in the ability to share the data, share the
resources, be highly available, scalable and to take less time for people
because the work is shared. I've been spending quite a bit of time doing
the system maintenance on my pc, installing changes, ... that does not
need to be done thousands of times on a mainframe. The more you share,
the more you want a mainframe.

You also need to work out how many years later you are using for the
comparison processors. I'm guessing that you are using one of the latest
Intel chips, then comparing to either a processor from the late 1990s or
maybe using a z800. With Moore's law still working, the timing is
important, as a six year gap tends to mean about 8 times faster. Disks
have also made dramatic performance improvements in that time frame. So
it does sound as though you have a big V8 Intel or AMD box, comparing it
to an old or small 4 cylinder. But if the auto industry changed at the
speed of computing, we could go to the moon and back on a tank of gas, and
with the prices increasing, we could really use that fuel economy.

Roger Miller

On Thu, 5 Jan 2006 07:46:07 -0600, Mackey, Glenn <[login to unmask email]>
wrote:

>
>
>Hello,
>
>Does anyone know of a method to access SQLServer from the z/OS
>environment.
>
>One suggestion was a direct ODBC connection via "mainframe" DB2Connect -
>but I am unfamiliar with such a beast at this point.
>Second option was to use "Websphere Information Integrator. Basic steps
>involve installing Websphere II, federate to SQL Server, then you can
>access from z/OS just like the data was on DB2 UDB using DRDA calls. You
>could also do bidirectional replication between the DB2/390 and SQL
>Server. " I have never done this - but has anyone else.
>-------------------
>
><ramblings>
>As an aside - why am I doing this:
>It looks like we are moving some data from the DB2 z/OS onto
>SQLServer2005 but still need to access some SQLServer data for mainframe
>applications. At first I said the performance would not be as good as
>our mainframe. Then to prove it I executed tests on SQLServer and z/OS
>DB2 with same volume of data - 11 million, 60 mill, 130M million row
>tables - table layouts etc and used various queries ... SQLServer
>pretty much won the day.
>
>I had to rethink things. How could my DB2-mainframe be out-performed by
>the SQLServer box. I did tests on the mainframe on many Sundays with
>the machine at about 8% CPU usage ... i.e. the machine was all mine. And
>SQLServer still was faster. I did multiple tests to prime buffer pools
>etc.
>
>My tests were along the lines of ...
>1. Fetch 10 millions rows of data. Force a TS-scan from a single table
>to 5 table join with predicates. Tests getting data
>2. Count(*) 10-million rows of data varying from a single table to 5
>table join with predicates. Test the engine without having to return
>data to application. (Hoping the raw M/F power would win the day).
>
>All up I had about 20 tests ...
>
>The mainframe is a 2-engine with a total of 210mips.
>The server is a 4GB dual Pentium 3.2GHz. (Each a dual-inline chip to
>look like 4-cpu's)
>
>Has anyone else been down this path of comparison and had similar
>results.
>Perhaps dual Pentiums actually outclass our mainframe CPU - I admit I do
>not have a feel for how the chips/cpu-s relate to each other in Intel -
>IBM M/F world. Maybe I am comparing a 4-cylinder mainframe with a
>V8-Intel. I really do not know. Anyone else?
>
>
>I never did any real heavy load stress tests - but I did manage about 10
>users on SQLServer and things seemed OK. Our particular application is
>Data warehouse and the access is by a few people pulling data into
>cognos type applications which will rarely visit the database after
>that. They then stay in cognos and slice-dice data.
>
>
>
>More off topic:
>The reason we got down path is that for our data warehouse application,
>we needed more DASD. In the meantime we setup UDB on Linux on Intel box
>to keep things moving - knowing that it would not be a real option. Got
>the DASD in a day so to speak (compare months for M/F). Did some tests
>and it was better than M/F. Boss said try SQLServer - yeah right - that
>will be a laugh ... and he is still laughing :)...
>
></ramblings>
>
>
>Anyway my questions were in the first few lines of this post ...
>
>
>
>Thanks
>DBA
>Glenn Mackey
>GuideOne Insurance
>Phone: 515.267.5767
>Pager: 515.241.1627
>Mail Stop: AB1
>-----------------------------------------------------------------------
>
>
>
>
>DISCLAIMER:
>This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. ?? 2510-2521, and contains
information intended for the specified individual(s) only. This
information is confidential. If you are not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that any
review, dissemination, copying, or the taking of any action based on the
contents of this information is strictly prohibited. If you have received
this communication in error, please notify us immediately by e-mail, and
delete the original message.
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm