RPC errors

Let me tap into the Guru experience base. We have an open call with tech support in the UK, but it's been open for a while now (an ongoing issue that we can't seem so solve). I don't have the exact details of the GUI app, but ........ We have a GUI frontend (user's PC, Windows), that connects via a (GUI) server on Unix (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B - dedicated database server running on Tru64). A couple of times a week the users start getting RPC errors, and eventually it gets so bad that we have to reboot the servers. We will then run clean for a couple of days, and then run into the same problem again. Any ideas in troubleshooting & pinpointing this problem ? I know this is probably a broad question, and can have various causes (1st of all network I would guess), etc. But any help / tips / ideas would be appreciated. TIA Dirk

IB that if you look at the server at the time that the users are getting RPC and connection errors you may find that there are many more sessions than there are users currently active. Windows apps are particularly poorly behaved about correctly shutting down IP connections and many UNIXes, TRU64 among them IIRC, do not timeout such defunct connections. That will mean that eventually the TRU64 server will run out of connection resources. You can try implementing keep-alive in the Informix connections and in the TRU64 network device drivers themselves. Also try to discipline your PC users to exit their applications via the menus rather than using the big red 'X' or by simply logging out or shutting down. Unfortunately even when Windows "programmers" (quotes intentional) remember to properly shutdown IP connections on a 'normal' exit they rarely remember to link that shutdown code into the forced quit callback code. Similarly, going home for the night with the apps still running may, depending on your PC policies, result in the users being force logged out over night which is just as bad. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, May 26, 2010 at 1:52 PM, Dc Dirk Moolman <DIRK@za.ibm.com> wrote: > Let me tap into the Guru experience base. We have an open call with tech > support in the UK, but it's been open for a while now (an ongoing issue > that we can't seem so solve). > > I don't have the exact details of the GUI app, but ........ We have a GUI > frontend (user's PC, Windows), that connects via a (GUI) server on Unix > (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B > - dedicated database server running on Tru64). > > A couple of times a week the users start getting RPC errors, and > eventually it gets so bad that we have to reboot the servers. We will > then run clean for a couple of days, and then run into the same problem > again. > > Any ideas in troubleshooting & pinpointing this problem ? I know this is > probably a broad question, and can have various causes (1st of all network > I would guess), etc. But any help / tips / ideas would be appreciated. > > TIA > Dirk > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --00504502bae16f0d6504878314ae

