We have recently updgraded to version 5.5 and started to use Oracle 9i but are gettting defunct unix sessions (HP-UX 11) if we leave the keyboard alone for approx 5 mins. We don't have any problems if we then continue working but over the course of a day with numerous sessions being used we get a large number of these defunct sessions. As soon as we log out of Pro-IV the associated defunct sessions disappear.
Can somebody give us an idea of what we need to do in order stop this please

Pro-IV / Unix defunct sessions
Started by Mark Snowshall, Jan 24 2006 02:09 PM
5 replies to this topic
#4
Posted 24 January 2006 - 03:04 PM
Not sure whether they are pro or oracle sessions. We get defunct sessions when we are purely editing functions and not actually running the application. When I do a 'ps -ef' I simply get the following where logged on as user news4 :-
ps -ef |grep pts |grep ta
news4 3925 3375 1 14:11:09 pts/ta 0:00
news4 27970 27969 0 08:15:06 pts/ta 0:00 -ksh
news4 4581 3375 1 14:17:25 pts/ta 0:00
news4 3372 27970 0 14:02:46 pts/ta 0:00 /bin/ksh ./mailnet MAC
news4 3376 3375 2 14:02:46 pts/ta 0:00
news4 3375 3372 0 14:02:46 pts/ta 0:07 /usr/local/pro55/bin/pro MAC MDC
news4 4192 3375 1 14:14:10 pts/ta 0:00
iscollect is set as -rwsr-xr-x
As we still have a version of 4.6 running on the same machine while we migrate our old systems over to 5.5, should we be running iscollect_64 which is what is in the 5.5 directory???
ps -ef |grep pts |grep ta
news4 3925 3375 1 14:11:09 pts/ta 0:00
news4 27970 27969 0 08:15:06 pts/ta 0:00 -ksh
news4 4581 3375 1 14:17:25 pts/ta 0:00
news4 3372 27970 0 14:02:46 pts/ta 0:00 /bin/ksh ./mailnet MAC
news4 3376 3375 2 14:02:46 pts/ta 0:00
news4 3375 3372 0 14:02:46 pts/ta 0:07 /usr/local/pro55/bin/pro MAC MDC
news4 4192 3375 1 14:14:10 pts/ta 0:00
iscollect is set as -rwsr-xr-x
As we still have a version of 4.6 running on the same machine while we migrate our old systems over to 5.5, should we be running iscollect_64 which is what is in the 5.5 directory???
#5
Posted 24 January 2006 - 04:20 PM
Mark,
Due to challenges in managing the iscollects, we have shied away from running to version of proIV on one unix box.
I believe that the safest course of action is to make sure that the older version of iscollect is the one that is running.
From our last go around, this is what I remember:
It is definitely not safe to run an older version of ProIV (4.6) with a newer version of iscollect (5.5).
It is typically safer to run a new version of ProIV (5.5) with an older version of iscollect (4.6).
However, there are no guarantees - as the supported solution is have both the pro version and the iscollect version match.
hth,
Joseph
Due to challenges in managing the iscollects, we have shied away from running to version of proIV on one unix box.
I believe that the safest course of action is to make sure that the older version of iscollect is the one that is running.
From our last go around, this is what I remember:
It is definitely not safe to run an older version of ProIV (4.6) with a newer version of iscollect (5.5).
It is typically safer to run a new version of ProIV (5.5) with an older version of iscollect (4.6).
However, there are no guarantees - as the supported solution is have both the pro version and the iscollect version match.
hth,
Joseph
#6
Posted 25 January 2006 - 03:33 PM
Looks like it was iscollect. Have tried a few tests and we now have both iscollect and iscollect_64 processes running on our development server. This seems to have solved the problem without causing any other problems.
We will keep it like this for the next few days then try it on our live server next week. If no problems, then we will keep both running on the live machine until all the systems have been migrated over.
Thanks for the help guys.
We will keep it like this for the next few days then try it on our live server next week. If no problems, then we will keep both running on the live machine until all the systems have been migrated over.
Thanks for the help guys.
Reply to this topic

0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users