Home > .NET 2.0 > IBM iSeries .NET Managed Provider

IBM iSeries .NET Managed Provider

May 14, 2007

I have long been a fan of IBM’s midrange server family, whether you want to call it the AS/400, the iSeries, the i5, or the IBM name du jour. Above all else, having the operating system, the hardware, and the database (UDB DB2 for iSeries) is the best thing about the box. My .NET specialty has really become using .NET to communicate with the iSeries. I have been taking advantage of the IBM supplied managed provider, which works great.

EXCEPT: last year, when I switched over to .NET 2.0, I started getting a strange message:

System.ObjectDisposedException was unhandled
Message=”Safe handle has been closed”
Source=”mscorlib”
ObjectName=””
StackTrace:
at System.Runtime.InteropServices.SafeHandle.DangerousRelease()
at System.Threading.RegisteredWaitHandleSafe.Finalize()

This happens on ANY and EVERY program that opens a Connection object to the iSeries server. It took a little while to track down, because the message is never thrown in conjunction with any of the windows code. I even tried using the Debug Exceptions option and set it to stop when the ObjectDisposedException was thrown, but still no joy. Eventually, through trial and error, I was able to determine that it was coming from the IBM.Data.DB2.iSeries code itself. With not much to do about it, and lots of other coding to get done, I carried on knowing in the back of my head that eventually I would have to fix it.

Well, eventually arrived last week. The PC side of my current project went to beta testing last week with the error intact. Needless to say, it quickly made it to my short list of “fix now” type problems. So I’ve done some more research and found the following.

DESCRIPTION OF PROBLEM FIXED FOR APAR SE22506 :
-----------------------------------------------
   When using the IBM.Data.DB2.iSeries .NET provider with
   .NET Framework 2.0, an ObjectDisposedException occurs
   when the application terminates, with a message indicating
   "Safe handle has been closed."  This problem occurs
   because of an incompatible change made in the .NET
   Framework.

CORRECTION FOR APAR SE22506 :
-----------------------------
   This ptf fixes the reported problem.  Note that this is not an
   official support statement for .NET Framework 2.0.  Future
   compatability with .NET Framework 2.0 is not guaranteed.

CIRCUMVENTION FOR APAR SE22506 :
--------------------------------
   None.

Oooooo-KAY. Did I read that right? “This problem occurs because of an incompatible change made in the .NET Framework” IBM says the problem is with the Framework, but isn’t the responsibility of the Managed Provider PROVIDER to meet the requirements of the Framework? It’s kind of like Congress saying it’s law making is defective because of the Constitution. Ummm… isn’t that the document that tells YOU how to make the laws?

OH… and I just LOVE this: “Future Compatibility with the .NET Framework is not guaranteed.” Then what is the point of the stinkin’ Provider? I know I know, they are just giving themselves an out. They can’t appear to officially support anything Microsoft does.

This is just more evidence of why I love the IBM machinery, but am not so fond of IBM itself.

BTW, for those looking for the fix, you need to apply the PTF available at the above link. Following the “Supercede Available” links will eventually land you at SI26600. And it is for V5R3, so if you are on an earlier release (like me) … sorry …

UPDATED POST HERE

Advertisements
Categories: .NET 2.0
  1. terry
    May 12, 2010 at 9:46 am

    I had the same problem, it went away when I defined my connection to the ISERIES inside a method instead of at the class level.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: