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

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 sp with pdq brings problems too. Thank you ----- Original Message ---- From: Davorin Kremenjas <davorin.kremenjas@gmail.com> To: informix-list@iiug.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@iiug.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@iiug.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@gmail.com> wrote: > 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 > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >