Enabled Rdb AIJs causes BAS-F-MEMMANVIO in PowerHouse call to External Product

[David B Sneddon]

Fred,

As a longtime user of BASIC, my first instinct on
the info you supplied would be to increase pgflquo
(try doubling it).

Regards
Dave

[Frederick Hoenisch]

Thanks again All:

The next opportunity to test is this weekend and the first 'load' test is Monday morning.

I'll give it a go and let you know. Thanks for the advice. For this next test, I intend to:

1. Double PGFLQUO for all users of the app.
2. Generate PROCESS dump files.
3. Add more line numbers to MMPREP.

Yours truly,
Fred.

[Ian Miller.]

could there be an issue with the location of the AIJ which is badly handled and leads to the ACCVIO. Is the AIJ file placed on a disk on which there is sufficent free space and that the file and the file and directory protection are correct?

[David B Sneddon]

Ian,

I think the AIJ stuff probably requires some memory
that is blowing the pgflquo value. I have seen our
developers make "small" changes like allocating a
new 10000 element string array and suddenly the
application falls over with ACCVIO errors. Increasing
pgflquo makes it go away. The fact that Fred can't
reproduce it in a test environment suggests that
the quotas in the test environment are probably
different to the production environment.

Dave

[Ian Miller.]

Dave, you are correct that quotas are the first thing to suspect. I was just wondering about other possible causes.

[David B Sneddon]

Yes it may be something else but all MEMMANVIO
errors I have seen over the years have been either
pgflquo issues or recursive/circular calls not
terminating (ending up in stack overflows).
Failure to create/rename files due to insufficient
contiguous space for directories usually manifest
as ACP type errors.

Dave

[David B Sneddon]

Having just re-read the original and the comment
about things breaking when the load increases,
is it possible that there is insufficient pagefile
available? Are there now more users than there
used to be?

[Jan van den Ende]

Fred,

Having read and re-read the whole stream, I am still quite in doubt whether this is to the point for you or not, but since I found no definitive arguments to rule it out, I will just relate our expirience (and workaround).

We first stumbled on it when we tried to implement Clusterwide Logical Names.

In ANY area definition in Rdb (and also DBMS), internally the logical names are evaluated up to the level where a physical or a Concealed Device appears. A Concealed device is then tested to be valid - explicitly - in LNM$SYSTEM_TABLE; EXECUTIVE mode.
Should somehow a reference be made to a data area that does NOT conform, then an Access Violation is generated. How that would trickle down trough Powerhouse is unknown to me.
Oracle was able to confirm our findings (back in febrary 2000), and promised support for clusterwide tables 'in the next release'. We have since been finding it not yet repaired in any following release...

As I started this post with, it might have nothing to do with your problem, but it might well be worth checking.


Proost.

Have one on me.

Jan