7.31 to 10X

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

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.

Hi Samuel, Will I would definitely recommend testing before moving to production your existing applications should work on 10.x as is. There are always exceptions to this rule. There are some caveats to this. For example: Make sure that none of your database objects (tables, stored procedure, indices etc.) use anything in the reserved word list. It has expanded from 7.31 to 10.00 ----- Original Message ---- From: SAMUEL JAKABOWSKI <samuel_jakabowski@wildblue.net> To: ids@iiug.org Sent: Wednesday, May 9, 2007 3:41:52 PM 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.

Your applications will most likely run without requiring changes. However, test them thoroughly. I suggest that you take some baseline performance measurements under IDS 7.31 and capture the query plans of all performance critical queries. Although IDS 10 shows overall better performance in a lab environment than IDS 7.31, performance of specific applications in live environments may require modifications to maintain existing performance baselines or to see a performance improvement. Capturing the performance plans under 7.31 prior to upgrading can help trouble- shoot any performance anomalies that may occur. Christine Normile On May 9, 2007, at 3:41 PM, SAMUEL JAKABOWSKI wrote: > 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. >

Thanks to all for your help. To be on the safe side we would like to install 10X on a different box keeping our 7.31 and spps on the current system. Hopefully we can connect between the two. --Sam

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.

Should work without problems. IFF the existing apps were compiled/linked with ESQL/C v 7.2x you'll have to recompile/relink with a recent SDK version of ESQL/C, but that's all. All of the recent SDK versions will support IDS 10 for any app that does not use v10 specific features (obviously not a problem for you so far). To take advantage of v10 features you'll need to get the most recent version of SDK (2.91 or later IB). Art S. Kagel ----- Original Message ----- From: Samuel Jakabowski <ids@iiug.org> At: 5/09 16:42:27 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.