Hi,

In the field, we are expiancing an issue where ATE will lock up when File, Disconnect is clicked. I have traced the problem back to the MEMORY entry in the ATE miame.ini file.
It appears that in older installations, the MEMORY setting is as follows: MEMORY= 500K,400K,10K
When changing to the new defaults (1200K,600K,10K), the issue is resolved.
I think this may only show up with PolyShell (which we are in the process of eliminating), but I am not sure.

I was wondering if anyone else was experiencing was experiencing this and if it would be possible to have the ATE installer fix it?

Thanks,
John Andreasen

I'm assuming you're talking about the MEMORY entry in the ATE copy of MIAME.INI?

It's unclear to me what takes "so much" memory for the shutdown operation, but if another couple hundred K solves the problem, I guess that's not too much to ask. (Probably the stack is getting corrupted earlier but it doesn't get noticed until the final unwinding.)

As for having the installer update it, that certainly sounds like the logical thing to do. Usually, we try to avoid having the installer fiddle with existing configuration parameters on the theory that if you had previously and deliberately changed them, you would be rightly annoyed by having your changed reset each time you did an update. But in this case, it's virtually certain that you don't care about the first MEMORY parameter (since it's always just the standard ATE main program using it). You might however have increased the second param if you knew you were using a particularly memory-intensive ATE-side SBX routine (which I think you guys are probably "guilty" of).

Let me review the installer capabilities and I'll report back...

OK, I am referring to the ATE MIAME.INI.

It is possible that a client side SBX is revealing the problem if that could affect it. I didn't think about that, but we have at least two that run whenever a new instance of ATE is launched.
With that being said, if you can't (or don't want to take the time to) figure out how to update the entry with the newer ATE defaults, perhaps we can do something to resolve it.

There are multiple ways to skin this cat, but before deciding which is best, can you send me or post a copy of one of those old MIAME.INI's?

OK, attached is a copy of a MIAME.INI from the field that was causing the lock up. I don't think it should have ever been hand edited.

Hey, the new attachment mechanism works pretty. (Maybe this whole BBS upgrade wasn't a pointless fiasco after all. )

OK, for starters I've generated an ATE install package that updates the existing MEMORY statement to 1200K,900K,100K (to allow a bit more headroom for really large client-side SBXs and more SBX cache). I think this is probably safe to do across the board (you're the first to ever report a memory issue), but just to be cautious, for the moment am posting it as a beta package:

ate-6.5.1665.0.exe

Glad to hear about the attachments! It was very simple on this end. It looks like it only accepts certain file extensions though. (This is why I zipped the file.)

As for the installer, I ran it on my development machine. It looks like the INI file was updated as it should have been.

Thanks!