 | |
#31
 
| |||
| |||
|
Re: overflow - which file -
11-12-2008
, 06:38 PM
|
On Nov 12, 11:30*am, Sean Chapman <sean.chap... (AT) gmail (DOT) com> wrote: On Nov 12, 10:49*am, "frosty" <fros... (AT) bogus (DOT) tld> wrote: Sean Chapman wrote: We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run.. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? |
Try a list-locks, there could be a group lock on the group. From
there you could trace the frame back to a base frame and then use the
FOF to find the file. List locks may even show the file, but may not
show the account that the file resides in.
I've had runaways for a number of reasons, many of which I had no
control over (eg. search-system seems to have a problem with gathering
too much disk space)
Other times I was attempting to build a huge string from transfer to
an outside process or XML document. I found in such cases it was just
better to 'print' to a hold file and at the end of the process copy
the hold file out to a windows file system.
I hope that this gives you food for thought that will help solve your
problem.
Regards,
Dale
#32
| |||
| |||
|
|
On Nov 12, 11:30*am, Sean Chapman <sean.chap... (AT) gmail (DOT) com> wrote: On Nov 12, 10:49*am, "frosty" <fros... (AT) bogus (DOT) tld> wrote: Sean Chapman wrote: We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run.. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? |
Try a list-locks, there could be a group lock on the group. From
there you could trace the frame back to a base frame and then use the
FOF to find the file. List locks may even show the file, but may not
show the account that the file resides in.
I've had runaways for a number of reasons, many of which I had no
control over (eg. search-system seems to have a problem with gathering
too much disk space)
Other times I was attempting to build a huge string from transfer to
an outside process or XML document. I found in such cases it was just
better to 'print' to a hold file and at the end of the process copy
the hold file out to a windows file system.
I hope that this gives you food for thought that will help solve your
problem.
Regards,
Dale
#33
| |||
| |||
|
|
On Nov 12, 11:30*am, Sean Chapman <sean.chap... (AT) gmail (DOT) com> wrote: On Nov 12, 10:49*am, "frosty" <fros... (AT) bogus (DOT) tld> wrote: Sean Chapman wrote: We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run.. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? |
Try a list-locks, there could be a group lock on the group. From
there you could trace the frame back to a base frame and then use the
FOF to find the file. List locks may even show the file, but may not
show the account that the file resides in.
I've had runaways for a number of reasons, many of which I had no
control over (eg. search-system seems to have a problem with gathering
too much disk space)
Other times I was attempting to build a huge string from transfer to
an outside process or XML document. I found in such cases it was just
better to 'print' to a hold file and at the end of the process copy
the hold file out to a windows file system.
I hope that this gives you food for thought that will help solve your
problem.
Regards,
Dale
#34
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
#35
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
#36
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
#37
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
#38
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
#39
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
#40
| |||
| |||
|
|
ean wrote We've got some processes that are hitting the Overflow runaway condition detected! continue/quit (c/q)? prompt and I'm trying to narrow down what process/file is being run. Is there any way to find which file is being used by that process or where that write is going? We are seeing them in our list-errors report but from what I see it just shows the account and not the file. (running AIX D3 Release Version *7.4.2.RS) Not all processes that generate overflow runaway condition are updating files; there's lots of other ways to achieve this. What makes you think it's a file update? -- frosty Well, I think it's the temp file that MV.NET uses but I'm uncertain for sure. It has happened since we got our last patch from bluefinity and only on their ports.- Hide quoted text - - Show quoted text - As far as th write goes.. Just came across a port stuck at the runaway :WHERE 904 0904 000AA8 E390 000018 * * *ovf.one.main:5D4 ovf.add:068 br.write:0AC any way to find out what file it's writing to? Grasping at straws here... Try a list-locks, there could be a group lock on the group. From there you could trace the frame back to a base frame and then use the FOF to find the file. List locks may even show the file, but may not show the account that the file resides in. I've had runaways for a number of reasons, many of which I had no control over (eg. search-system seems to have a problem with gathering too much disk space) Other times I was attempting to build a huge string from transfer to an outside process or XML document. I found in such cases it was just better to 'print' to a hold file and at the end of the process copy the hold file out to a windows file system. I hope that this gives you food for thought that will help solve your problem. Regards, Dale |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.