Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

Out of String Space (AREV Specific)

At 08 APR 1999 02:27:47PM Dove Pierce wrote:

Suddenly this week we have had a rash of clients who have received the "out of string space" message running on correctly configured workstations. Two were creating merge letters and got the message when saving. We thought it was either a virus or a virus checker. In one case it seems it was the virus checker, but another client swears virus checking is off. Does this ring a bell? We have over 200 clients running our application in AREV 2.12.


At 09 APR 1999 12:20AM Jonathan Bird wrote:

"Out of string space" in my experience is always because expanded memory is un-available. Check the shortcut, CONFIG.SYS and that arev is called with the /x /m4096 parameters.

J


At 10 APR 1999 09:00PM Fred D. wrote:

Not much more to add to Jonathan's comments, but I find that most such errors that occur after the workstations has been performing satisfactorily for a while, are due to the installatioon of some new Windows-based program, game, etc.

I also find that most Win-based programs automatically reset the EMM386.exe line in the Config.sys to "NOEMS" as a "standard" practice, even though their own use is unaffected by it either way. If I query the user, they will usually "fess-up" to installing some new game, drivers, screen-saver, wallpaper, Win-Fax, etc.

This problem can also occur if the application was suspended when the user tries to re-start it without typing "Exit". The resulting orphaned roll-out file will prevent full memory access if it is not deleted before starting the application again.

Again, as Jonathan points out, all related to the EMM driver not being loaded or the memory being otherwise occupied.


At 12 APR 1999 10:22AM Victor Engel wrote:

This problem can also occur if the application was suspended when the user tries to re-start it without typing "Exit". The resulting orphaned roll-out file will prevent full memory access if it is not deleted before starting the application again.

What? I'm really speaking over my head here, but my impression was that the rollout file was not even looked at unless going into or out of a suspended state. What I can picture, though, is that the session that is suspended keeps a small fragment in memory (not the rollout file but code to restore the session from the rollout file). It would be this memory that would cause a conflict.

View this thread on the forum...