Although A-Shell operates in the Linux and Windows environments, it borrows a number of architectural concepts along with associated acronyms and terminology from earlier operating systems, most recently AMOS but also its predecessors in the minicomputer world, particularly DEC RSTS, as well as other modern programming languages that the reader may or may not be familiar with. Several of the terms are defined here and subsequently referenced throughout this document without further elaboration.
Please take a quick look down this page and read up on any terms with which you are not familiar. A few terms native to A-Shell are included at the bottom.
AMIGOS
An AMOS component supporting certain extended terminal functions, particularly the ability to save/restore rectangular areas. A-Shell supports the main features via TAB(-1,148) and TAB(-1,149) (see Tab Functions), as well as TRACKER (see topic on this page).
AMOS
An acronym for the Alpha Micro Operating System. AMOS was a microcomputer-based multi-user system running on the Alpha Micro family of computers. The AM computers were originally built around the Western Digital WD16 and later the Motorola 68K family of processors. The Alpha Micro was introduced in the late 1970s, with a heyday in the 80s and early 90s. It was revolutionary for its time, offering minicomputer-like capabilities at microcomputer prices, consequently attracting the attention of business application developers who thrived for a decade or so. Most of these independent developers were squeezed out of the market by Windows and UNIX, as networking improvements started to make Linux viable for multi-user applications and improving processor performance began to make the Windows-based business machines cost-competitive. A-Shell was originally conceived as a bridge for those developers wanting/needing to migrate their applications from AMOS to the more popular operating systems.
ASB
An acronym for A-Shell Basic, A-Shell's application development language.
ATE
An acronym for A-Shell Terminal Emulator, the standard client used for connecting to A-Shell servers via telnet or ssh. In addition to the typical capabilities common to terminals and terminal emulators, ATE also supports an extensive set of advanced client/server capabilities including support for building a Windows-based GUI, remote execution, file transfer, etc. See the separate ATE Reference for more information.
AUI
An acronym for the A-Shell User Interface, a framework allowing applications to build GUI applications dynamically. Two unique aspects of AUI are that it allows for the possibility of integrating GUI elements into to existing plain text applications (incrementally, without requiring an all-or-nothing rewrite), and it supports client-side GUI over telnet/ssh connections, even when the server is Linux. See the AUI subroutine for more details.
CGI
Acronym for Common Gateway Interface (not to be confused with computer-generated imagery), a web standard for communicating between browsers and back-end programs via a web server. See A-Shell as a CGI Engine and CGIUTL.
Device
Aside from the more general meaning of a thing designed or adapted for a purpose, or in the computer context, a storage device like a disk drive, within the A-Shell context it refers to the first part of the DevPPN file system organization, which has the format <name><unit#> followed by a colon. The <name> part must be three or four alphabetic characters (not case sensitive), the <unit #> one to three digits, with the total length between 4 and 6 characters plus the trailing colon, e.g. DSK0:, SDA123:, BACK99:, etc. Historically the <name> was intended as a reference to a physical storage device, while the <unit#> was typically a partition within that device although in the Windows and UNIX environments, each A-Shell Device maps to an arbitrary path by means of DEVICE directives in the system configuration file.
DevPPN
Hybrid abbreviation/acronym (Device Project Program{mer} Number}; a framework for organizing disk storage into Devices and PPNs. See the DevPPN topic in File System Organization for more details.
GDI
Acronym for Graphic Device Interface, a Windows component used by A-Shell to support graphic printing capabilities. See GDI Printing.
INFLD
Pronounced "infield." The name of A-Shell's internal field-level keyboard input mechanism underlying all other keyboard input mechanisms, including the command prompt, ASB INPUT statements, Xcall input routines such as INPUT, SBXINP, and INMEMO, and the AUI edit control. See Xcall INFLD for a complete reference to its capabilities.
Insight
An AMOS component supporting certain text-based mouse interactions. A-Shell supports some of those ancient methods among others; see Mouse Interaction.
ISAM
Acronym for Indexed Sequential Access Method, a file structure supporting both direct and sequential access. Each ISAM file unit is actually made up of a data (.DAT) file and one or more index (.IDX) files. A-Shell actually supports two ISAM frameworks: the traditional one and a more advanced version called ISAM-A. See ISMBLD, ISMDMP and ISAM Files for more details.
ISAM-A
Newer / alternative variation of ISAM. See ISAM-A for general information, including a comparison against ISAM, and ISAM-A Files for syntax details.
Job
An instance of A-Shell, equivalent to a pid in the Windows or UNIX environments. Each job has a unique Job Name consisting of six upper case alphabetic characters, either specified by the -j command line switch or auto-generated. In the latter case, the format is TSKAAA thru TSKZZZ for interactive instances (with real terminals) or TASAAA thru TASZZZ for background tasks. Each Job also has a corresponding Terminal (aka TRMDEF) with the same name, and a Job Number indicating its position in the Job Table, ranging from one thru the maximum number of jobs recently in use. The names and numbers are reused as instances are released. Use JOBALC to display your own job name, and Job Table on this page for related information.
Job Table, aka JOBTBL
Table keeping track of Job activity maintained in a file jobtbl.sys whose size is determined by the license in conjunction with the MAXJOBS directive in the system configuration file. Supports administrative commands such as SYSTAT, JSTAT, SEND, KILL, FORCE, etc.
LDF
An acronym for Language Definition File, A-Shell's version of the various language/locale settings supported by various operating systems. LDF files are stored in DSK0:[1,6] as langabbr.LDF with a particular one being activated via the LANGUAGE directive in the system configuration file, or the SET command. Details may be queried via Xcall GTLANG.
LOKSER
The historic name for a particular model of file locking built based on the underlying operating system's file locking capabilities and exposed mainly through variations of ASB file I/O statements such as OPEN, READ, and WRITE. Must be enabled in the LOKSER directive in the system configuration file or with the SET command. Applications that do their own QFLOCK-based locking may prefer to leave LOKSER disabled to avoid having to navigate the various LOKSER rules for file access.
MAP
Noun / verb / adjective reference to variable declaration (see MAP statements) in general or possibly to a type of collection (i.e. ordered map).
MIAME
Historical acronym for Machine Independent Alpha Micro Environment (pronounced like the city in Florida). Although outdated, it continues to be used as the standard base directory for A-Shell installations. See Configuration.
MIAMEX
The name of a particular XCALL subroutine with over 200 sub-functions (i.e. "MIAMEX functions") for accessing A-Shell and host OS internals, system-level features and operations, and operations to small or obscure to be worth separate XCALL implementations.
P2P
Acronym for Peer-To-Peer, and network confirmation made up of workstations with file sharing capability. Typical environment for small Windows-based A-Shell installations (where any of the workstations can act as the "server" simply by hosting the file directories).
Server/Client
A seemingly backwards variation of the more common "client/server" (architecture) which more aptly describes ATE-based systems. In the traditional client/server scenario (e.g. web browser application), the client is driving the action, running the primary application logic and making requests to the server for information. By contrast, in the ATE framework, the application runs on the server, which drives the action but makes requests to the ATE client to extend the capabilities of the server (e.g. displaying a GUI front-end, executing SBX routines and client-side Windows commands, retrieving information from the client environment, etc.)
PPN
An acronym for Project, Program{mer} Number; a two-level directory organization scheme consisting of two numbers from 0-999, typically formatted as [p,pn], e.g. [7,6] or [257,0]. The first number is known as the "Project", typically used to group related files or programs, such as a module like AR or GL within a larger application. The second number, more cryptically known as the "Program{mer} Number" is in practice used for sub-grouping files by type or ownership or other attribution within a project. For example, a project 50, corresponding to, say, an order entry module, might be sub-divided into the the following:
[50,0] - RUN programs; the ,0 directory is automatically part of the project search path
[50,100] - Common source include files
[50,101] - Projection source files
[50,102] - Beta source files
[50,121] - Hector's development/test directory
[50,122] - Elvira's development/test directory
[50,400] - Common data files
[50,401] - Tuscaloosa division data files
[50,402] - Topolobompo division data files
[50,403] - Transylvania division data files
etc.
In the Windows and UNIX environments, PPNs are mapped to native directories with 6 digit names by expanding both parts into three digits, i.e. [1,4] maps to 001004, [50,122] maps to 050122, etc.
Note that Project numbers 1 thru 9 are traditionally reserved for system use. See DevPPN for more details, the PPN system command to display existing PPNs, and the SYSACT system command for creating new PPNs.
QFLOCK
A reference to the system file qflock.sys used for maintaining a variety of application-level inter-Job locks. Alternative or adjunct to the OS-level file locking system LOKSER. See A-Shell subroutines XLOCK and FLOCK.
SBX
File extension identifying XCALL subroutine modules; may be used an adjective (e.g. "SBX files").
TCRT
An acronym (for Tab Cathode Ray Tube?) referring to a set of extended terminal commands invoked via TAB(-n,f) commands. The negative first parameter separates these commands from the standard TAB(row,col) commands for cursor positioning and identifies the group of commands such as display functions, color, layout, ATE functions, etc. See Terminal Functions for more details.
Terminal, aka TRMDEF
The name for the terminal device—serial or network, real or virtual—attached to a Job. Given that each Job is attached to a Terminal of the same name, the distinction between them is mostly lost and can be ignored in modern networked environments. The concept of attaching terminals to jobs was more salient in the days where terminal devices were hard wired to serial ports. See the TRMDEF system parameter for additional details.
TRACKER
The historic name of a subsystem for tracking the text-based contents of the screen, allowing text-based applications to save and restore areas of the screen in order to implement pop-up windows or toggling between logical screen displays, typically using the subroutines MSBOXX or SWPSBR. Also see the WSET command.
XCALL
An abbreviation for eXternal CALL, used as verb, noun or adjective, whether referring to the action, the target routine/module, or the variation of type of ASB control statement. The XCALL mechanism allows ASB to dynamically load and invoke subroutines/procedures/functions within external modules written in other languages, complete with parameter passing by value or reference, whether to access capabilities otherwise not available (e.g. pointers) or not efficient (e.g. low level raw memory access), or to tap into existing shareable libraries (DLLs or Linux .so files; see DYNLIB) to avoid reinventing the wheel. Historically XCALL routines were written in assembler; in the A-Shell world they are typically written in C, or even ASB itself, where the primary motivation would be modularity. A-Shell is distributed with a couple of hundred standard XCALLs, to which most application developers add their own. See Subroutines for more details.
