Although A-Shell itself can exist in any directories, for system administration purposes it may be wise to try to separate it from other application and operating system directories, if possible. This is less of an issue under Windows, where you typically have only one file system (or partition) available, and thus the best separation you can achieve is to give A-Shell its own directory tree, and possibly its own share name. Under Unix on the other hand, it is normal to have multiple file systems, and there are some particularly good reasons for defining one or more individual file systems to keep A-Shell separate from the rest of the operating system:

The core A-Shell installation consists of a single directory tree, normally named /vm/miame or \vm\miame. The top level contains the main configuration file, miame.ini. Below that is a bin directory containing the binaries—i.e., A-Shell's main programs and libraries—and a DSK0 directory tree with multiple sub-directories for  system commands and general shell variables and control file.

Depending on the size and complexity of your application, you may create one more more additional pseudo-device directory trees adjacent to DSK0 or anywhere. That is something you would set up manually after finishing the basic system installation; see DEVICE.

After installation, it is necessary to install the security key that was supplied at the time of purchase. This process is described in the After Installation notes. If you don’t have a security key, A-Shell will run in demo mode, which is fully functional except for nag messages and being limited to a the single user.

For Windows, updates are most easily accomplished via the Help > Check For Updates menu, which checks for the existence of an update, and if found, gives you the option to proceed. The update routine is identical to the install except that it doesn't give you the option of a target location.

For Linux, use the same process as for the original installation.

Under all operating systems, the installation process will detect that (or ask if) an update is being performed and will not overwrite any existing configuration files. Any configuration files that might have new fields added, or differing formats, are stored in example form with .new extensions. If the function key translation tables are updated, the original ones will be saved with .ifs (.ifx) and .vus (.vux) extensions.

The ash_install script used for installing and updating A-Shell under Unix will execute two special customization scripts—pre_ash_install and post_ash_install—if they exist in the custom subdirectory of the specified target directory tree. These allow you to customize the update process, perhaps saving, renaming, or removing certain commands or files, etc. See the sample scripts included with the release for further notes and examples.

It is possible to install A-Shell several times on a single machine, in different paths, which enables entirely separate A-Shell environments. While this is generally not recommended for end-users, who are typically running A-Shell as a single-purpose application, multiple environments can be very useful for developers and resellers for a variety of purposes: development versus production systems, duplicating customers' systems, etc. The recommended directory structure is to have all virtual machines located in the \VM or /vm directory. Each A-Shell installation would live one directory level below this identified by its machine name and the MIAME environment variable pointing to this subdirectory. It is recommended that the first A-Shell installation on a machine be made in the default directory \VM\MIAME or /vm/miame.

The days of agonizing over how to spend your limited hardware budget in order to get acceptable performance are pretty much over. Modern computers are so powerful and so fast that all A-Shell applications, with very few exceptions, will run at nearly unbelievable speeds. However, there are still some basic principles to consider when deciding on how to deploy and configure a multi-user system for best performance:

Operating System

Linux is generally much faster than Windows, especially in the area of multi-user disk I/O. It also requires a lot less memory per user. At the opposite extreme is the Windows peer-to-peer ("P2P") LAN environment, where file sharing can get bogged down in network communication between multiple PCs. If you don't have a lot of disk I/O involving simultaneous access to shared files, a P2P LAN is probably the simplest and most familiar Windows configuration, especially for those who already have such a LAN in place. Somewhere in the middle would be a Windows server configuration where the workstations are just running as terminals (i.e. connected via RDP or ATE/telnet), in which case you eliminate the network/file sharing overhead.

CPU

For multi-user systems, the more CPU cores, the better. A-Shell applications are rarely limited in speed by CPU issues, so this isn't a major consideration.

Memory

Most A-Shell applications are quite comfortable with less than 20MB per user, which is quite small by modern standards. That said, all operating systems will benefit from lots of extra memory for disk cache and other internal uses.

Disk Drives

SCSI is far faster than SATA or IDE, even in a virtual hardware environment. Since most A-Shell applications will be limited in speed by disk access times rather than CPU performance, this is probably one of the most important considerations. On the other hand, most modern disk drives are very fast, especially SSDs.

Directories

An often overlooked consideration is how many files you allow to accumulate in a single directory. With huge disk capacities, you may be tempted to accumulate years worth of report files. However, a better approach is to move those files to archive directories so the active directories don't have to deal with overhead of scanning over thousands of files for every file lookup. A good rule of thumb is to keep the number of files in any active directory below 1000.

More Information

Given the pace of change in the computer hardware environment, the information presented above may be accurate or hopelessly out of date. For more information and the latest discussions on this subject, see the relevant discussions on the A-Shell forum.