IDS Forum

RE: 7.31 to 10X

Posted By: ART KAGEL, BLOOMBERG/ 731 LEXIN
Date: Monday, 14 May 2007, at 11:36 a.m.

In Response To: RE: 7.31 to 10X (George Palmer)

There's no need to FREE a cursor before reopening it. The memory leak you refer
to, IB, happened in certain versions of ESQL/C and IDS if you re-declared a
cursor without freeing it first. Just closing and reopening it will not use any
additional resources, the open does an implied close (unless OPEN/FETCH/CLOSE
optimizations are in effect in which case the last FETCH closes the cursor so
the OPEN does not have to). Anyway, once a CURSOR's been declared there's no
reason that I can think of to redeclare it unless the connection was lost and
had to be reestablished, so even if you are using one of the versions with the
redeclare memory leak you have an application design problem.

Art S. Kagel
----- Original Message -----
From: George Palmer <ids@iiug.org>
At: 5/09 17:44:03

It has been a while but a couple years ago I was involved in a migration
of about 15 applications (mostly written in esql/c migrating from 7.31
to 9.40).

There is an issue an issue that may affect you. In 7.31 if you open a
cursor that has already been opened. The engine will automatically do a
close and free prior to opening the cursor. In the later engines the
close is done but the free is not. You need to do the close and free to
avoid the engine consuming all available memory.

If your application was written using named cursor and took advantage of
the auto close and free. Then you will see the size of the engine
processes grow without bounds while the system runs.

The environment I was working on kept a static number of connections
open, and routed requests through the processes that maintained the
connections.

The clean up from one request to the next was left for the engine to
take care of (which may have been the norm for older applications) at
any rate when we first tested the application with the new engine (using
both the old esql and a new SDK (2.90) the engine would fail when the
memory became exhausted.

I don't really remember much else we had to do. I do remember it took a
lot of convening to get the applications people to fix the code and a
great deal of talking to get QA to do a full regression test.

George

-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
SAMUEL JAKABOWSKI
Sent: Wednesday, May 09, 2007 1:42 PM
To: ids@iiug.org
Subject: 7.31 to 10X [9103]

Hi All,

We are considering migrating our 7.31 environment to 10X. We have around
50
applications that are esql/c based. Will they work with 10X as is?

Thanks

************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.

*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.

Messages In This Thread

• 7.31 to 10X
  SAMUEL JAKABOWSKI -- Wednesday, 9 May 2007, at 4:41 p.m.
  • RE: 7.31 to 10X
    George Palmer -- Wednesday, 9 May 2007, at 5:43 p.m.
    • RE: 7.31 to 10X
      ART KAGEL, BLOOMBERG/ 731 LEXIN -- Monday, 14 May 2007, at 11:36 a.m.
  • Re: 7.31 to 10X
    Mark Jamison -- Thursday, 10 May 2007, at 2:11 p.m.
  • Re: 7.31 to 10X
    Christine Normile -- Thursday, 10 May 2007, at 4:02 p.m.
    • Re: 7.31 to 10X
      SAMUEL JAKABOWSKI -- Thursday, 10 May 2007, at 7:44 p.m.
  • Re: 7.31 to 10X
    ART KAGEL, BLOOMBERG/ 731 LEXIN -- Monday, 14 May 2007, at 11:44 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.