Something that just came up yesterday that I had not noticed. After logging out, "Memory Fault" displays in the window. Haven't seen that before and it had some of the users concerned.

See guys? I'm the one the bulletin board now.

Hi Bernie - welcome to the forum! (Too bad you couldn't have started with an easy question, like "how do I get the system time?")

I vaguely recall a symptom like this prior to 5.0, relating to PolyShell and/or changing the terminal driver from within A-Shell. The problem wasn't particularly serious, because the fact that the message is seen indicates that the error was trapped, and since it occurred on exit, everything was being cleaned up anyway.

If the memory fault occurred within A-Shell's process space, it would be trapped by A-Shell and a copy of the current log file, called core would be in the directory where the miame.ini is found (i.e. ls -l /vm/miame/core*) But in that case, if you saw any message, it would probably be "segmentation fault". I believe that "memory fault" is the message output by the bash or korn shell when it detects a segmentation fault. In the case of the terminal driver change, the issue had to do with both processes (the outer login shell and A-Shell) sharing the environment variable space, and when A-Shell relocated the TERM environment variable, it left the outer shell with an invalid pointer to that variable when A-Shell exited. If that's the problem, then I believe it was fixed quite awhile ago.

Even if that's not the issue, I would strongly urge updating to at least 5.0, and preferably 5.1, since it is next to impossible now to investigate such problems and provide patches for versions older than 5.0.

As an aside, if your users are seeing this message on exit from A-Shell, that implies that when they exit from A-Shell, they end up at the Linux shell prompt, rather than closing the session and closing the telnet window. That might be appropriate for administrators who need access to the Linux shell, but probably is not appropriate for ordinary users. To eliminate that, you can insert an "exit" command after the "ashell..." launch command in the $HOME/.bash_profile (which is typically how A-Shell gets launched). Or you could insert an "exec" at the start of the of "ashell..." command line (to replace the Linux shell entirely with A-Shell, which would also probably eliminate any possibility of there being a shared memory conflict between A-Shell and the Linux shell, since there would be no Linux shell left.)

Also, although this may seem like a "cover up", if your telnet session is going to be terminated when you log out of A-Shell (i.e. "host"), then perhaps you should have the telnet window automatically close at the same time. In the case of ZTERM, there is a "close on telnet close" option in the Configuration>Options dialog.

I don't ever remember seeing the message before and it's showing up on all users as far as I know. Even mine. What most of us do is arrow to the main menu and use the logout that exists there. That logs out the session but, yes, the window is still open. That is where "Memory Fault" is seen. I searched for that core file, but it doesn't seem to exist on my system. I did make the change in the config ZTerm setting and that does work, but is that an actual solution? No one actually needs access to the Linux shell because those that do need access have Linux access already and access it via SSH. Seeing that upgrading to new version may or may not happen, what would be the best course of action?

You're not seeing a corelog file because the error is occurring outside of A-Shell, in the login shell (presumably ksh). And since it only occurs right as you're exiting from that shell, I suspect it's not necessarily a "problem" requiring a fix. The main thing about it which unsettles me is that it suddenly started happening, when you presumably made no changes to trigger it. (Or did you?) But if it was a real memory fault (physical problem with memory), chances are pretty good that you would see the error in other contexts.

It might be useful to look at the ashlog.log file to see whether there is any indication of jobs failing to exit properly. If you have the INOUT trace turned on (which I added when I was out there a couple of weeks ago - perhaps that caused the problem(?)), the last entry for a job in the file should be something like:

23-Mar-10 17:20:03 [tsk:19949-j9] Out: Nodes Remaining = 10P/18L, 2 reads, 0 writes, 0 kbd bytes

If you see entries which begin with "In:" but no "Out:", that would suggest that the error is occurring before A-Shell actually exits.

If the "Out:" line looks ok, and there are no other indications of errors in the log (feel free to email it to me for review), then I would suggest testing whether inserting "exec" in front of the command line which launches A-Shell (probably inside $HOME/.bash_profile), i.e. "exec /vm/miame/bin/ashell -i /vm/miame/miame.ini ..." eliminates the issue. If it does, then the error is almost certainly in the login shell routine that gets control back from the forked ashell process. And since you say you have no particular need to return to the login shell after exiting A-Shell, the "exec" solution would eliminate the context that the error occurs in. (Although, like closing the window, you could still say it wasn't a real solution, although in this case it would be more a matter of avoiding the circumstances that lead to the error, rather than "covering it up").

Beyond that, you may need to have someone take a closer look to try to pinpoint the issue. If the machine is accessible remotely via the Internet, perhaps I could even do that myself. (Although in that case, the first thing I would do is install a parallel copy of version 5.0 or 5.1 to see if it has the same problem, and if not, my suggestion would probably be the same as it would be even without the error, i.e. update to at least the minimum currently supported version - 5.0).