Back to the Alpha Micro Phun Machine @ Floodgap Retrobits | Jump to: Alpha Micro Pageant of Machines | Downloads | Links and Resources

AMPM: Primer to AMOS

AMOS, the primary operating system for most Alpha Micro servers, is certainly alien to people who have only lived in a Unix-Windows duality -- but very familiar to people who have dealt with things like TOPS-10, of which it is not a descendant but can be considered strongly influenced by.

This document talks about some of the basics with starting up, setting up, using, administering and shutting down the typical AMOS-based system. By typical, I mean specifically AMOS/32, the most common version, which runs on the majority of 68K-based Alpha Micro systems; despite this, however, this document is still largely applicable to AMOS/L and the oldest S-100 WD-16 systems (less so for the most current Windows XP/EAMOS systems, which are well-documented and have their own unique characteristics). Note that this document does not cover complex administration tasks, nor does it cover the entire length and breadth of the AMOS command set, nor does it cover tools such as VUE and MULTI in anything but an elemental sense.

This document assumes you have some working knowledge of use and basic administration of a multi-user system such as Windows NT/Windows Server or a Unix or Un*x derivative operating system.

What is AMOS?

AMOS is a multiprocess/singlethreaded multiuser operating system that is proprietary and unique to the Alpha Micro line. Its current release for the modern x86 AMs is 8.2; the last release for the 68K AMs is 2.3A; and the last release for the antediluvian AM-100 is 5.0 (of its particular earlier form of AMOS).

AMOS has some unusual features for an operating system. One of the most unusual is that the 68K, a big-endian chip, is run effectively in little-endian mode due to bus line swaps needed for preserving data file compatibility with the WD-16 systems. Although the kernel (called the "monitor") preemptively multitasks, AMOS is also a strictly real-memory operating system: it does not use an MMU, nor does it require one. Memory is partitioned into fixed segments and programs are expected to be relocatable to whatever address they are loaded without any patching. Programs can also be marked as "reentrant" and/or "reusable," i.e., respectively, that their memory image(s) can be run simultaneously by multiple users without interference, and/or that the image can be held and called again with the expectation it can self-initialize without being explicitly reloaded.

AMOS/L vs. AMOS/32

As mentioned above, when I say AMOS, I mean AMOS/32, which runs on the vast majority of operational Alpha Micro installations. AMOS/L is the original 68K-based AMOS, which was introduced on the AM-100/L and the primary operating system of the AM-1000 and AM-1500, and later the AM-1200. With the advent of the 68020 and the AM-2000, Alpha Micro introduced the fully 32-bit AMOS/32, designed as backwards-compatible with AMOS/L, and maintained each version in parallel. This duality was mostly lost on casual users due to both forks being functionally and internally similar, and with AMOS 2.0 (/L and /32 flavours) the distinction became further blurred. Finally, with AMOS 2.3, Alpha Micro merged everything back into a unified version that ran on any 68K and the /L vs. /32 issue gracefully disappeared.

Getting the Console Connected

Before we even get moving, you'll need a serial console. The older "DB-9" (DE-9 actually) ports are not quite the same as a modern PC COM port and require conversion. Similarly, you'll need an adaptor for RJ-45 ports if your system has those instead. This is true even if you have a real Alpha Micro terminal like an AM-62 or AM-65. The below converter will allow you to run a DB-9 (DE-9) Alpha Micro port to a DB-25 RS-232 port connected by a straight-thru RJ-45 (such as a Cat 5 Ethernet) cable, using all eight lines. If you use RJ-45 ports on your AM, then just use the DB-25 end.

On the Alpha Micro DB-9 side, this is the wiring schedule (with 8P8C colours) for RJ-45 female to 25-pin RS-232 DB-9 (DE-9) male. Both the DB-9 (DE-9) and DB-25 modular converters can easily be found at places like Fry's for a few bucks. Colours refer to the wires within the adaptor. In this orientation, the female RJ-45 "lock snag" is at the bottom with line 1 on the left, and the male DB-9 (DE-9) has pin positions 1-5 on the top row with pin 1 on the left.

Blue (RJ-45 1) to DE-9 1
Orange (RJ-45 2) to DE-9 8
Black (3) to 3
Red (4) to 5
Green (5) to 2
Yellow (6) to 9
Brown (7) to 7
White (8) to 4

