overflow - which file

[Database Administrator]

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)

[Database Administrator]

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

[Database Administrator]

On Nov 12, 10:49*am, "frosty" 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.

[Database Administrator]

On Nov 12, 11:30*am, Sean Chapman wrote:
> On Nov 12, 10:49*am, "frosty" 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?

[Database Administrator]

On Nov 12, 3:48*pm, Sean Chapman wrote:
> On Nov 12, 11:30*am, Sean Chapman wrote:
>
>
>
> > On Nov 12, 10:49*am, "frosty" 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?

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

[Database Administrator]

Dale's technique reminds me of an old trick that should work on Sean's
D3 AIX but doesn't apply to Windows. When the process hits the
overflow condition, do a POVF (A) command and look at the list of
frames that are available. Then C to continue, then do another POVF
(A). Look for frames missing from the second listing that were
present in the first. DUMP fid (LU) to trace the links of that frame
all the way back to the base, as Dale suggests. DUMP the frame and
just look at what's in there. If the data repeats ad infinitum then
there is a bug somewhere. If there is simply a long list of item IDs
then perhaps the software is only doing what was asked of it.

The chances higher that mv.NET is the culprit if something new is only
happening after you load a new release of mv.NET. However, as I
recall, D3 AIX v7.4.2 was also plagued with various issues that
required a couple hundred patches. It's now very old, and you could
be looking at an old bug that is only triggered by some new code
sequence in mv.NET - not necessarily a bug with mv.NET itself. At
this point obviously there isn't enough info to even guess.

Since we're here, for any Nebula R&D clients who have mv.NET. I've
installed the new v4.0 release software and am carefully checking it
on the platforms we support. I think it's better to do this sort of
research before distributing the software to our client base, so I
have not yet announced availability (emails will probably be sent on
Friday). This is one of the services we provide for our clients and I
thank you for the opportunity and your patience. (Yes, I practice
what I preach.)

mv.NET v4 has enhancements to make it significantly faster for D3, and
I welcome inquiries from anyone who wants to re-evaluate the product
after I've had a chance to verify the functionality.

HTH

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide,
and provides related development and training services



Dale wrote:
>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