A-Shell Consolidated Reference

In secure environments, you may find that the default security privileges assigned to the "SYSTEM" user are not sufficient. The solution is to go into the Services applet, display the properties of the A-Shell Telnet Service, select the Log On tab, and specify a user logon that has the necessary privileges. Note that since, from the standpoint of Windows, ATS automatically logs the clients in, you should use some kind of application-based security to prevent unauthorized users from gaining access to the system. And you should probably keep any such users away from the dot prompt.

If you can install the service but when you launch it, you get an error message indicating that the service could not be launched, the first step is to go into the Event Viewer (Control Panel .. Administrative Tools) to see what the error was. It will be under the System section. If the error indicates that "A-Shell Telnet Server (ATS) is not a valid Win32 application", then check what the executable is. (The service executable will be listed on the General tab of the Properties dialog for the service in the Services applet.) If the path to the executable contains spaces, make sure that there are no files which match up to the space. For example, if the path starts with C:\Program Files\MicroSabio, then make sure there are no files called Program in the root of the C: directory.

The most common problem with telnet connections is that they can be dropped by circumstances outside your control. When this happens, you can have two types of problems. The first is that the server doesn't know that the connection has been dropped. In most cases, ATSD uses a keepalive probe and thus should detect passively dropped connections within a minute or so. Explicit disconnects (initiated by either end rather than simply being broken in the middle somewhere) should be detected immediately. If the application on the server is still running at that point, it will get an error #250 and be given the chance to shut itself down via an error trap routine. If the job stops for input before closing itself down, it will be forcefully closed.

To help detect and track this kind of disconnect, you can add TRACE=SIGHUP to the miame.ini file, in which case the ashlog.log file will note all spontaneous disconnections. We also recommend TRACE=INOUT which logs all ins and outs to ashlog.log. This can be very helpful in tracking all kinds of problems.

See Service Installation Tips for more ideas which may help in troubleshooting.

Each ATSD connection uses up about 16K of heap memory on the server. Unfortunately, Windows allocates a fixed amount of heap memory to be shared by all instances of a particular service, so it is possible that you could hit the limit if making a lot of connections (probably 25+). Equally unfortunate, there is no standard diagnostic display to indicate when you are running out of heap memory, and the symptoms when you do run out may vary. You may just get a generic failure-to-connect message, or you may find that the connection hangs without an error while burning a lot of CPU time. To further complicate matters, the amount of heap memory allocated by default varies among different version of Windows. To one fortunate aspect of the problem is that it is relatively easy to reconfigure the amount of heap memory, by editing the following Registry item:

HKLM\\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

The value of the item is a long string containing many key=value clauses separated by spaces. The one to change is SharedSection=a,b,c (e.g. 1024,3072,1024) where c is the value to change. In some older versions, the third value may be missing entirely, in which case you'll need to add it. (Each extra 1024K is good for about another 60 connections.) You don't want to make the number needlessly large, since the extra memory would just be wasted, but you should probably stick with multiples of 512. Be careful not to touch any of the other clauses in the string!!! After making the change, you'll need to reboot the server. For more information about this setting, consult the Microsoft Knowledge Base article 126962. You may also be interested in the monitoring utility HeapMon.

You may need to add an inbound firewall rule to allow incoming connections to the port that the ATSD server is listening on.