On the terminal/PC DB-25 side, this is the writing schedule (with 8P8C colours) for RJ-45 female to 25-pin RS-232 DB-25 male. Colours refer to the wires within the adaptor. In this orientation, the female RJ-45 "lock snag" is at the bottom with line 1 on the left, and the male DB-25 has pin positions 1-13 on the top row with pin 1 on the left.

Blue (RJ-45 1) to DB-25 1
Orange (RJ-45 2) to DB-25 20
Black (3) to 3
Red (4) to 5
Green (5) to 2
Yellow (6) to 8
Brown (7) to 7
White (8) to 4

If you only have 9-pin RS-232 ports on your terminal, use any standard PC 25->9 converter cable to get you the proper polarity and pinout at this point.

There is no real convention for where the console terminal port usually sits, so you may need to try different ports before you find it. If the ports are arranged horizontally left to right, try the left-most port; if they are arranged left to right and top to bottom, try the upper left port or bottom right port. Either way, configure your terminal for 19.2kbps, 8N1 or 9600bps, 8N1. If you don't have a real Alpha Micro terminal, you might have some garbage when you boot, which is expected. Somewhat later we will discuss how to change the characteristics of your terminal if you have this problem.

Filesystem

AMOS has several filesystem conventions which will sound familiar to DEC users, but may be strange to others.

All files are in 6.3 format, which is to say, six letter filenames and three letter extensions. Like most operating systems, there are a number of reserved file extensions (this list is not exhaustive):

.LIT: executable
.CMD: command script
.INI: settings or initialization file
.BAS: AlphaBASIC source file
.RUN: compiled AlphaBASIC executable
.SBR: AlphaBASIC extension file
.M68: 68K assembly source file
.TXT: text file
.RTI: Run-time module
.CTL: Task Manager batch control file
.DO: DO script

Every file is associated with a disk number (such as DSK0:) and a project-programmer number (such as [1,2]). This setup is often called an "account" in Alpha Micro documentation and I also use such terms more or less synonymously. For example, the bootstrap script lives in DSK0:AMOS32.INI[1,4]. The project-programmer number is best thought of as a "user directory" -- in this case, the home directory of the system administrator account. PPNs can be password protected, which is the basis of user accounts and user security in AMOS. When you switch PPNs with the LOG command, you assume the privileges of that PPN (and if the PPN is password protected, you must enter the password to access that account). PPNs are 8 bits each and are expressed in octal, so the highest PPN for a given disk is [377,377].

Remembering the PPN and disk number for a whole bunch of accounts would be irritating and tough to juggle, so you can establish an alias called an ersatz for a (disk,PPN) pair. There are several common ersatzes on just about every system:

OPR:, the operator account
SYS:, system files, and most executable binaries
DVR:, drivers
CMD:, command directory, usually the same as SYS:
LIB:, library directory
HLP:, help files
BAS:, BASIC support libraries and extensions
MAC:, assembler support files
TXT:, letters and office files
TCP:, AlphaTCP
MULTI:, MULTI environment

In general, most ersatzes refer to a standard location. For example, the ersatz initialization file lives in SYS:ERSATZ.INI, which is almost always DSK0:ERSATZ.INI[1,4]. This file contains a list of ersatzes and their (disk,PPN) equivalents, separated by whitespace and an equals (=) sign. Users will often have accounts defined as an ersatz, such as TRM1: or USER1:.

Similarly, OPR:, the operator/system administrator account, is virtually always DSK0:[1,2]. There can be operator accounts ([1,2]) on other disks with administrative privileges to accounts on those disks, but not to the system at large.

There are no subdirectories in AMOS.

If you omit the disk name, then the current one you are logged into is assumed. If you omit either part of the PPN, like [,5], or the PPN altogether, then the current one you are logged into is also assumed. Things like COPY DSK1:=DSK0:, for example, don't copy the whole disk; it copies from the current PPN you are in on DSK0: to the same PPN on DSK1:, assuming it exists.

