Hi there.

*** I'm asking for your help about error produced while trying to write in a table. Error is 243, but ISAM is 770 "Bad Fragment id specified", which is internal.

*** I've already told to IBM support. Meanwhile I want to know if somebody out there has knowledge about this.

*** Engine is IDS 11.50 FC6, SO is Solaris 9

***Thanks in advance

*** *** *** *** *** *** *** *** Omar Muñoz

Hi Omar,

I've had the same error, only on version 10, the cause could be
completely different in your case.
Here the cause was a stored procedure created with PDQ > 0 set in the
environment.
When the stored proc was dropped and recreated with PDQ = 0, the
problem disappeared.

HTH

Davorin

Hi.

Actually,that was my case too. I realized that a weekly update statistics ran with pdq=20, including sps. I did as you said and problem dissapeared.

So this issue exists on 11.50 too. I wonder if running a spwith pdq brings problems too.

Thank you

*


----- Original Message ----
From: Davorin Kremenjas <davorin.kremenjas (AT) gmail (DOT) com>
To: informix-list (AT) iiug (DOT) org
Sent: Tue, June 8, 2010 10:58:22 AM
Subject: Re: ERROR 770 on IDS 11.50 FC6

Hi Omar,

I've had the same error, only on version 10, the cause could be
completely different in your case.
Here the cause was a stored procedure created with PDQ > 0 set in the
environment.
When the stored proc was dropped and recreated with PDQ = 0, the
problem disappeared.

HTH

Davorin
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Hi Omar,

If you want to run any specific stored procedure with PDQ you still
can, just set the PDQ inside the body of the procedure (and possibly
reset it at the end, not sure if it gets reset automatically after the
exit, it's been over a year when this issue occurred here).

HTH

Davorin

There sems to be a bug (?) that is not very widely advertised - When
running stats in a daily/weekly script, run stats for the procs first
with no pdq being set.
Then set pdq to your liking and run table stats. i have never heard an
explanation - official or otherwise - why setting pdq and running
stats over procs does "weird" things but apparently it sure does.
Maybe you can include this in your communications to IBM support.
Tom

If you compile/recompile your SPL procedures (ie update statistics) with
PDQPRIORITY set they will always run with that priority. My dostats utility
will change PDQPRIORITY to zero (unless you tell it otherwise) before
recompiling your stored procedures for that reason. There are lots of odd
things that happen when you have a procedure that's compiled with a non-zero
PDQPRIORITY. I have seen any session that runs such a proc grab PDQ
resources and never release them, odd locks on catalog tables, etc. No one
has ever explained why this is or reported that it's being fixed (I reported
it to Informix first many years ago). Bottom line, as Tom says, don't
compile any procedure with non-zero PDQPRIORITY unless there is a specific
reason for doing so and you have tested it thoroughly.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) 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 Sat, Jun 12, 2010 at 11:12 AM, Tom Lehr <tomcaml (AT) gmail (DOT) com> wrote: