Cannot kill session (onmode -z doesn't work)
On IDS 10 / AIX 5, a JDBC session (PID shown as -1, which simply means a Java client) had ballooned to over 1GB of memory and was making the server swap; onmode -z would not kill it even after hours. Fernando Nunes suggested checking whether memory dropped after the kill, and running 'onstat -g stm <sid>' to see repeated PREPAREs, a common Java application bug. In this case 'onstat -g stm' returned nothing, and the session only went away after a full database shutdown two days later. No real fix was found; opening a PMR with IBM support was recommended in case of an application issue or server memory leak.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
IDS 10
AIX 5
Our server started swapping seriously, and I looked at the sessions using the
most memory:
mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
14247 compans - -1 mtnepp17 1 1545867264 1256744912 off
990910 root - 29740 mtnepp16 1 9289728 8973456 off
1010090 root - 38588 mtnepp16 1 8753152 8567712 off
409418 root - 227618 mtnepp16 1 9232384 8371432 off
2062 root - 1982 mtnepp16 1 8732672 8218912 off
1010418 root - 47034 mtnepp16 1 8314880 7973072 off
524172 root - 307888 mtnepp16 1 8572928 7972744 off
1011113 root - 57346 mtnepp16 1 8441856 7966376 off
The top one, does not have a corresponding PID. It seems like a runaway
process that died, or was killed, and the SID stayed behind.
I tried killing it (onmode -z), but for the last 5 hours it just won't kill
... and I can't shut down the database at this stage (I don't have a downtime
window now).
Any ideas ?
Dirk
________________________________
NOTE: This e-mail message is subject to the MTN Group disclaimer see
http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
Although 5H is way too much, can you check if the memory decreased since you
run onmode -z?
In a situation like this even when it works it takes some time (minutes not
hours). I've seen 15m with more or less the same amount of memory in a
server that was not swapping.
In any case, before you kill the session, run an onstat -g stm SID
This will show you the prepared statements for the session. Most probably
your application is repeating prepares for one or more statements.
Most if not all the situations I've seen (I'd say 80%) are from Java
programs.
Not that Java is inherently bad, but apparently it becomes easier to make
the above mistake.
By the way, the session does have a PID. It's "-1" which signals it's a java
program (in pure Java code there is not (or there was no...) way to get the
process id. That's why it shows -1
In short: I may not be able to help you to kill that session, but it's at
least as important to see why it happened. If it's the prepare problem above
than the application code must be changed.
Regards.
On Sat, Jun 25, 2011 at 1:59 PM, Dirk Cornel.... <moolma_dc@mtn.co.za>wrote:
> IDS 10
> AIX 5
>
> Our server started swapping seriously, and I looked at the sessions using
> the
> most memory:
>
> mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> 14247 compans - -1 mtnepp17 1 1545867264 1256744912 off
> 990910 root - 29740 mtnepp16 1 9289728 8973456 off
> 1010090 root - 38588 mtnepp16 1 8753152 8567712 off
> 409418 root - 227618 mtnepp16 1 9232384 8371432 off
> 2062 root - 1982 mtnepp16 1 8732672 8218912 off
> 1010418 root - 47034 mtnepp16 1 8314880 7973072 off
> 524172 root - 307888 mtnepp16 1 8572928 7972744 off
> 1011113 root - 57346 mtnepp16 1 8441856 7966376 off
>
> The top one, does not have a corresponding PID. It seems like a runaway
> process that died, or was killed, and the SID stayed behind.
>
> I tried killing it (onmode -z), but for the last 5 hours it just won't kill
> .... and I can't shut down the database at this stage (I don't have a
> downtime
> window now).
>
> Any ideas ?
>
> Dirk
>
> ________________________________
> NOTE: This e-mail message is subject to the MTN Group disclaimer see
> http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--0016e6469ad2c5553904a6893aa3
Regarding the killing of the session, I ran and onmode -z on the SID, and it
stayed there for 2 days, until we were allowed to shutdown the database.
:-o
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Fernando Nunes
> Sent: Saturday, 25 June 2011 03:24 PM
> To: ids@iiug.org
> Subject: Re: Cannot kill session (onmode -z doesn't work) [24149]
>
> Although 5H is way too much, can you check if the memory decreased
> since you
> run onmode -z?
> In a situation like this even when it works it takes some time (minutes
> not
> hours). I've seen 15m with more or less the same amount of memory in a
> server that was not swapping.
>
> In any case, before you kill the session, run an onstat -g stm SID
> This will show you the prepared statements for the session. Most
> probably
> your application is repeating prepares for one or more statements.
> Most if not all the situations I've seen (I'd say 80%) are from Java
> programs.
> Not that Java is inherently bad, but apparently it becomes easier to
> make
> the above mistake.
>
> By the way, the session does have a PID. It's "-1" which signals it's a
> java
> program (in pure Java code there is not (or there was no...) way to get
> the
> process id. That's why it shows -1
>
> In short: I may not be able to help you to kill that session, but it's
> at
> least as important to see why it happened. If it's the prepare problem
> above
> than the application code must be changed.
>
> Regards.
> On Sat, Jun 25, 2011 at 1:59 PM, Dirk Cornel....
> <moolma_dc@mtn.co.za>wrote:
>
> > IDS 10
> > AIX 5
> >
> > Our server started swapping seriously, and I looked at the sessions
> using
> > the
> > most memory:
> >
> > mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> > 14247 compans - -1 mtnepp17 1 1545867264 1256744912 off
> > 990910 root - 29740 mtnepp16 1 9289728 8973456 off
> > 1010090 root - 38588 mtnepp16 1 8753152 8567712 off
> > 409418 root - 227618 mtnepp16 1 9232384 8371432 off
> > 2062 root - 1982 mtnepp16 1 8732672 8218912 off
> > 1010418 root - 47034 mtnepp16 1 8314880 7973072 off
> > 524172 root - 307888 mtnepp16 1 8572928 7972744 off
> > 1011113 root - 57346 mtnepp16 1 8441856 7966376 off
> >
> > The top one, does not have a corresponding PID. It seems like a
> runaway
> > process that died, or was killed, and the SID stayed behind.
> >
> > I tried killing it (onmode -z), but for the last 5 hours it just
> won't kill
> > .... and I can't shut down the database at this stage (I don't have a
> > downtime
> > window now).
> >
> > Any ideas ?
> >
> > Dirk
> >
> > ________________________________
> > NOTE: This e-mail message is subject to the MTN Group disclaimer see
> > http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
> >
> >
> >
> >
> ***********************************************************************
> ********
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --0016e6469ad2c5553904a6893aa3
>
>
> ***********************************************************************
> ********
> Forum Note: Use "Reply" to post a response in the discussion forum.
NOTE: This e-mail message is subject to the MTN Group disclaimer see
http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
We are now running into the same problem again. I tried the "onstat -g stm
SID", but it comes back with nothing.
mtnx87.mtn.co.za:/ # onstat -g stm 24416
IBM Informix Dynamic Server Version 10.00.FC8XF -- On-Line -- Up 3 days
12:36:09 -- 157286176 Kbytes
session 24416 ---------------------------------------------------------------sdblock heapsz statement ('*' = Open cursor)
I ran it for the session taking the most memory again -
mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
24416 compans - -1 mtnepp17 1 1104437248 821853816 off
1918648 compans - -1 mtnepp17 1 627732480 627723024 off
213352 root - 393443 mtnepp16 1 12611584 12223256 off
2010236 root - 103699 mtnepp16 1 11874304 11474120 off
1934587 root - 310760 mtnepp16 1 10776576 10772344 off
1900065 root - 17593 mtnepp16 1 10842112 10591824 off
1939737 root - 49782 mtnepp16 1 10203136 9949496 off
1912556 root - 29692 mtnepp16 1 9408512 9191848 off
1949170 root - 56065 mtnepp16 1 9183232 8739384 off
1911515 root - 25919 mtnepp16 1 9027584 8639688 off
1920278 root - 34257 mtnepp16 1 8986624 8380720 off
697526 root - 95294 mtnepp16 1 9277440 8216904 off
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Fernando Nunes
> Sent: Saturday, 25 June 2011 03:24 PM
> To: ids@iiug.org
> Subject: Re: Cannot kill session (onmode -z doesn't work) [24149]
>
> Although 5H is way too much, can you check if the memory decreased
> since you
> run onmode -z?
> In a situation like this even when it works it takes some time (minutes
> not
> hours). I've seen 15m with more or less the same amount of memory in a
> server that was not swapping.
>
> In any case, before you kill the session, run an onstat -g stm SID
> This will show you the prepared statements for the session. Most
> probably
> your application is repeating prepares for one or more statements.
> Most if not all the situations I've seen (I'd say 80%) are from Java
> programs.
> Not that Java is inherently bad, but apparently it becomes easier to
> make
> the above mistake.
>
> By the way, the session does have a PID. It's "-1" which signals it's a
> java
> program (in pure Java code there is not (or there was no...) way to get
> the
> process id. That's why it shows -1
>
> In short: I may not be able to help you to kill that session, but it's
> at
> least as important to see why it happened. If it's the prepare problem
> above
> than the application code must be changed.
>
> Regards.
> On Sat, Jun 25, 2011 at 1:59 PM, Dirk Cornel....
> <moolma_dc@mtn.co.za>wrote:
>
> > IDS 10
> > AIX 5
> >
> > Our server started swapping seriously, and I looked at the sessions
> using
> > the
> > most memory:
> >
> > mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> > 14247 compans - -1 mtnepp17 1 1545867264 1256744912 off
> > 990910 root - 29740 mtnepp16 1 9289728 8973456 off
> > 1010090 root - 38588 mtnepp16 1 8753152 8567712 off
> > 409418 root - 227618 mtnepp16 1 9232384 8371432 off
> > 2062 root - 1982 mtnepp16 1 8732672 8218912 off
> > 1010418 root - 47034 mtnepp16 1 8314880 7973072 off
> > 524172 root - 307888 mtnepp16 1 8572928 7972744 off
> > 1011113 root - 57346 mtnepp16 1 8441856 7966376 off
> >
> > The top one, does not have a corresponding PID. It seems like a
> runaway
> > process that died, or was killed, and the SID stayed behind.
> >
> > I tried killing it (onmode -z), but for the last 5 hours it just
> won't kill
> > .... and I can't shut down the database at this stage (I don't have a
> > downtime
> > window now).
> >
> > Any ideas ?
> >
> > Dirk
> >
> > ________________________________
> > NOTE: This e-mail message is subject to the MTN Group disclaimer see
> > http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
> >
> >
> >
> >
> ***********************************************************************
> ********
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --0016e6469ad2c5553904a6893aa3
>
>
> ***********************************************************************
> ********
> Forum Note: Use "Reply" to post a response in the discussion forum.
NOTE: This e-mail message is subject to the MTN Group disclaimer see
http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
As I mentioned, even a few hours would be more than enough.
You definitively have a very serious issue... those two java sessions are
consuming more than 1.5GB of RAM.
I cannot explain why onstat -g stm sid doesn't show anything... Eventually
they don't have nothing prepared, but I hardly believe that. You can do an
onstat -g ses to check which memory pools are consuming more memory withinthe instance.
In any case, a PMR may be the easiest way to go... Possibly it's only
something in the application, but in that case tech support can help you
find what. On the other hand if there is a memory leak in the server you'd
really need tech support.
Regards.
On Wed, Jun 29, 2011 at 1:01 PM, Dirk Cornel.... <moolma_dc@mtn.co.za>wrote:
> We are now running into the same problem again. I tried the "onstat -g stm
> SID", but it comes back with nothing.
>
> mtnx87.mtn.co.za:/ # onstat -g stm 24416
>
> IBM Informix Dynamic Server Version 10.00.FC8XF -- On-Line -- Up 3 days
> 12:36:09 -- 157286176 Kbytes>
> session 24416
> ---------------------------------------------------------------
> sdblock heapsz statement ('*' = Open cursor)
>
> I ran it for the session taking the most memory again -
>
> mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> 24416 compans - -1 mtnepp17 1 1104437248 821853816 off
> 1918648 compans - -1 mtnepp17 1 627732480 627723024 off
> 213352 root - 393443 mtnepp16 1 12611584 12223256 off
> 2010236 root - 103699 mtnepp16 1 11874304 11474120 off
> 1934587 root - 310760 mtnepp16 1 10776576 10772344 off
> 1900065 root - 17593 mtnepp16 1 10842112 10591824 off
> 1939737 root - 49782 mtnepp16 1 10203136 9949496 off
> 1912556 root - 29692 mtnepp16 1 9408512 9191848 off
> 1949170 root - 56065 mtnepp16 1 9183232 8739384 off
> 1911515 root - 25919 mtnepp16 1 9027584 8639688 off
> 1920278 root - 34257 mtnepp16 1 8986624 8380720 off
> 697526 root - 95294 mtnepp16 1 9277440 8216904 off
>
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Fernando Nunes
> > Sent: Saturday, 25 June 2011 03:24 PM
> > To: ids@iiug.org
> > Subject: Re: Cannot kill session (onmode -z doesn't work) [24149]
> >
> > Although 5H is way too much, can you check if the memory decreased
> > since you
> > run onmode -z?
> > In a situation like this even when it works it takes some time (minutes
> > not
> > hours). I've seen 15m with more or less the same amount of memory in a
> > server that was not swapping.
> >
> > In any case, before you kill the session, run an onstat -g stm SID
> > This will show you the prepared statements for the session. Most
> > probably
> > your application is repeating prepares for one or more statements.
> > Most if not all the situations I've seen (I'd say 80%) are from Java
> > programs.
> > Not that Java is inherently bad, but apparently it becomes easier to
> > make
> > the above mistake.
> >
> > By the way, the session does have a PID. It's "-1" which signals it's a
> > java
> > program (in pure Java code there is not (or there was no...) way to get
> > the
> > process id. That's why it shows -1
> >
> > In short: I may not be able to help you to kill that session, but it's
> > at
> > least as important to see why it happened. If it's the prepare problem
> > above
> > than the application code must be changed.
> >
> > Regards.
>
> > On Sat, Jun 25, 2011 at 1:59 PM, Dirk Cornel....
> > <moolma_dc@mtn.co.za>wrote:
> >
> > > IDS 10
> > > AIX 5
> > >
> > > Our server started swapping seriously, and I looked at the sessions
> > using
> > > the
> > > most memory:
> > >
> > > mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> > > 14247 compans - -1 mtnepp17 1 1545867264 1256744912 off
> > > 990910 root - 29740 mtnepp16 1 9289728 8973456 off
> > > 1010090 root - 38588 mtnepp16 1 8753152 8567712 off
> > > 409418 root - 227618 mtnepp16 1 9232384 8371432 off
> > > 2062 root - 1982 mtnepp16 1 8732672 8218912 off
> > > 1010418 root - 47034 mtnepp16 1 8314880 7973072 off
> > > 524172 root - 307888 mtnepp16 1 8572928 7972744 off
> > > 1011113 root - 57346 mtnepp16 1 8441856 7966376 off
> > >
> > > The top one, does not have a corresponding PID. It seems like a
> > runaway
> > > process that died, or was killed, and the SID stayed behind.
> > >
> > > I tried killing it (onmode -z), but for the last 5 hours it just
> > won't kill
> > > .... and I can't shut down the database at this stage (I don't have a
> > > downtime
> > > window now).
> > >
> > > Any ideas ?
> > >
> > > Dirk
> > >
> > > ________________________________
> > > NOTE: This e-mail message is subject to the MTN Group disclaimer see
> > > http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
> > >
> > >
> > >
> > >
> > ***********************************************************************
> > ********
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --
> > Fernando Nunes
> > Portugal
> >
> > http://informix-technology.blogspot.com
> > My email works... but I don't check it frequently...
> >
> > --0016e6469ad2c5553904a6893aa3
> >
> >
> > ***********************************************************************
> > ********
> > Forum Note: Use "Reply" to post a response in the discussion forum.
>
> NOTE: This e-mail message is subject to the MTN Group disclaimer see
> http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--001636c92c1eee590104a6dd2147
Thanks Fernando.
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Fernando Nunes
> Sent: Wednesday, 29 June 2011 07:30 PM
> To: ids@iiug.org
> Subject: Re: Cannot kill session (onmode -z doesn't work) [24184]
>
> As I mentioned, even a few hours would be more than enough.
> You definitively have a very serious issue... those two java sessions
> are
> consuming more than 1.5GB of RAM.
> I cannot explain why onstat -g stm sid doesn't show anything...
> Eventually
> they don't have nothing prepared, but I hardly believe that. You can do
> an
> onstat -g ses to check which memory pools are consuming more memory> within
> the instance.
>
> In any case, a PMR may be the easiest way to go... Possibly it's only
> something in the application, but in that case tech support can help
> you
> find what. On the other hand if there is a memory leak in the server
> you'd
> really need tech support.
>
> Regards.
> On Wed, Jun 29, 2011 at 1:01 PM, Dirk Cornel....
> <moolma_dc@mtn.co.za>wrote:
>
> > We are now running into the same problem again. I tried the "onstat -
> g stm
> > SID", but it comes back with nothing.
> >
> > mtnx87.mtn.co.za:/ # onstat -g stm 24416
> >
> > IBM Informix Dynamic Server Version 10.00.FC8XF -- On-Line -- Up 3> days
> > 12:36:09 -- 157286176 Kbytes
> >
> > session 24416
> > ---------------------------------------------------------------
> > sdblock heapsz statement ('*' = Open cursor)
> >
> > I ran it for the session taking the most memory again -
> >
> > mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> > 24416 compans - -1 mtnepp17 1 1104437248 821853816 off
> > 1918648 compans - -1 mtnepp17 1 627732480 627723024 off
> > 213352 root - 393443 mtnepp16 1 12611584 12223256 off
> > 2010236 root - 103699 mtnepp16 1 11874304 11474120 off
> > 1934587 root - 310760 mtnepp16 1 10776576 10772344 off
> > 1900065 root - 17593 mtnepp16 1 10842112 10591824 off
> > 1939737 root - 49782 mtnepp16 1 10203136 9949496 off
> > 1912556 root - 29692 mtnepp16 1 9408512 9191848 off
> > 1949170 root - 56065 mtnepp16 1 9183232 8739384 off
> > 1911515 root - 25919 mtnepp16 1 9027584 8639688 off
> > 1920278 root - 34257 mtnepp16 1 8986624 8380720 off
> > 697526 root - 95294 mtnepp16 1 9277440 8216904 off
> >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> Of
> > > Fernando Nunes
> > > Sent: Saturday, 25 June 2011 03:24 PM
> > > To: ids@iiug.org
> > > Subject: Re: Cannot kill session (onmode -z doesn't work) [24149]
> > >
> > > Although 5H is way too much, can you check if the memory decreased
> > > since you
> > > run onmode -z?
> > > In a situation like this even when it works it takes some time
> (minutes
> > > not
> > > hours). I've seen 15m with more or less the same amount of memory
> in a
> > > server that was not swapping.
> > >
> > > In any case, before you kill the session, run an onstat -g stm SID
> > > This will show you the prepared statements for the session. Most
> > > probably
> > > your application is repeating prepares for one or more statements.
> > > Most if not all the situations I've seen (I'd say 80%) are from
> Java
> > > programs.
> > > Not that Java is inherently bad, but apparently it becomes easier
> to
> > > make
> > > the above mistake.
> > >
> > > By the way, the session does have a PID. It's "-1" which signals
> it's a
> > > java
> > > program (in pure Java code there is not (or there was no...) way to
> get
> > > the
> > > process id. That's why it shows -1
> > >
> > > In short: I may not be able to help you to kill that session, but
> it's
> > > at
> > > least as important to see why it happened. If it's the prepare
> problem
> > > above
> > > than the application code must be changed.
> > >
> > > Regards.
> >
> > > On Sat, Jun 25, 2011 at 1:59 PM, Dirk Cornel....
> > > <moolma_dc@mtn.co.za>wrote:
> > >
> > > > IDS 10
> > > > AIX 5
> > > >
> > > > Our server started swapping seriously, and I looked at the
> sessions
> > > using
> > > > the
> > > > most memory:
> > > >
> > > > mtnx87.mtn.co.za:/ # onstat -g ses | sort -nr -k 8 | more
> > > > 14247 compans - -1 mtnepp17 1 1545867264 1256744912 off
> > > > 990910 root - 29740 mtnepp16 1 9289728 8973456 off
> > > > 1010090 root - 38588 mtnepp16 1 8753152 8567712 off
> > > > 409418 root - 227618 mtnepp16 1 9232384 8371432 off
> > > > 2062 root - 1982 mtnepp16 1 8732672 8218912 off
> > > > 1010418 root - 47034 mtnepp16 1 8314880 7973072 off
> > > > 524172 root - 307888 mtnepp16 1 8572928 7972744 off
> > > > 1011113 root - 57346 mtnepp16 1 8441856 7966376 off
> > > >
> > > > The top one, does not have a corresponding PID. It seems like a
> > > runaway
> > > > process that died, or was killed, and the SID stayed behind.
> > > >
> > > > I tried killing it (onmode -z), but for the last 5 hours it just
> > > won't kill
> > > > .... and I can't shut down the database at this stage (I don't
> have a
> > > > downtime
> > > > window now).
> > > >
> > > > Any ideas ?
> > > >
> > > > Dirk
> > > >
> > > > ________________________________
> > > > NOTE: This e-mail message is subject to the MTN Group disclaimer
> see
> > > > http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
> > > >
> > > >
> > > >
> > > >
> > >
> ***********************************************************************
> > > ********
> > > > Forum Note: Use "Reply" to post a response in the discussion
> forum.
> > > >
> > > >
> > >
> > > --
> > > Fernando Nunes
> > > Portugal
> > >
> > > http://informix-technology.blogspot.com
> > > My email works... but I don't check it frequently...
> > >
> > > --0016e6469ad2c5553904a6893aa3
> > >
> > >
> > >
> ***********************************************************************
> > > ********
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> > NOTE: This e-mail message is subject to the MTN Group disclaimer see
> > http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
> >
> >
> >
> >
> ***********************************************************************
> ********
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --001636c92c1eee590104a6dd2147
>
>
> ***********************************************************************
> ********
> Forum Note: Use "Reply" to post a response in the discussion forum.
NOTE: This e-mail message is subject to the MTN Group disclaimer see
http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g