Wildcards (*,?) are valid in filenames, file extensions and PPNs (e.g., [*,5] and [*2,???] are legal, although [2*,5] is not -- note that ??? would match a number of one or two digits as well as three), but not disk device specifications. The idiom [] is the same as [*,*], so COPY DSK1:[]=DSK0:[] would copy all files (because COPY also assumes *.* by default). To refer to all disks, use ALL:.

PPNs can also be used to designate things akin to ACLs and user groups. By default, a particular file is readable and (for executable files) executable by anyone, but can only be written to or deleted by people logged into its PPN or a PPN with the same project number (the first number of the two). Thus, assigning people the same project number allows them to be in the same "workgroup" and access and manipulate each others' files. For AMOS filesystems with "extended files" in them, this can be made much more granular. Remember, anyone logged into OPR: can read, write, change and delete anything.

Systems may also have usernames for login, but this is different from a PPN/password system. If you get a username prompt and you don't have a login, try System Service, which is the default administrative user on a minimally-configured system. This username is usually attached to the SYS: account. Another common pre-configured username is DEMO, which is often attached to OPR:.

Jobs and Terminals

Jobs are the AMOS equivalent of processes on other operating systems. The maximum number of jobs available on your computer is defined on startup, and then jobs are "allocated" from that maximum pool. A fixed amount of available memory is assigned statically to a job when it is allocated. Jobs are generally also statically allocated on startup, and may or may not be attached to terminals, although some may be dynamically allocated by subsystems like MULTI or AlphaTCP (for example, the webserver job that served you this page was dynamically allocated by AlphaTCP, started up with a fixed memory allocation, served the file and then died off after its job was done).

Terminals are much more flexible, dynamic entities than on many operating systems. Every terminal must have a job attached to be functional, but the job attached to the terminal may change. In addition, you can force input into a job as if the terminal the job is attached to were entering the commands (in fact, this is very common in the system initialization file).

We'll talk about adding more jobs and terminals presently.

PICs, Licenses and the SSD

Every AM system has a Software Security Device (SSD), a serial number acting as a unique identifier. Although license management is generally not of much interest to a casual hobbyist who picked up a used Alpha Micro to mess around with, and probably would give Richard Stallman a really nasty twitch, you should know how it works in case you decide to upgrade the system software later.

To manage license caps and lock installable software options to a particular machine, many installed software packages require a PIC (Product Installation Code) keyed to the SSD. The PIC enforces certain options and, where applicable, maximum user caps. If you do not have a PIC for a particular package and system combination, do not try to install the software or you may damage your system with a failed install. Later versions of AMOS may not require you to enter a PIC for certain packages like AlphaTCP, so check your documentation.

Typically, the PIC will come from the vendor or VAR who sold you the package. Your SSD's serial number is usually on the exterior of the system case and must be provided to the VAR to generate the PIC when you purchase it.

Starting Up and Shutting Down the System

The console terminal should be turned on first, along with any printers. If you have external disk drives, those should be turned on next, and then the main system.

If this is done right, on an AM-62 or compatible terminal you should see something like 'System booting, please wait' in the status line and the Alpha Micro logo and copyright scroll into view. After that, the lines in SYS:AMOS32.INI will be executed.

At that point, most systems will put you at an AMOS command prompt (., a single dot), usually in the OPR: account. If this doesn't happen, type LOG OPR: and, if requested, the operator account password. You will now have administrative privileges.

On certain systems, you may need to enter a username/password first, and you will usually be placed in whatever PPN is the default for that username. If you don't have a username, try System Service or DEMO. (I have some tips on how to legally! break into a used Alpha Micro you may have acquired on the Eagle 450 page, showing the steps how I got control over that particular machine.)

Shutdown requires generally no special preparation. Make sure all users are out of any applications, including you, and are logged off the system. At that point, barring special caching or backend setups, you can simply turn off the main system, followed by external drives, printers and finally the console terminal. However, if you are using devices with write-behind caching or just want to be paranoid, unmount those devices with MOUNT diskspec:/U, such as MOUNT FLP0:/U. Your system should have these "special devices" marked.

Command Syntax

Online help is available for selected commands by typing HELP (alone for the table of contents, or with the command name).

Commands consist of a command name, any switches (switches start with /), an input file, and for those files generating output, an output file such as any of the following:

