A-Shell consists of a portable version of the BASIC language coupled with an Linux-like “shell.” Together, they provide the means for BASIC applications to run on a wide variety of operating system platforms, with minimal—or even no—changes to the original code. 

Specifications

• Runtime interpretor (RUN.LIT) is fully compatible with existing *.RUN files. (No recompilation needed!)  
• Existing data files (including random, sequential, and ISAM) files require no conversion. A-Shell takes care of byte order and alignment issues automatically and transparently.  
• ISAMPlus files are implemented using the Informix C-ISAM system, which allows you to access your files from a wide variety of Informix and third-party utilities. It does, however, require that they be dumped (using the AMOS ISMUTL utility) and reloaded (using the A-Shell ISMUTL utility).  
• Compiler is fully source compatible with existing BAS files, and will produce the exact same hash code as the AMOS COMPIL and OCMPIL modules. BASIC-Plus is not supported, but the compiler does optionally support the extended control structures (IF/ENDIF, DO/WHILE, UNTIL/LOOP). A portable version of the VUE editor is included. 
• Old-style terminal system features are supported, including TAB(-1,x), TAB(-2,x), TAB(-3,x), TRMCHR, variable rows and columns. UNIX version supports many old terminal drivers. AM65, AM62A, AM75, WYSE50, AIX, SUN drivers come standard; developers can create their own. Windows version supports mouse “hot spots.” 
• XCALL subroutines: Over 150 routines are built-in, including all standard AlphaBASIC routines (BASORT, SPOOL, COMMON, ODTIM, etc.), all AlphaACCOUNTING routines (NOECHO, MMENU, ANYCN, INPUT, SERCH, etc.), mainstream MicroSabio routines (INFLD, INMEMO, EZ-SPOOL, MSBOXX), and the most common custom routines (JOBNAM, TRMNAM, GETCHR, etc.). “XCALL AMOS” is fully supported, as is “XCALL HOST” (to execute a host operating system command). Configuration options handle variations between different customizations of common routines. C programmers can develop and link their own subroutines with the A-Shell development kit. BASIC programmers can write XCALL routines in BASIC which are loaded from disk at the time they are called. 
• LIT commands: Over 50 of the most important LIT commands are provided, including APPEND, COPY, CREATE, DEVTBL, DIR, DO, DUMP, ERASE, ERSATZ, ISMBLD, ISMDMP, ISMUTL, LOG, LOOKUP, MAKE, PPN, PRINT, RENAME, SET, SORT, SRCCOM, SYSACT, SYSTAT, TYPE, etc. BASIC programmers can develop additional LIT commands. 
• CMD and DO files are supported, including IF, ELSE, ENDIF, LOOKUP, and parameters. 
• File and record locking: FLOCK, XLOCK, and LOKSER mechanisms are supported. 
• TRACKER (screen area save and restore) is supported. 
• ERSATZ devices are supported via ERSATZ.INI (ala-AMOS); DSK devices are supported by mapping them onto host operating system directories. 
• File System Compatibility: A-Shell files are directly accessible as standard DOS/Windows or UNIX files, and your application can directly access external “native” files and execute “native” commands. 
• Print Spooling: AMOS printer names are supported by mapping them to host operating system printer or spooler support facilities.

Supported Platforms

A-Shell comes in two basic flavors: Windows and UNIX/Linux, with several variations of the UNIX/Linux flavor. For more information, see the A-Shell Platforms / Environments page.

Performance

It is very difficult to offer meaningful and accurate performance comparisons, due to the innumerable factors involved, although some general observations may be useful. In most cases, your application will run faster under A-Shell then under AMOS. Partly this is due to optimized coding, but mainly it is due to the disparity in raw hardware performance between open systems platforms, such as PC’s and RISC machines, versus AMOS boxes. As an example, the A-Shell compiler is about 10 times faster under A-Shell/UNIX on a Pentium 800 than under AMOS on a 6000. Most people find that their application runs 20 times faster on a relatively inexpensive LINUX box than it did on an AM6000. Improvements will be less dramatic in a Windows environment, primarly due to network and filesharing bottlenecks.

Porting

The most important question for most people is: “How much effort will be required to actually port my application?” It is difficult to give a blanket answer because applications are not all alike. In many cases, applications require no conversion at all, so the only effort is installing A-Shell and transferring your files. In most cases, however, some additional effort will be required. The following list points out some of the areas that may require additional effort or prevent A-Shell from being a solution for you:

