I have a small focexec that needs to generate some internal values for a database write, and then update records. So I call the fex via WFServlet, do some amper-varialble setup in FOCUS, then have a Maintain block that loops, sets up a stack for writing, then issues an UPDATE command.

It generally works, but it doesn't dependably work. I get the error above, followed by an Unrecognized Command error for each line of the Maintain block.

I've found a couple of references to this problem dating back to 2008 and a recommendation to set Agent_Refresh to 1 which isn't really an option for a Maintain-heavy server.

This is running on NT, 7.6.11 soon to be 7.7. Are there any alternate recommendations at this point?

J.

This message has been edited. Last edited by: Kerry,

John
This issue stems from Maintain not being generally run in-stream. Maintain wants to start up a new agent but instead uses the current one and I am pretty sure that is what's causing the error. The setting of Agent Refresh took care of this issue by letting Maintain start a new agent.

I am not sure there is another solution that is dependable.

Mark

What effect will that have in an environment where 20 people spend the bulk of their time on complex Maintain screens? Presumably I can't set Agent Refresh within the particular focexec.

J.

You can alleviate some of the issues with agent refresh set to 1 with providing more agents ready to be used. take a look are MAXIMUM and NUMBER_READY.

quote:

This is running on NT

I hope its not NT , but 2003 server or better.

"Alleviate some of the issues" doesn't inspire confidence Mark. "Won't work" and "I don't know" are both reasonable answers here. If we're in uncharted territory I'd like to know that. If I'm stuck I'd like to know that as well.

This is a production system running a major chunk of health care billing. I'm not in a position where alleviating some of the issues is a sufficient solution. I need a fix that works for all users all the time. The server runs with 30 agents ready and 60 maximum to manage a big chunk of people running 40+ Maintain screens and 200+ supporting html and Focus units. It hums. It works fine. This is new material that is not running dependably. Is there a particular part of the Maintain that screws do pooch?

If I can't get a dependable result I need to rewrite all this stuff. If that's the case please let me know. Is there a way to use Agent_Refresh or any other variable within the focexec itself to guarantee a new agent? If not or if you don't know, just say it. I'll find an alternative solution and report back.

Windows 2008 by the way.

J.

quote:

doesn't inspire confidence Mark

Ouch....

I assume this is a persistent maintain app ?

Yes on persistence.

I don't mean to jab at Mark, but I'm in a different position from him. I need to produce a specific result for a specific customer. He's producing a general tool for application creation, and in this case advising on it. If I'm in a bad place I need to be told that.

If need be I can rewrite both of them completely in Maintain and call via MNTCON instead. I little bulky for the level of work I'm doing but if it's gotta be it's gotta be.

J.

This message has been edited. Last edited by: John_Edwards,

Scratch that -- that was you Waz, not Mark replying. Sorry for the disconnect.

J.

Part experience is that non-persistence uses much less resources, its just a bit more work to set it up.

You wouldn't hit this sort of issue.

John

With the resources used by persistent Maintain apps, the overhead of agent_refresh being set to 1 is miniscule. I have quite happily had that scenario and had no issues and no noticeable performance degradation.

To hedge my bets, I converted these to full-blown Maintain units that I run non-persistent. They're just a loop and then an update so it seemed hardly worth the effort, but it appears to be guaranteeing a proper execution. I still have issues passing 700+ IDs to the units via the amper-variables but I'll be able to break them up in JavaScript and beat that problem without too much trouble.

Thanks for all the input folks. This is the place to be for the hard questions.

S.