TYPE/P SYS:AMOS32.INI
COPY/Q/NOD COPY.TXT=ORIGINAL.TXT

Switches can also come at the end of a command line, although most people coming from a DOS or Unix background (like me) will probably put them in leading position and that's fine too. However, if you are using a system prior to AMOS 2.0, you must put them at the end: TYPE SYS:AMOSL.INI /P If you are using, say, 1.3C, remember to convert examples below to this format.

Redirection (<, >) is supported on later versions of the operating system, and so is piping, although these operations are not chain-able. If this doesn't work right, type SET REDIR to make sure that redirection is enabled. The REDIR command can "steal" the output from a command if you are otherwise unable to redirect.

Later versions of the AMOS command line understand quoted strings and backslashes. You might also be able to hit CTRL-R to retype a line.

There is no concept of "searching the path" on AMOS. Instead, commands are sought for in a particular hard-coded order: SYS:name.LIT, then name.LIT in the current account, then SYS:name.CMD, then SYS:name.DO, then name.{CMD,DO} in the current account, then name.{CMD,DO}[,0]. If you don't know where a command is, try FIND name.* or if that doesn't exist, its equivalent DIR ALL:[]name.*

Here is a table of the typical filesystem commands you will use in AMOS, along with their DOS/Windows CMD.EXE and Un*xy equivalents. An asterisk (*) indicates that there might not be online help for that particular command. Common options are in (parentheses).

AMOS	*Unxy Thing**	MS-DOS
`dir (/w) (/f)`	`ls (-C) (-l)`	`dir (/w) ([default])`
`erase`	`rm`	`del`
`copy`	`cp`	`copy`
`append`	`cat`	`copy /c`
`rename`	`mv`	`ren`
`type`	`cat`	`type`
`type/p`	`more`	`more`
`find`	`find`	`dir /s`
*`rename/prot()`**	`chmod`	`-`

Commands like COPY and RENAME that require you to specify an output filespec work a little differently. For example, to rename file A.LST to B.LST, the command would be RENAME B.LST=A.LST (like the RENAME disk command for Commodore 1541 disk drives). You can also specify a full device and PPN if necessary: for example, to copy all files named EGREP.* from, say, DSK5:[100,100] to the current PPN, then you would enter COPY EGREP.*=DSK5:EGREP.*[100,100] or the equivalent.

Unique User Tasks and Commands

Here are tasks specific to AMOS, or that AMOS handles differently.

