- 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.
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-
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-
- 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-
The complete A-
- 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-
- 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.
Shell Track Record
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.
Please see the pricing page for the latest details on support options.