To follow on from Art's good advice, we had similar stuff with Unix apps. An examination of the active sessions allowed us to identify those with no controlling tty and so were 'ripe' for pruning. Furthermore we were able to put code into the app which at app (or workstation) startup looked for active sessions associated with that workstation which must have been carried over from a previous boot/logon/app start and culled them. It wasn't elegant, but it worked.. In your case with the intermediate GUI server, maybe that machine could, as well as being the GUI server, check back with the PC clients to ensure that they're running and if not kill both the GUI session and any associated database session too. That's kind of what the tcp keep-alives should be doing but they've never really worked for me, often leaving sessions active for days after one end has gone away. Have fun, Andy. > To: ids@iiug.org > From: art.kagel@gmail.com > Subject: Re: RPC errors [20232] > Date: Wed, 26 May 2010 14:02:49 -0400 > > IB that if you look at the server at the time that the users are getting RPC > and connection errors you may find that there are many more sessions than > there are users currently active. Windows apps are particularly poorly > behaved about correctly shutting down IP connections and many UNIXes, TRU64 > among them IIRC, do not timeout such defunct connections. That will mean > that eventually the TRU64 server will run out of connection resources. You > can try implementing keep-alive in the Informix connections and in the TRU64 > network device drivers themselves. Also try to discipline your PC users to > exit their applications via the menus rather than using the big red 'X' or > by simply logging out or shutting down. Unfortunately even when Windows > "programmers" (quotes intentional) remember to properly shutdown IP > connections on a 'normal' exit they rarely remember to link that shutdown > code into the forced quit callback code. > > Similarly, going home for the night with the apps still running may, > depending on your PC policies, result in the users being force logged out > over night which is just as bad. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Wed, May 26, 2010 at 1:52 PM, Dc Dirk Moolman <DIRK@za.ibm.com> wrote: > > > Let me tap into the Guru experience base. We have an open call with tech > > support in the UK, but it's been open for a while now (an ongoing issue > > that we can't seem so solve). > > > > I don't have the exact details of the GUI app, but ........ We have a GUI > > frontend (user's PC, Windows), that connects via a (GUI) server on Unix > > (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B > > - dedicated database server running on Tru64). > > > > A couple of times a week the users start getting RPC errors, and > > eventually it gets so bad that we have to reboot the servers. We will > > then run clean for a couple of days, and then run into the same problem > > again. > > > > Any ideas in troubleshooting & pinpointing this problem ? I know this is > > probably a broad question, and can have various causes (1st of all network > > I would guess), etc. But any help / tips / ideas would be appreciated. > > > > TIA > > Dirk > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --00504502bae16f0d6504878314ae > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now

Hi, from your description it is not clear to me, where the RPC error occurs, at the IDS server (passed on to client), or at the client itself (Windows PC), or in the middle (on "server A")? What (I think) I know about the IDS server side ...: - it does not do explicit (direct) RPC calls. - it does implicit RPC calls, this happens when it utilizes certain network services that are implemented using RPC. E.g. DNS lookup, file access on a NFS are candidates. - something like "truss" or "strace" (I don't know what it might be called on True64) could give you some hint ... in that you may be able to figure out whether the error occurs when accessing a NFS file or some network socket. Perhaps you'd see some data (of a write call) that helps identifying the intended action. But most likely the interesting info about OS services calls (like "gethostbyname()") will not be seen :-( I can't say anything about the other two tiers. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Dirk Wittkopp Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 05/26/2010 07:52:29 PM: > > Let me tap into the Guru experience base. We have an open call with tech > support in the UK, but it's been open for a while now (an ongoing issue > that we can't seem so solve). > > I don't have the exact details of the GUI app, but ........ We have a GUI > frontend (user's PC, Windows), that connects via a (GUI) server on Unix > (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B > - dedicated database server running on Tru64). > > A couple of times a week the users start getting RPC errors, and > eventually it gets so bad that we have to reboot the servers. We will > then run clean for a couple of days, and then run into the same problem > again. > > Any ideas in troubleshooting & pinpointing this problem ? I know this is > probably a broad question, and can have various causes (1st of all network > I would guess), etc. But any help / tips / ideas would be appreciated. > > TIA > Dirk > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Thanks guys. I will start looking into the number of sessions versus active users. Just need to rtfm first, a little rusty with the onstat commands at the moment. This problem is getting worse at the moment, and we are now rebooting almost every 2nd day. Thanks for the advise so far. Regards Dirk From: "Andrew Lennard" <andy_lennard@hotmail.com> To: ids@iiug.org Date: 2010/05/27 12:53 AM Subject: RE: RPC errors [20234] Sent by: ids-bounces@iiug.org To follow on from Art's good advice, we had similar stuff with Unix apps. An examination of the active sessions allowed us to identify those with no controlling tty and so were 'ripe' for pruning. Furthermore we were able to put code into the app which at app (or workstation) startup looked for active sessions associated with that workstation which must have been carried over from a previous boot/logon/app start and culled them. It wasn't elegant, but it worked.. In your case with the intermediate GUI server, maybe that machine could, as well as being the GUI server, check back with the PC clients to ensure that they're running and if not kill both the GUI session and any associated database session too. That's kind of what the tcp keep-alives should be doing but they've never really worked for me, often leaving sessions active for days after one end has gone away. Have fun, Andy. > To: ids@iiug.org > From: art.kagel@gmail.com > Subject: Re: RPC errors [20232] > Date: Wed, 26 May 2010 14:02:49 -0400 > > IB that if you look at the server at the time that the users are getting RPC > and connection errors you may find that there are many more sessions than > there are users currently active. Windows apps are particularly poorly > behaved about correctly shutting down IP connections and many UNIXes, TRU64 > among them IIRC, do not timeout such defunct connections. That will mean > that eventually the TRU64 server will run out of connection resources. You > can try implementing keep-alive in the Informix connections and in the TRU64 > network device drivers themselves. Also try to discipline your PC users to > exit their applications via the menus rather than using the big red 'X' or > by simply logging out or shutting down. Unfortunately even when Windows > "programmers" (quotes intentional) remember to properly shutdown IP > connections on a 'normal' exit they rarely remember to link that shutdown > code into the forced quit callback code. > > Similarly, going home for the night with the apps still running may, > depending on your PC policies, result in the users being force logged out > over night which is just as bad. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Wed, May 26, 2010 at 1:52 PM, Dc Dirk Moolman <DIRK@za.ibm.com> wrote: > > > Let me tap into the Guru experience base. We have an open call with tech > > support in the UK, but it's been open for a while now (an ongoing issue > > that we can't seem so solve). > > > > I don't have the exact details of the GUI app, but ........ We have a GUI > > frontend (user's PC, Windows), that connects via a (GUI) server on Unix > > (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B > > - dedicated database server running on Tru64). > > > > A couple of times a week the users start getting RPC errors, and > > eventually it gets so bad that we have to reboot the servers. We will > > then run clean for a couple of days, and then run into the same problem > > again. > > > > Any ideas in troubleshooting & pinpointing this problem ? I know this is > > probably a broad question, and can have various causes (1st of all network > > I would guess), etc. But any help / tips / ideas would be appreciated. > > > > TIA > > Dirk > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --00504502bae16f0d6504878314ae > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

"That will mean that eventually the TRU64 server will run out of connection resources." This means the problem is created on the opsys level, and not at the database level, correct ? I would think so, as on the IDS side the connections are controlled by the NETTYPE parameters, and will be reported in the online.log if exceeded. From: "Art Kagel" <art.kagel@gmail.com> To: ids@iiug.org Date: 2010/05/26 08:03 PM Subject: Re: RPC errors [20232] Sent by: ids-bounces@iiug.org IB that if you look at the server at the time that the users are getting RPC and connection errors you may find that there are many more sessions than there are users currently active. Windows apps are particularly poorly behaved about correctly shutting down IP connections and many UNIXes, TRU64 among them IIRC, do not timeout such defunct connections. That will mean that eventually the TRU64 server will run out of connection resources. You can try implementing keep-alive in the Informix connections and in the TRU64 network device drivers themselves. Also try to discipline your PC users to exit their applications via the menus rather than using the big red 'X' or by simply logging out or shutting down. Unfortunately even when Windows "programmers" (quotes intentional) remember to properly shutdown IP connections on a 'normal' exit they rarely remember to link that shutdown code into the forced quit callback code. Similarly, going home for the night with the apps still running may, depending on your PC policies, result in the users being force logged out over night which is just as bad. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, May 26, 2010 at 1:52 PM, Dc Dirk Moolman <DIRK@za.ibm.com> wrote: > Let me tap into the Guru experience base. We have an open call with tech > support in the UK, but it's been open for a while now (an ongoing issue > that we can't seem so solve). > > I don't have the exact details of the GUI app, but ........ We have a GUI > frontend (user's PC, Windows), that connects via a (GUI) server on Unix > (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B > - dedicated database server running on Tru64). > > A couple of times a week the users start getting RPC errors, and > eventually it gets so bad that we have to reboot the servers. We will > then run clean for a couple of days, and then run into the same problem > again. > > Any ideas in troubleshooting & pinpointing this problem ? I know this is > probably a broad question, and can have various causes (1st of all network > I would guess), etc. But any help / tips / ideas would be appreciated. > > TIA > Dirk > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --00504502bae16f0d6504878314ae ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Correct.. That is what I suspect. Art=20 -----Original Message----- From: Dc Dirk Moolman <DIRK@za.ibm.com> Sent: Thursday, May 27, 2010 10:33 AM To: ids@iiug.org Subject: Fw: RPC errors [20242] "That will mean that eventually the TRU64 server will run out of=20 connection resources."=20 This means the problem is created on the opsys level, and not at the=20 database level, correct ? I would think so, as on the IDS side the=20 connections are controlled by the NETTYPE parameters, and will be reported= =20 in the online.log if exceeded.=20 From:=20 "Art Kagel" <art.kagel@gmail.com>=20 To:=20 ids@iiug.org=20 Date:=20 2010/05/26 08:03 PM=20 Subject:=20 Re: RPC errors [20232]=20 Sent by:=20 ids-bounces@iiug.org=20 IB that if you look at the server at the time that the users are getting=20 RPC=20 and connection errors you may find that there are many more sessions than=20 there are users currently active. Windows apps are particularly poorly=20 behaved about correctly shutting down IP connections and many UNIXes,=20 TRU64=20 among them IIRC, do not timeout such defunct connections. That will mean=20 [The entire original message is not included]=

AFAIR the SQL/code you need for idle/zombie sessions is in the OAT documentation/examples - just copy that and run via OAT or a shell script Cheers Paul -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Dc Dirk Moolman Sent: Thursday, May 27, 2010 8:54 AM To: ids@iiug.org Subject: Fw: RPC errors [20238] Thanks guys. I will start looking into the number of sessions versus active users. Just need to rtfm first, a little rusty with the onstat commands at the moment. This problem is getting worse at the moment, and we are now rebooting almost every 2nd day. Thanks for the advise so far. Regards Dirk From: "Andrew Lennard" <andy_lennard@hotmail.com> To: ids@iiug.org Date: 2010/05/27 12:53 AM Subject: RE: RPC errors [20234] Sent by: ids-bounces@iiug.org To follow on from Art's good advice, we had similar stuff with Unix apps. An examination of the active sessions allowed us to identify those with no controlling tty and so were 'ripe' for pruning. Furthermore we were able to put code into the app which at app (or workstation) startup looked for active sessions associated with that workstation which must have been carried over from a previous boot/logon/app start and culled them. It wasn't elegant, but it worked.. In your case with the intermediate GUI server, maybe that machine could, as well as being the GUI server, check back with the PC clients to ensure that they're running and if not kill both the GUI session and any associated database session too. That's kind of what the tcp keep-alives should be doing but they've never really worked for me, often leaving sessions active for days after one end has gone away. Have fun, Andy. > To: ids@iiug.org > From: art.kagel@gmail.com > Subject: Re: RPC errors [20232] > Date: Wed, 26 May 2010 14:02:49 -0400 > > IB that if you look at the server at the time that the users are getting RPC > and connection errors you may find that there are many more sessions than > there are users currently active. Windows apps are particularly poorly > behaved about correctly shutting down IP connections and many UNIXes, TRU64 > among them IIRC, do not timeout such defunct connections. That will mean > that eventually the TRU64 server will run out of connection resources. You > can try implementing keep-alive in the Informix connections and in the TRU64 > network device drivers themselves. Also try to discipline your PC users to > exit their applications via the menus rather than using the big red 'X' or > by simply logging out or shutting down. Unfortunately even when Windows > "programmers" (quotes intentional) remember to properly shutdown IP > connections on a 'normal' exit they rarely remember to link that shutdown > code into the forced quit callback code. > > Similarly, going home for the night with the apps still running may, > depending on your PC policies, result in the users being force logged out > over night which is just as bad. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Wed, May 26, 2010 at 1:52 PM, Dc Dirk Moolman <DIRK@za.ibm.com> wrote: > > > Let me tap into the Guru experience base. We have an open call with tech > > support in the UK, but it's been open for a while now (an ongoing issue > > that we can't seem so solve). > > > > I don't have the exact details of the GUI app, but ........ We have a GUI > > frontend (user's PC, Windows), that connects via a (GUI) server on Unix > > (on server A, running Tru64), to the database (IDS 10.00 FC8, on server B > > - dedicated database server running on Tru64). > > > > A couple of times a week the users start getting RPC errors, and > > eventually it gets so bad that we have to reboot the servers. We will > > then run clean for a couple of days, and then run into the same problem > > again. > > > > Any ideas in troubleshooting & pinpointing this problem ? I know this is > > probably a broad question, and can have various causes (1st of all network > > I would guess), etc. But any help / tips / ideas would be appreciated. > > > > TIA > > Dirk > > > > > > > > > **************************************************************************** *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --00504502bae16f0d6504878314ae > > > **************************************************************************** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum. **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum. _____ avast! Antivirus <http://www.avast.com>; : Outbound message clean. Virus Database (VPS): 100527-0, 05/27/2010 Tested on: 5/27/2010 10:20:44 AM avast! - copyright (c) 1988-2010 ALWIL Software.

Unfortunately, OAT is not available for version 10 of informix. Which is the latest version that will run on Compaq true 64 > To: ids@iiug.org > From: paul@oninit.com > Subject: RE: RPC errors [20246] > Date: Thu, 27 May 2010 11:20:49 -0400 > > AFAIR the SQL/code you need for idle/zombie sessions is in the OAT > documentation/examples - just copy that and run via OAT or a shell script > > Cheers > Paul > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Dc > Dirk Moolman > Sent: Thursday, May 27, 2010 8:54 AM > To: ids@iiug.org > Subject: Fw: RPC errors [20238] > > Thanks guys. I will start looking into the number of sessions versus > active users. Just need to rtfm first, a little rusty with the onstat > commands at the moment. > > This problem is getting worse at the moment, and we are now rebooting > almost every 2nd day. Thanks for the advise so far. > > Regards > Dirk > > From: > "Andrew Lennard" <andy_lennard@hotmail.com> > To: > ids@iiug.org > Date: > 2010/05/27 12:53 AM > Subject: > RE: RPC errors [20234] > Sent by: > ids-bounces@iiug.org > > To follow on from Art's good advice, we had similar stuff with Unix apps. > An > examination of the active sessions allowed us to identify those with no > controlling tty and so were 'ripe' for pruning. Furthermore we were able > to > put code into the app which at app (or workstation) startup looked for > active > sessions associated with that workstation which must have been carried > over > from a previous boot/logon/app start and culled them. > > It wasn't elegant, but it worked.. > > In your case with the intermediate GUI server, maybe that machine could, > as > well as being the GUI server, check back with the PC clients to ensure > that > they're running and if not kill both the GUI session and any associated > database session too. > > That's kind of what the tcp keep-alives should be doing but they've never > really worked for me, often leaving sessions active for days after one end > has > gone away. > > Have fun, > > Andy. > > > To: ids@iiug.org > > From: art.kagel@gmail.com > > Subject: Re: RPC errors [20232] > > Date: Wed, 26 May 2010 14:02:49 -0400 > > > > IB that if you look at the server at the time that the users are getting > RPC > > and connection errors you may find that there are many more sessions > than > > there are users currently active. Windows apps are particularly poorly > > behaved about correctly shutting down IP connections and many UNIXes, > TRU64 > > among them IIRC, do not timeout such defunct connections. That will mean > > > that eventually the TRU64 server will run out of connection resources. > You > > can try implementing keep-alive in the Informix connections and in the > TRU64 > > network device drivers themselves. Also try to discipline your PC users > to > > exit their applications via the menus rather than using the big red 'X' > or > > by simply logging out or shutting down. Unfortunately even when Windows > > "programmers" (quotes intentional) remember to properly shutdown IP > > connections on a 'normal' exit they rarely remember to link that > shutdown > > code into the forced quit callback code. > > > > Similarly, going home for the night with the apps still running may, > > depending on your PC policies, result in the users being force logged > out > > over night which is just as bad. > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.com) > > IIUG Board of Directors (art@iiug.org) > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other > > organization with which I am associated either explicitly, implicitly, > or by > > inference. Neither do those opinions reflect those of other individuals > > affiliated with any entity with which I am affiliated nor those of the > > entities themselves. > > > > On Wed, May 26, 2010 at 1:52 PM, Dc Dirk Moolman <DIRK@za.ibm.com> > wrote: > > > > > Let me tap into the Guru experience base. We have an open call with > tech > > > support in the UK, but it's been open for a while now (an ongoing > issue > > > that we can't seem so solve). > > > > > > I don't have the exact details of the GUI app, but ........ We have a > GUI > > > frontend (user's PC, Windows), that connects via a (GUI) server on > Unix > > > (on server A, running Tru64), to the database (IDS 10.00 FC8, on > server B > > > - dedicated database server running on Tru64). > > > > > > A couple of times a week the users start getting RPC errors, and > > > eventually it gets so bad that we have to reboot the servers. We will > > > then run clean for a couple of days, and then run into the same > problem > > > again. > > > > > > Any ideas in troubleshooting & pinpointing this problem ? I know this > is > > > probably a broad question, and can have various causes (1st of all > network > > > I would guess), etc. But any help / tips / ideas would be appreciated. > > > > > > > TIA > > > Dirk > > > > > > > > > > > > > > > > **************************************************************************** > *** > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --00504502bae16f0d6504878314ae > > > > > > > > **************************************************************************** > *** > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > _________________________________________________________________ > http://clk.atdmt.com/UKM/go/197222280/direct/01/ > Do you have a story that started on Hotmail? Tell us now > > **************************************************************************** > *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > _____ > > avast! Antivirus <http://www.avast.com>; : Outbound message clean. > > Virus Database (VPS): 100527-0, 05/27/2010 > Tested on: 5/27/2010 10:20:44 AM > avast! - copyright (c) 1988-2010 ALWIL Software. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969