To log into a particular PPN, type LOG and the PPN, such as LOG OPR: or LOG DSK0:[1,2]. If the PPN is password-protected, you will be asked for a password. If you don't know what account you're logged into, type LOG by itself.
To list all the PPNs on the disk you're logged into, type PPN.
To mount a disk (floppy, hard drive, etc.), unmount and remove the previous media if any/applicable by typing MOUNT diskspec:/U, insert the new media, and type MOUNT diskspec: (such as MOUNT DSK4:). Hard drive partitions and other SCSI devices usually appear as DSKn and floppies often as AMSn FLPn DDAn -- if you're not sure, type DEVTBL for a list of all defined devices. The system will warn you if the device is still in use, and you may need to be logged into OPR: either overall or on that device in certain circumstances.
This does not in general apply to CDs if you have a CD-ROM system. If you have ISOCD, you can use this to browse any ISO 9660 CD, but it cannot mount them as AMOS devices. AMOS-format CDs such as the AlphaCD can be mounted using the ACD command to set up the logical disks on the CD-ROM as ACDn. (Remember to unload it when you're done with ACD /U.)
To display all the jobs running on a system and their attached terminals, type SYSTAT. For a dynamic list like the Task Manager or monitor, try STAT. To see just what job is controlling your own terminal, try JOBALC.
To display all the terminals defined on the system and their controlling jobs, type TRMDEF. This also lists what interface is running them, which port, which terminal driver, and various options. Pseudo-terminals such as those used for network sockets and Telnet are also shown.
To cancel an executable a job is running, type KILL jobname. If the job is a dynamic one, such as one generated by AlphaTCP, this may also have the effect of causing the job to close entirely (which is usually what you want). If it is a pre-allocated one, it will return to AMOS command level.
To start AlphaBASIC, type BASIC. To return to the command prompt, type BYE inside BASIC.
To run a precompiled AlphaBASIC program (.RUN), use the RUN command.
To preload an executable for efficiency, use the LOAD command. You can see what executables are already preloaded into your memory allocation with MAP. To remove an image that you don't need anymore, use DEL. Preloaded executables obviously take up memory, but they run considerably faster since they are "pre-cached". (Executables can also be loaded into system memory, but this is beyond the scope of this primer.)
To ring the terminal bell, use DING n where n is the number of black eyes, er, bells you want rung.
To send a message to another terminal, use SEND job message (note that this means you need to know what job is controlling which terminal). The equivalent for wall is SEND *. AMOS also supports a mailbox system allowing intrasystem E-mail, but this is not something I will discuss in the primer.

VUE, the Visual Editor

AMOS uses VUE for most editing tasks. It's not as fat as emacs, which is like saying that I'm not as Catholic as the Pope (i.e. not much). Actually, VUE will run in as little as 32K, file size permitting.

To edit a file, type VUE filespec:. You can enter a new filename that doesn't exist, in which case VUE will ask if you want to create it. VUE will refuse to edit files with certain extensions, such as .LIT or .BAK -- rename them if you want to open it anyway. A backup file will be created (.BAK) if the file already existed, and the editor will start.

VUE is a modal editor. Press ESC to switch back and forth between edit and command modes.

VUE is much nicer on an Alpha Micro terminal because the cursor keys and special editing keys work; otherwise, you're pretty much condemned to key combinations. The equivalents for most basic operations are:

Cursor controls: CTRL-H,J,K,L for left, down, up, right
Insert and delete a character: CTRL-F, -D. To toggle automatic insertion, use CTRL-Q.
Insert and delete a line: CTRL-B, -Z. To toggle automatic insertion, use CTRL-\. To undelete a line, type CTRL-underscore (CTRL-SHIFT-dash), then R.
Mark a block (begin and end): CTRL-P
Block copy or move: CTRL-underscore (CTRL-SHIFT-dash), then press C or M
Beginning or end of line: CTRL-U, -N
Repaint screen: CTRL-@
Next and last page: CTRL-T, -E

When you are done, press ESC for a command prompt and either enter FINISH (to write the file out and exit), or QUIT to abandon your changes.

Making Command Files

There are much more to these than this brief description of .CMD/.DO file syntax would indicate, but simple files are straightforward to demonstrate. For most people, a .DO file is the closest thing to a shell-script or batch file (the difference being that .CMD files don't accept arguments, and .DO files do).

Special sequences start with a colon, and comments with a semicolon. For example, this script prints a message and edits the file specified on the command line:

; only show output of commands, not the commands themselves ; to show commands, use T :R ; this acts like a here-document :< Now editing the file $0. Notice that arguments start with 0. > VUE $0

Remember to put the file in a standard place like CMD: if you want to access it from other accounts.

If you put a command file called START.CMD into a particular PPN, it will execute when you log into that account (very handy for automated tasks and the like).

MULTI

MULTI is a text-windowed environment manager that allows a single terminal to dynamically allocate and jump between multiple jobs, much like Unix screen or virtual consoles on most modern operating systems. I personally don't use it because it can rapidly grow a large memory footprint, and it does not play particularly nicely on anything but Alpha Micro terminals, but there are some people who adore it and you will find it on many AM systems that were in office automation environments. Its use is beyond the scope of this primer.

To start MULTI and play with it, type MULTI.

Administrator Activities

For many of these activities, this primer deals with only the barest, least complicated cases. Configuring AlphaTCP on those systems for which it is supported is discussed below.

The following tasks can generally be done "hot" without restarting:

To change the date or time, use the DATE and TIME utilities. Dates are given in MM/DD/YY format, and time in 24-hour HH:MM:SS. You must be OPR: to change them. Typing them without an argument just shows what they are.
To add a login message, write a file DSK0:MAIL.JNK[7,2] (this account may not exist on your system; see below). The first line will be displayed on the initial LOG of a user, similar to Unix /etc/motd.
To check a disk for integrity, try REDALL diskspec:. This will attempt to sequentially and non-destructively read every sector on the disk. If REDALL fails, get help!
Note that this doesn't find soft problems such as defective (but physically intact) directory entries and the like. The equivalent to fsck is DSKANA but DSKANA can destroy a disk if run while other users are accessing it! It is strongly advised you read the System Administrator's manual before trying to repair or scan a disk for soft errors, or you could make the problem worse. If you just want to scan a disk without attempting to repair it, use DSKANA/C.
To add, remove or otherwise manage PPNs on a disk, use SYSACT. Log into OPR: and type SYSACT diskspec: to start the utility. You may want to look at its help page first.
The SYSACT prompt is an asterisk *. To list all the PPNs on the device, type L (or use the PPN command). For help, type H. You cannot remove accounts without clearing files first. If you want to wipe the disk, use option I but this will erase all data!
To exit SYSACT, type CTRL-C or press Cancel on any Alpha Micro terminal.
To add, change or remove valid user names on a system, use MUSER. This is a menu-driven program, and is much friendlier than things like adduser. You must be OPR:. The System Service login should not be removed in general unless you have something specific in mind, but putting a password on it is a good idea since this is not often done by default. You might want to remove DEMO if it exists, however.
To force a job to do certain commands, use FORCE job. You can pass an optional command to do right away, or FORCE will put you into a multi-line mode where commands are accepted sequentially until you type a blank line. This is a great way to make an idle terminal log off -- find its job and FORCE it to exit whatever application it's in. Even Telnet sessions (see below) can be FORCEd to do operations or even LOGOFF completely if you know what their controlling job is. Yes, you generally have to be OPR: for jobs you're not allowed to play with. The barn door isn't that wide open.

The following tasks require you to edit the main system initialization file. Always edit a backup -- never edit SYS:AMOS32.INI directly because an error in it may make your system unbootable! The copy should be made somewhere in DSK0: as well. After editing your copy, log all users off, get to AMOS command level and as OPR: use the MONTST command to run a simulated boot in a command like this (substitute your file for TEST.INI; it must be in OPR:):

MONTST AMOS32,TEST.INI

This will launch the AMOS/32 monitor (i.e., the kernel) with the new system initialization file. If this works as expected, then replace SYS:AMOS32.INI with your new file and restart the system. If it doesn't, simply reboot (either from command level or hitting the reset button) and try again.

To increase the number of total jobs, find the line usually early in the file with the JOBS command and increase that number. This may be necessary for AlphaTCP if you have a busy server. Note that this doesn't actually allocate more jobs; it merely makes it possible to allocate more jobs, although subsystems like AlphaTCP and MULTI can dynamically allocate from the job pool meaning you don't have to explicitly allocate them yourself. Set this number to something reasonable based on your load level.
To change the characteristics of a terminal, find the TRMDEF line corresponding to the desired terminal. These lines have the terminal name, the interface and port number, the port speed, the emulation file (look at the TDVDEF line to see what is defined, or DIR/W DVR:*.TDV to see what is available), options specific to the terminal, and the editing mode (typically 5). Generally, most people will want to change either the port speed or terminal emulation. The other options should be left alone. Note that if you ask for a .TDV that is not loaded in the TDVDEF line, you may make that terminal or the whole system inoperable, so make sure that you request all terminal emulation files you will need in the TDVDEF line also.
If your terminal is so hosed that you can't even edit the INI file, grabbing it over FTP and editing it remotely on another computer might be worth a shot if your Alpha Micro has a running copy of AlphaTCP.
Adding more terminals is beyond the scope of this primer. However, the relevant lines are of course TRMDEF again, JOBALC to allocate a job, and finally SETJOB to attach that job and a memory allocation to an individual terminal with a startup task to run. You may be able to do this for simple cases by following the established template already in the .INI but I advise getting familiar with how the initialization process works first.

AlphaTCP

(NB: AlphaTCP != AlphaNET. AlphaNET precedes AlphaTCP and is only useful if you have a network of Alpha Micro systems; its configuration is somewhat unusual to the AMOS-naive and is beyond the scope of this primer.)

AlphaTCP is AMOS' grafted-on TCP/IP stack, essentially an implementation of (per developer Steven Lawson) SpiderTCP and SpiderStreams, emulating System V, with later work to add Unix-like signal handling and a faked-up fork(). In fact, some of its command set feels a lot like Unix. AlphaTCP will only run on an '020 or later, and an '030 or later is strongly recommended, but machines upgraded with Roadrunners will work too so even your AM-1000 can come play if you pony up the green. Ethernet is preferred, but SLIP over a serial port is possible.

Certain machines and hardware options may demand a minimum version of AlphaTCP, or they will not function. If your particular setup came preconfigured with a particular version of AlphaTCP, do not downgrade it. (Upgrading is of course safe.)

AlphaTCP has several versions, but the minimum version that is "truly useful" is 1.3A due to the considerable stability and architectural improvements made in this release. 1.3 also was the first version with a HTTP web server, which makes sites like this even possible! Later versions add performance, fix some minor bugs and add many additional features, but if the cost of a new AlphaCD has your teeth chattering and you're running 1.3A, don't worry about it -- you won't get all the newest stuff, but you do have all the essentials and there are no known remotely exploitable security issues either. In fact, I fuzzed my 1.3C Eagle pretty badly on several ports and didn't get anything of consequence. Of course, running cleartext services like telnetd or ftpd on an WAN is a nice way to get pwn3d, so you shouldn't do that, and there is no ssh for AMOS. That's why mine sits behind a firewall for external access.

Note that BOOTP/DHCP support as a client requires 1.5.

For client applications, AlphaTCP 1.3A minimally implements NSLOOK (nslookup, DNS queries), ARP, PING, NETSTA (i.e. netstat in 6 characters), a strange PS modeled on Unix ps purely for AlphaTCP applications with a corresponding UKILL, RUPTIM (ruptime), TCPMON (a simple packet monitoring interface), UUD/UUE (uudecode/uuencode), EMAIL (an SMTP MTA interface), TELNET, FTP and TFTP. FINGER was added in 1.3B, URL (essentially a tiny curl for FTP and HTTP only) and WHOIS in 1.4, AMPM (the Alpha Micro Product Manager) in 1.5, and after great delay the very essential TROUTE (traceroute) in 1.5A. Furthering the Unix-isms, many of these use hyphenated switches, not AMOS' standard slashed switches.

There is no web browser for AlphaTCP other than what URL offers, but there is a Gopher client that we maintain at Floodgap.

Telnet Connections to AMOS

Telnet is a convenient way to log in to your server remotely (but heed my warning -- cleartext Telnet over a WAN is just asking for it, so use this only within your local trusted network). If this is configured, when you connect you will get a prompt like this:

Enter terminal type and memory required (default is 64K) or a question mark (?) to see a list of supported terminals Example: >am65a 64k

If you don't see your terminal type in the list you get with ?, you might need to install it. 1.3 lacks a VT100 compatible .TDV which seriously impacts the breadth of clients that can talk to it, but I have the customized one I use on the Downloads page which will work for most VT100 emulators including xterm and Mac OS X Terminal. A comfortable memory allocation if you can afford it is 640K, which is the typical amount I ask for when I log into my machine, but strictly speaking you should only allocate the minimum amount to run what you need without impacting the free memory pool on the system.

After that, you will get a login prompt. Login with your username/password. If you don't know a login username, try System Service or DEMO.

To find out what job has been dynamically allocated to you, type JOBALC (and similarly your job and pseudoterminal will also show up if you type TRMDEF). If you have 1.3C or later, the VTID command will also tell you your source IP and source port number.

To log off of a machine, type LOGOFF and a summary of usage will be printed before you disconnect.

AlphaTCP Server Notes

On the server side, AlphaTCP 1.3A implements SMTPD (AMOS' answer to sendmail), POP3D and POPPWD (POP3 and POP password management), LPD, ITCD (a tunneling service for AlphaNET), RWHOD, TELNED (telnetd), TFTPD, FTPD and HTTPD. SLIPD is present to manage the connection for SLIP systems as well, although it does not exist in the same world as the true TCP server applications and is administered differently. SNTPD (simple network time management) and TAMED (for AlphaBASIC TCP applications) were added in 1.4, POP3D was replaced by QPOP3D in 1.4A and the AMPM server was added in 1.5. Gradual improvements also occurred particularly in the web server which we'll talk about in a little bit.

All services are managed by TCPEMU, which is analogous to inetd with an attitude problem. Setting up TCPEMU and AlphaTCP is such a big topic that you really need to read the manual for it. Configuring and building an AlphaTCP installation from scratch is not exactly intuitive until you've done it a few times and made all the possible mistakes (this is indeed how I learned too). This document will assume you have a system preconfigured or someone assisted you with the initial bring-up.

Assuming you're past that point, the file TCP:NETWRK. (notice the overtly blank extension!) contains the IP address for the particular interface in question, assuming you are using a static IP and not DHCP. TCP:RESOLV. is the analogue of /etc/resolv.conf; the line tryhostfile will cause the DNS client to look at TCP:HOSTS. (in fact, first before any DNS query is made in 1.4+) for any relevant entries. Services that TCPEMU runs are in TCP:CONFIG. but you should really understand what this is doing before you edit it! Changes can be made live, but it would be best to followup with a restart to ensure that they stick.

The web server uses some ingenious but not entirely obvious tricks to map a apparently much larger filesystem onto the simple AMOS PPN scheme, and this can really trip you up if you don't understand it fully. To keep aliasing from being a problem, I recommend just keeping your names in the 6.3 format and then you don't have to worry about what long filename will map into what short one. By default, the home document is TCP:HTTPD.HTM, but files can be stored anywhere; for example, this file is /www/amos.htm, which maps into WWW:AMOS.HTM. Note that the default "default file" in a "directory" is HOME.HTM, not INDEX.HTM. Any ersatz with a PUBLIC.PPN file in it is servable by the webserver; don't put this in SYS: because that would be really stupid and dumb, wouldn't it?

As a consequence of how filename mapping is performed, it isn't possible to serve any file from the root "directory" except HTTPD.HTM (and ROBOTS.TXT, which is "special-cased"), unless you redefine where the root is using the -m option in 1.4+. Since this isn't possible in 1.3, you are limited to those two files in the root, so start defining ersatzes for everything else. FAVICON.ICO is served from TCP:FAVICO.ICO, but this isn't supported in 1.3 either.

1.3A supports imagemaps and hit counters internally. CGI scripts are also supported, but must be pre-defined in TCP:HTTPD.APP. For example, here is the one for the local systat:

#systat Application=systat Command=SYSTAT Memory=50k Kill=Yes Decode=No Account=SYS: Mime=text/plain

CGIs do not need to emit headers, but they can if they want. You can write CGIs in AlphaBASIC too, and have them accept arguments and POSTs, but you should read the manual for security considerations first.

Unlike most of the configuration files, MIME.TYP is stored under LIB:, not TCP:.

There are some other differences in HTTPD relative to later versions which are not properly documented in the AlphaTCP manual.

CGI scripts are all under /cgi-bin. The alternative method of CGI scripts living in the root doesn't work until 1.4A. Still, it's best to only refer to CGIs under /cgi-bin even in later versions to avoid ambiguity.
The -m option doesn't work. This wasn't added until 1.4.
Putting Redirect: into files to handle redirection doesn't work. Use <META HTTP-EQUIV="refresh" CONTENT="...;URL=..."> instead. Internal redirection wasn't added until 1.5.
Only GET, HEAD and POST are supported. PUT and DELETE methods weren't added until 1.4A.
NCSA-style logging wasn't supported until 1.5A.

TAMED offers a standard API for TCP sockets which is very complete and works for both assembly and AlphaBASIC applications, but requires 1.4. For a kludgey but functional way to add some arbitrary socket transactions to 1.3, try fingerproxy.

One final note: older versions of FTPD bug out on many graphical clients due not only to the strange filesystem but the missing SIZE command. 1.4A fixed this problem and other issues with crummy clients, but your ugly but dependable command line ftp is not bothered by any of this and works just fine with any version of FTPD. You can cd directly to a PPN, just like LOG from the command prompt. You should be running FTPD with the -n -o options to make it act "like you expect it to," and you may need to force your client not to use passive mode. For example, when connecting to this server from my Fedora workstation, I start ftp with the -A option so passive mode is turned off.

Comments?

Please send me your comments, corrections and suggestions at ckaiser@floodgap.com.

Links and Resources | Downloads | Back to the Alpha Micro Phun Machine