• Subroutines: The most common problem is incompatible subroutines. We provide a great selection of the most popular and useful routines, but you may have one or more that we don’t already support. If it does something simple and common, like return a piece of information about your job, then we probably already support it but under a different name and you can alias it. If not, you may have to modify your source code to use one of the routines we provide which does the same thing, but with different parameters. We provide some routines in both A-Shell and AMOS format for getting the typical job and terminal information, so you could change to our routine and then have source code compatibility. The other two possibilities with rogue subroutines are to code around them in BASIC, or to create them in C and link them into A-Shell. You can do that yourself with the A-Shell Developer Kit, or you can contract with us to do it. Or you can write your own subroutines in BASIC. 
• Major third-party subsystems or language facilities that we don’t support. The best examples of these are applications written in assembly language, AlphaBase, Andi, ESP. If you use any of these, A-Shell will probably not help you much. In the case of BASIC-PLUS, we support the most popular features but not all of it so you may need to take a close look at which features you are using. 
• Code that is specific to AMOS, your hardware, or an AMOS-only application: A-Shell tries to draw a reasonable line between emulating features of AMOS, and providing an interface to the actual facilities of the host operating system. For example, A-Shell tries to emulate the spooler interface (SPOOL.SBR or PRINT.LIT) rather than the spooler itself, since most environments have one or more good spooler systems, and your application will integrate better with others if it uses the “normal” spooler for that platform. But the features and architectures of spoolers vary among systems, so if your application relies too heavily on special features of one of the AMOS spoolers, you might need to modify it. Another example would be if you directly access a serial port using the TRM:trmdef format. Under UNIX, serial ports have names like /dev/tty1a, and under Windows, like COM1:. Other examples would be dependence on AlphaNET (e.g. CPU IDs), the ITC or Software Interrupt system, LOKUTL, MTUSAV, the Task Manager, or AlphaWRITE. These kinds of facilities mayhave rough equivalents on other platforms, but we cannot emulate them directly.

If your application has one or more of the above “problems”, you may be able to work around by checking for the host system at run time and then making appropriate adjustments. For example, if you chain to a command file to execute MTUSAV for backup under AMOS, you might chain to a different set of commands for backup under UNIX. It may be interesting to note that A-Shell itself uses this strategy; about 95% of the source code is common to all platforms, with conditionals for the remainder.

Installation Overview

The complete A-Shell package, including setup program, can be downloaded from our web site. The Windows setup program is very similar to most other modern Windows setup programs (mostly a matter of clicking “Next” several times.). The UNIX version is released as a cpio archive, from which you can extract and run the installation script. After running the setup program, you have a few additional tasks:

• Adjust the MIAME.INI configuration file. This is conceptually similar to the AMOS.INI file or to Windows INI files or UNIX profiles. You can probably figure on spending an hour with this file on your first installation. A significant issue here is how to optimally map your AMOS logical devices to physical devices on the host system. 
• Set up printer.INI files. These are similar to the spooler INI files used under AMOS, but are slightly trickier given the wider range of possibilities for spooler devices under A-Shell. 
• Transfer your programs and data from your AMOS system to the new platform. In most cases, you will do this by connecting the two systems together (via a serial or network link). You will need a file transfer utility, like pcVision or AlphaLAN, that supports binary transfers. (XMODEM will not work for your data files.) For UNIX systems, if you can connect via TCP/IP, you can use FTP to transfer your files. Otherwise you may want to do a two-step transfer: AMOS to PC and then PC to UNIX. No conversions of any data files are needed, except for ISAMPlus files, which must be dumped and re-loaded using ISMUTL. Source code should undergo the normal line terminator translation (CRLF vs. LF) when going to UNIX. 
• Install the security code. A-Shell comes with a software installation “key”, similar to most PC and UNIX software. A hardware “dongle” is not required. 
• Learn about the host operating system. Unfortunately, many people forget this step in estimating the amount of effort to complete a porting project. It is true that A-Shell insulates you from a lot of details about DOS, Windows, or UNIX, but it is impossible to survive in these environments without a reasonable level of knowledge about them.

The A-Shell Track Record

A-Shell was originally developed by John Bown in 1990, and was first sold commercially in England in 1991. MicroSabio became a distributor in 1992, and took over development and support in 1995. As of May 2016, we had issued well over 1500 licenses, with an average of five to ten nodes per license. We have many sites with 100 or more users, and a few over 500 users. Although the core functionality has been quite stable, we have been continuously maintaining and enhancing the product, making improvements available regularly on our web site through a low-priced annual support/update subscription. The vast majority of our sales have been through dealers, as part of vertical market applications. We take this as a show of confidence in the product, since dealers have the most to lose (and the most to gain) by depending on A-Shell for sales in the “open systems” market. It is especially satisfying, when dealers tell us—which they frequently do—that without A-Shell, they would have gone out of business. A significant and growing percentage of our sales are to new customers that have never heard of Alpha Micro, proving that A-Shell is expanding the reach of AlphaBASIC applications.

 

Pricing

A single node (one user) A-Shell system retails for about $400.  At 10 nodes, the average cost per node is about $150, and at 30 nodes, it is about $100.  See the A-Shell Price List for more detailed information.   Dealer pricing is available to qualified dealers.

Support

Please see the pricing page for the latest details on support options.