DB2 z/os and .Net

John Panopoulos

DB2 z/os and .Net
I have an application server running Windows 2003 and IIS.

I have a Web application in the server that access DB2 though DB2.Net
Provider.

CLI does not use ODBC to access DB2 database on the z/os mainframe.

I am getting a quite good performance.

What is your opinion about mixing these two technologies?



Using IBM's BMC tool I found out that fetching 72000 rows requires about
72 fetches of 99 rows per fetch?

This is something that DB2.Net Provider or DB2 does for maximizing
performance?

My query is a dynamic sql by I could also use a store procedure...

I have not used any multi row fetch technique....


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************


IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion listserv that are being implemented to improve reliability and the overall user experience of DB2-L. These changes are coming on November 30th. Details at http://www.idug.org

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

John Miller

Re: DB2 z/os and .Net
(in response to John Panopoulos)
John,

We use the DB2.NET Provider to access DB2 on the z/os mainframe. We use
the provider to call a mixture of SQL and COBOL stored procedures. This
works very well for us and we also see quite good performance. Your
statement that CLI does not use ODBC is correct, but keep in mind that
the reverse is true, ODBC uses CLI. The .NET provider also uses CLI to
access the database. In my opinion, if done properly the .NET provider
is a very good language for accessing DB2 from the windows platform. Be
sure that you handle your transactions properly, if you do not embed
your database access within the DB2Transaction class then AUTOCOMMIT is
turned on automatically for you and you cannot control your unit of
work.



The fetching info that you are seeing is valid (I think, I'm assuming
you mean 720 fetches or 7200 rows?). This is because multi-row fetch is
being used automatically for you as long as your return cursor is
non-ambiguous (i.e. specify FOR READ ONLY or FOR FETCH ONLY) and you are
at least in v8 CM mode.



John Miller



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of John Panopoulos
Sent: Thursday, November 29, 2007 12:21 AM
To: [login to unmask email]
Subject: [DB2-L] DB2 z/os and .Net



I have an application server running Windows 2003 and IIS.

I have a Web application in the server that access DB2 though DB2.Net
Provider.

CLI does not use ODBC to access DB2 database on the z/os mainframe.

I am getting a quite good performance.

What is your opinion about mixing these two technologies?



Using IBM's BMC tool I found out that fetching 72000 rows requires about
72 fetches of 99 rows per fetch?

This is something that DB2.Net Provider or DB2 does for maximizing
performance?

My query is a dynamic sql by I could also use a store procedure...

I have not used any multi row fetch technique....

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

This email and any files transmitted with it are confidential and

intended solely for the use of the individual or entity to whom they

are addressed. If you have received this email in error please notify

the system manager.

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



IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion
listserv that are being implemented to improve reliability and the
overall user experience of DB2-L. These changes are coming on November
30th. Details at http://www.idug.org

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


The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. Any unauthorized review, distribution or other use of or the taking of any action in reliance upon this information is prohibited. If you receive this in error, please contact the sender and delete or destroy this message and any copies.

IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion listserv that are being implemented to improve reliability and the overall user experience of DB2-L. These changes are coming on November 30th. Details at http://www.idug.org

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