Introduction to JAM
1 About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Working with JAM: Two Scenarios . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Function Keys and Application Execution . . . . . . . . . . . . . . . . . 3
3 JAM Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Control Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Data links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 JAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Control links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Data links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 JAM Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 What do I do now? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Setting Up Your Environment . . . . . . . . . . . . . . . . . . . . . . . 7
6.2 JAM Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3 Organizing JAM Applications . . . . . . . . . . . . . . . . . . . . . . . 9
7 A JAM Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A Sample Key Assignments . . . . . . . . . . . . . . . . . . . . . .14
Appendix B List of Supported Terminals and Emulators . . . . . . . . . . . .15
1 About This Manual
Congratulations on your purchase of JAM, the JYACC Application Manager. Your
documentation includes the following chapters:
The Introduction to JAM (this chapter) describes the rest of the
documentation, and explains the basic concepts and mechanisms of JAM.
The JAM Author's Guide describes in detail how to create the screens
and links that constitute JAM prototypes.
The JAM Programmer's Guide explains some of JAM's internal operation,
shows how to code application routines in the language of your choice,
and describes in detail the support functions supplied with JAM.
The JAM JPL Programmer's Guide describes the JYACC Procedural
Language, a specialized interpreted programming language.
The JAM Configuration and Utilities Guide explains how to create and
alter configuration files for terminals and displays, and how to use
numerous utility programs.
Those who are familiar with JYACC FORMAKER may find that Section 6 of this
chapter and the section on JAM control links in the JAM Author's Guide are
sufficient to get them started.
Even those whose motto is "when all else fails, read the manual" may find the
following nuggets useful:
Section 6 of this chapter
The sections on JAM control fields and data entry keys in the JAM
The keyboard maps and Glossary appended to this chapter
Finally, for those who choose to read it through, this Introduction will provide
a framework of understanding for designing applications with JAM: how the design
process flows, what facilities JAM provides and how they work, and how to use
the individual tools in the JAM package.
Words printed in italics are defined in the Glossary following this chapter.
2 Working with JAM: Two Scenarios
This section presents a quick look at two aspects of JAM: designing an
application and using it.
2.1 Application Design
The first step in designing an interactive application is to break it down into
screens and groups of screens. Very often, things will fall into a simple tree
structure like the one in Figure 1. At other times, the structure of the
application is more complicated, as in Figure 2: here two screens share the
sub-screen marked Application #5, and there are links up as well as down the
menu tree. It is often a good idea, if your application is at all large, to draw
such a picture; it will help to visualize the way your application is organized.
With a basic idea of what you want, you are ready to start up JAM and begin
creating screens. With JAM's free cursor motion and drawing features, your ideas
for screen layout quickly appear; just as quickly, you can test and revise them.
It is easy to create several variations on the same idea and compare them. You
Figure 1: Tree Structure of Screens
Figure 2: Complex Structures of Screens
can also add prompts and help displays, to show others (or to remind yourself)
what is to happen next.
Next, you create links between screens to direct the flow of control and data in
the application. You can group screens under menus, call up sub-windows, have
data entered in windows appear automatically in their parent screens, and call
up existing programs. In fact, you can create a prototype application that looks
exactly like the real one. We call this prototype the application shell, because
it shows what the application will look like on the outside.
Now the process of refining the application shell can begin. This may involve
demonstrating it to a number of people; you can solicit suggestions, and make
and revoke changes on the spot. Since it is just as easy to rearrange the links
between screens as to alter the layout of an individual screen, you can try out
different organizations. In this way, the user interface to an application can
be thrashed out quickly and thoroughly before coding begins.
At this point, the application shell embodies the structure of your application.
Now, you simply add processing routines to the application shell, within the
control structure it provides, and your application is finished!
There is a particular class of application, called "transaction-based
applications", for which JAM is particularly suited, and we sometimes refer to
transactions in this manual. The term connotes a group of related data items and
screens, but is difficult to define precisely. If it is unfamiliar to you,
simply think of a screen or a group of related screens.
2.2 Function Keys and Application Execution
JAM makes heavy use of function keys to control the execution of applications.
Function keys are special keys on a computer or terminal's keyboard, distinct
from those used to enter data. Because the names and positions of keys vary from
one terminal to another, JAM has a notion of logical keys: we speak of "the EXIT
key" or "the TRANSMIT key", even though there is probably no key on your
terminal labeled "EXIT" or "TRANSMIT". JAM has configuration files that tell it
what real keys correspond to its logical keys.
At any rate, function keys tell JAM how to behave. In a menu screen, for
instance, striking arrow or tab keys makes the cursor move from one menu
selection to another. Pressing the Transmit key tells JAM that the item under
the cursor is the right one, and it proceeds to bring up a new screen
corresponding to the menu selection.
In data entry screens there are function keys for moving between fields,
clearing fields, and altering data in fields, as well as the normal keys for
entering data in fields. Again, the Transmit key is often used to tell JAM that
the data on the screen is complete and correct. There are also help keys that
cause explanatory text to be presented. Along with these and other predefined
keys, JAM defines a number of function keys that an application may interpret in
any way it chooses.
3 JAM Concepts
This section defines the major components of a JAM application: screens, control
links, data links, and programs. Here, we simply describe what they do; in
Section 4, some details of how they do it appear.
Screens, arrangements of data on the computer's display, are the basis of an
application designed with JAM. There are a few different types of screens,
described below, but they share the same basic components. Display data are
text, graphics, and borders that do not change. They serve to identify the
screen and its constituent fields, as well as to tell the user what to do. Data
entry and presentation take place in fields, the variable part of a screen.
Fields are often highlighted visually in some way, such as by underlining.
With JAM, you can define many of the characteristics and actions associated with
a field within the screen itself, without resort to programming. Here are some
of the most frequently used:
The field's name
Its data type (dollar amount, character string, etc.)
The field's display attributes (color, highlighting, etc.)
A prompt or help screen explaining the field
Whether data entry in the field is allowed
Whether data in the field should be left- or right-justified
A routine to be called when the field is tabbed through
A calculation to compute the field's value
Items associated with a field are variously called attachments, edits, and
validations. See the Glossary for an explanation of these categories.
Menus are a special kind of screen that guide users to a particular place in an
application. A menu presents a list of choices. When the user picks one, another
screen corresponding to the choice comes up. It may be a sub-menu with further
choices, or it may be a data entry screen for some transaction.
Both data entry screens and menus may be displayed either as base forms or as
windows. A base form covers the entire display; a window typically (but not
always) occupies part of the display, leaving a form partially visible "beneath"
it. Windows are normally subservient in some way to the forms (or other windows)
they overlay, while forms are not.
3.2 Control Links
In the broadest terms, a control link associates something the user of a JAM
application does with the application's response. A common example is that the
user makes a menu selection and JAM responds by bringing up a new screen. More
generally, JAM recognizes two types of action that trigger control links:
and two types of response:
Bring up a new screen
Invoke a program or function
The first response leaves control of the application with JAM. In the second
case, however, control is transferred to the application code, and JAM control
links have no effect until that code returns.
Finally, there are a few specific function keys whose action links are
restricted to one type. There is a GOTO key, which when struck prompts for the
a screen and brings it up; this provides knowledgeable users with
shortcuts through a menu-based system. There is a SYSTEM key, which will prompt
for and execute an operating system command (possibly an escape to the operating
system's command interpreter). And there is an EXIT key, which normally causes
JAM to erase the screen that is currently displayed and return to the previous
3.3 Data links
Data links are most easily described by explaining how they work, which is done
in Section 4.3. Here we shall simply say that important data items can be given
names and shared among various JAM screens and transactions, thereby linking the
data belonging to those transactions. This makes it possible, among other
things, for an item entered in a window to be displayed automatically in the
window's parent form, or even in an unrelated form; and for application code to
refer to data entered in screens that are no longer displayed.
The JAM Database Interface, or JAM/DBi, is an optional subsystem provided with
JAM. It extends data links to a relational database manager.
JAM supplies much of the logic for controlling the flow of data and execution in
an application. Nevertheless there remains, of course, a need for
application-specific code. JAM provides several types of hooks on which
application code can be hung. Among these are the control links just discussed;
attached function field edits, which specify routines to be called when the
cursor enters or leaves a field; and hooks where you can insert special
processing into a number of generic operations, such as keyboard input. These
and other hooks are fully discussed in the Programmer's Guide.
As for the application code itself, it may either be part of the currently
running JAM application, or it may be a separate program (possibly one written
well before the JAM application). The main difference from JAM's point of view
is that code within an application can share control and data links, but code in
separate programs cannot.
In addition to standard programming languages, JAM contains a specialized
programming language called JPL, for JYACC Procedural Language. Since JPL is
interpreted, it speeds up prototyping by eliminating the edit-compile-link
cycle; and it contains special features for manipulating JAM data items.
4 JAM Mechanisms
In this section we explain a bit about how JAM works, with a view toward giving
application designers a firmer conception of how to use its features.
Screens are stored as files and are referenced by name, although they may reside
either on disk or in memory. All information about a screen's display data,
fields, and edits are stored in this file. Also in the screen file are the
control and data links active when that screen is displayed; they reside and are
changed with the screen, not in some central location. When JAM displays a menu,
form, or window, it reads the file with the corresponding name and builds
structures in memory to represent the fields and links.
Menu screens are distinguished from data entry screens by the presence of a
field named jam_menu.
4.2 Control links
Control links are implemented through control strings stored in the screen. On a
menu, the control strings appear in special fields following the menu
the control strings associated with function keys are stored
offscreen. In either case, the first character of the string identifies the type
of action, as follows:
^ call an application routine
! execute another program
& bring up a window
bring up a base form
Following that is the name of the screen, program, or application routine. (For
a base form, the first character is included in the name.)
JAM traces an application's flow of control. Every time a JAM application brings
up a new screen, JAM stores the name of the screen. This makes it possible to
return up the path to a previously visited screen by using the EXIT key.
4.3 Data links
Each JAM application has a data dictionary file which holds a list of named data
items, with all their characteristics. These data items are linked to screens by
name; that is, a field whose name is the same as that of a data dictionary entry
will share its value with that entry. When the screen is brought up, the field
will be initialized to the shared value.
If new information is subsequently entered into such a field, the resulting
value will be stored under the shared name. It will be stored not in the data
dictionary itself, but in a memory-resident structure called the local data
block or LDB, which provides a dynamic copy of the data dictionary. When you
move between screens, the LDB preserves the newly entered values of all data
items listed in the data dictionary.
The exact behavior of a named data item is governed by the scope of the data
item, one of its permanent characteristics stored in the data dictionary. Items
having the same scope can be erased and reinitialized as a group.
The JAM Database Interface uses a query and data management language, such as
SQL, to link database fields to the LDB and screen. Here the database field or
column names correspond to data dictionary names.
We defer detailed discussion of JAM programs to the Programmer's Guide, and make
only a couple of general points. Programs, like other items in JAM, are referred
to by name, and the names and addresses of application routines referenced by
control links must be installed in a special list called the function list.
Programs can access named data and screen items through function calls supplied
in the JAM library.
JPL procedures, on the other hand, can access named data and screen items
directly, treating them like global variables. If you have JAM/DBi, your SQL or
other database language statements are incorporated into JPL procedures. Refer
to the JPL Programmer's Guide, and the JAM Database Interface Guide.
5 JAM Tools
This section summarizes the authoring and programming tools supplied with JAM,
and how they support the features described in Sections 3 and 4.
JAM includes two distinct environments, called the authoring environment and the
application environment. All prior discussion has referred to the application
environment. The authoring environment is identical, with two significant
additions: someone running in the authoring environment can call up the JAM
screen editor and the data dictionary editor.
The authoring utility, JXFORM, is a tool for defining screens and control links;
it includes a screen editor, which you use to create display data, fields and
their edits, and the control fields that specify control links. JXFORM also
contains a syntax-checking data dictionary editor. There are special functions
in the screen editor for automatically creating fields linked by name to data
dictionary items. Both the screen editor and data dictionary editor are fully
documented in the JAM Author's Guide.
The JAM library is an extensive collection of functions for reading and writing
data contained in forms and in the Local Data Block. There are functions for
displaying screens and getting keyboard input, for applications where standard
JAM control is not appropriate. Much more information, and a description of each
entry point, are available in the Programmer's Guide.
The following utility programs, and more, are described in the Configuration
Guide; the introduction to that chapter contains a summary of all utilities.
All configuration files are supplied as text files you can modify with an
editor; each also has a binary format that JAM uses at run-time. Msg2bin,
key2bin, vid2bin, and var2bin convert ASCII message, key, video, and setup files
(respectively) to binary. Modkey is a specialized editor for keyboard
configuration files, and term2vid can create a primitive video file from a
terminfo or termcap database. There are also several utilities for managing the
configuration of JAM applications. One called jammap creates a cross-reference
listing of all the JAM screens in a application, with their control strings.
Another, bin2c, converts binary configuration files to C language source files;
f2struct and dd2struct create programming language data objects from screens and
data dictionary records. Dd2asc and ddmerge can be used to list, edit, transport
and combine data dictionary files. Finally, f2r4 and dd2r4 convert JAM release 3
screens and data dictionaries to Release 4.0 format.
6 What do I do now?
If JAM has not yet been installed on your computer, please refer to the
Installation Notes for guidance, and return to this section when you are ready
to try out the newly installed software.
Sit down at your computer or terminal and invoke the JAM authoring utility by
at the system prompt. If all is well, the screen will clear, and you may see
some messages at the top referring to missing data dictionary files; you are
ready to begin. Turn to the JAM Author's Guide and follow the instructions
there. If, on the other hand, the computer prints only a single error message,
there are some things to set up in your environment.
6.1 Setting Up Your Environment
If the message you see resembles one of the following:
Bad command or filename(MSDOS)
jxform not found (UNIX/XENIX)
Not found. JXFORM (std$cp)
then the directory where JAM resides is not in your execution path, and you must
add it. Here are some examples of how to do this:
PATH=$PATH:/usr/jam; export PATH (UNIX, Shell)
set path=($path /usr/jam) (UNIX, C shell)
PATH c:\bin;c:\usr\bin;c:\jam (MSDOS)
MS-DOS note: You must type in the old value of the path by hand; it can be
obtained by typing 'path' with no argument.
PRIMOS note: There is no environment; you must either install the screen editor
in CMDNC0, or define an abbreviation to run it from the installation directory.
JAM Configuration Variables
If the message you see is
SMMSGS not found
then you need to define JAM configuration variables. (If it is SMVIDEO not found
or SMKEY not found, you probably just need to set SMTERM; but bear with us for a
moment.) Here are the variables and their meanings:
SMMSGS pathname of a file containing error message text SMKEY
pathname of a keyboard configuration file SMVIDEO
pathname of a display configuration file SMVARS
pathname of an abbreviation file containing all three
abbreviates your terminal's make and model
The first three are the ones you really need. They tell JAM where to find its
configuration files: one with error message text, another that maps your
terminal's keys to JAM's logical keys, and a third that tells JAM how to control
your terminal's display.
These files are normally installed in a subdirectory named config of the
directory where JAM was installed. The default message file is called
msgfile.bin. The video and keyboard files come in pairs; their names consist of
a prefix corresponding to the terminal type followed by vid.bin and keys.bin
respectively, as in
for the DEC VT-100. The config subdirectory contains a file named smvars, with
pathnames of all the configuration files qualified by the terminals to which
Anyway, once you've found the files you need, the most straightforward thing to
do is to assign their full pathnames to the SMMSGS, SMKEY, and SMVIDEO
variables. An alternative is to set the SMVARS variable to the pathname of the
smvars.bin file in the JAM config directory, and your SMTERM to your terminal
abbreviation. Then, JAM will find the files flagged with your terminal type in
the smvars file.
PRIMOS note: The configuration files are in a top-level directory named
FORMAKER*, and there is no environment; JAM will prompt for your terminal type.
MS-DOS/XENIX note: For consoles, the key file is IBMkeys.bin; the video file is
bwvid.bin for monochrome monitors, and colvid.bin for color monitors.
If Your Terminal Isn't Configured
There is a list of terminals for which JYACC distributes configuration files in
an Appendix to this chapter. If you cannot find distributed configuration files
for your specific model, check for emulations. Many popular terminals, for
instance, emulate the DEC VT-100; others may support the ANSI standard escape
sequences. If that doesn't work, you will need to create your own; the JAM
Configuration Guide will help you through that process.
6.2 JAM Function Keys
JAM interprets a number of keys specially. Here is a list of their names and
functions. To find out how these logical functions are assigned to your
terminal's keys, examine the key translation file, or run the modkey utility on
it. Modkey, described in the Configuration Guide, contains a key translation
test screen that you can use to check your key mappings. To find the key file,
see the previous section; listings for the IBM PC and Wyse 85 are appended as
examples. There is a much more detailed summary of special keys in the Author's
Guide, in the section on data entry.
JAM Navigation Functions
TRANSMIT Menu selection or end of data entry EXIT
Abort data entry, return to previous screen SPF1
Return to top-level screen SPF2
Escape temporarily to the operating system SPF3
Go directly to a named screen
JAM Authoring Functions
SPF5 Invoke the screen editor SPF6
Invoke the data dictionary editor
Up Arrow Cursor up one line or field Down Arrow
Cursor down one line or field Left Arrow
Cursor left one column or field Right Arrow
Cursor right one column or field Tab
Next field Backtab
Previous field Return
Next field on following line Page Up
Scroll data up in scrolling field Page Down
Scroll data down in scrolling field
Insert Toggles insert/overwrite mode Delete
Deletes character under cursor Backspace
Deletes character to left of cursor Field Erase
Erase from cursor to end of field Clear Screen
Erase all unprotected fields
PF1-PF24 These are commonly assigned to the otherwise APP1-APP24
unnamed function keys on a terminal. SPF7-SPF24
6.3 Organizing JAM Applications
It is a good idea to keep all the screens belonging to a JAM application in one
directory. Limited sharing of screens among applications can be accomplished by
use of the SMPATH environment variable, which is explained in the Programmer's
Guide. Application code can be maintained in subdirectories of the application
directory. This is generally more convenient than placing screens and code in
subdirectories of a common parent.
7 A JAM Glossary
See run-time environment.
application shell The structure of JAM screens and links that defines the
look and control flow of an application; everything but
array Several fields grouped together in one place, that can be
treated as a unit. The elements of an array share all
characteristics, such as scrolling, and can be referred
to as occurrences of the first field in the array.
attached function An application routine associated with a field that is
called with certain parameters whenever the cursor enters
or exits the field. Also, an application routine
associated with a screen and called upon screen entry or
author A person whose task is to create a JAM application shell
or prototype; connotes an application designer without
training in programming.
authoring environment The tools used to create and test JAM screens and links,
comprising the screen editor, data dictionary editor, and
border Text or highlighting used to mark the outline of a
character edits A field's character edit defines what type of character
may be entered in a field, such as digits, letters, or a
control field In a JAM menu, a field following a menu selection that
contains a control string to be executed when that
selection is chosen.
control link An association between something a JAM user does (menu
selection or function key) and JAM's response (bring up a
new screen or call an application program).
control path A list (actually a stack) of the names of all the screens
entered via JAM control links, and not yet exited.
control string A special string, usually not displayed, used to implement
control links. The name or location of a control string
identifies the event that triggers the link, while its
contents define the action to be taken.
cursor A special marker on the display, commonly a blinking block
or underline, that shows where the text you type will go.
data dictionary A list of named data items and all their characteristics.
data link The sharing of values among data items in different
screens that share a name with a data dictionary entry.
display A physical screen, such as a terminal on a multi-user
computer or the monitor on a personal computer.
display attribute Visible characteristics of data on the screen, such as
underlining, or blinking.
display data The fixed part of a screen: text, borders, and graphics
that do not change. Distinct from fields, which may be
altered by the program or by data entry.
element A field that is part of an array. An array element may be
referred to either by its own field number, or by the name
of the array plus its element number. A non-array field is
considered to have a single element.
element number A field's element number is its position within the array
it belongs to. The element number of a simple field is 1.
field A variable area of a screen, used for the exchange of
data between an application and its user. A single field
occupies part or all of one line. It may be extended
horizontally through shifting, and vertically through
scrolling. Fields may have many characteristics and
actions associated with them, known variously as edits,
attachments, and validations.
field attachment An item associated with but distinct from a field.
Examples include a help screen, a prompt, an attached
function, a calculation, or a menu of possible items for
field edits Field edits either restrict the data that can be entered
into a field, or alter its appearance. Examples include a
range of permissible values, right justification,
conversion to upper case, and dollar amount format.
field number JAM numbers fields according to their positions within a
screen, from left to right then top to bottom, beginning
at 1. When a field is spoken of as "next" or "following"
another field, this is the ordering that applies.
field validation An action associated with a field that checks data entered
there for correctness.
form A screen that occupies the entire display and does not
overlay another screen, as opposed to a window. Often used
loosely as synonymous with screen.
function key A key that has some special function other than data
entry, for instance cursor motion. JAM treats such keys as
logical keys, referring to what they do rather than to
their labels on the keyboard, since the labels are
different for the many keyboards it supports.
function list A list of pairs of function names and addresses, compiled
into JAM applications to provide necessary linkage.
help screen A screen containing any information helpful to the user of
a JAM application. Help screens may be attached to JAM
screens and fields; they appear when the HELP or FORMHELP
function keys are struck.
hook A software device by which an application routine is made
known to JAM, specifying its name, address, and language.
The two most important kinds of hooks are attached
functions and invoked functions.
invoked function An application routine that is triggered by a control
link. Also called a caret function.
item Data entered into a scrolling field, or into one field of
a scrolling array.
item number The position of an item within its scroll list. The item
number does not depend on the item's position on the
justification Data in JAM fields may be either right- or left-justified,
that is, pushed all the way to the right- or left-hand end
of the field.
LDB See local data block.
library The JAM function library, which contains routines
application programmers can use to access data in screens
and the local data block.
link See control link and data link.
local data block A dynamic copy of the data dictionary, which holds the
values of items that have been changed by data entry or
logical key JAM's interpretation of a function key, as opposed to the
physical key on a terminal. Physical keys are mapped to
logical keys by a configuration file.
menu A screen containing a list of choices, from which the user
may select one.
occurrence A general term covering simple fields, array elements, and
items of scroll lists. In a scrolling field or array,
occurrence is equivalent to item; in a non-scrolling
array, it is equivalent to element.
occurrence number A data item's element number or item number, whichever
applies. If the field is neither scrolling nor part of an
array, the occurrence number is 1.
parallel array Scrolling arrays placed next to one another will scroll in
parallel, i.e. whenever one array is scrolled with the
cursor or page keys the associated arrays scroll
prompt Text associated with a field that appears on the
terminal's status line whenever the cursor enters the
field. Also called status text.
prototype A collection of JAM screens and control links used for
testing the user interface to a new application; similar
to the application shell, but used in different
protected field A field into which no data may be entered from the
run-time environment The JAM code that processes control links, displays
screens, controls data entry, and handles the calling of
scope Data dictionary entries all have a scope, which is a
number between one and nine. Entries having the same scope
can be erased and reinitialized as a group.
screen Data to be displayed on a computer's terminal or display,
such as menus and data entry forms. When the hardware
display itself is meant, the terms physical screen or
display are used.
screen editor A JAM tool used to create and alter screens and control
scrolling JAM screens may contain data lists that are too long to
fit in available space; such lists may be scrolled, either
in a single field or in an array of fields. The cursor
motion keys cause different parts of the list to appear on
scroll list A data list displayed through a scrolling field or array.
shifting A data item too wide to fit in a field may be shifted
horizontally; the cursor motion keys will cause different
parts of the item to appear in the field.
status line JAM sets aside one line of the physical screen, usually
the bottom one, for error and status messages; it is
called the status line.
status text See prompt.
system date The current date, as stored in the computer. JAM date
fields can be automatically initialized to the system
system time The current time, as stored in the computer. JAM time
fields can be automatically initialized to the system
transaction A related group of screens and data items.
user date A date entered into a JAM date field by the user of an
user time A time entered into a JAM time field by the user of an
window A screen that normally does not cover the whole physical
screen, and overlays some other screen or screens.
word wrap Fields and scrolling arrays may have a word wrap edit,
which will cause whole words to be kept together on the
same line of text. (JAM's default is to fill the field
with characters, without regard to word spacing.)
zoom Shifting and scrolling fields may be viewed and edited as
a whole, in a pop-up window, using a special zoom key.
Appendix A Sample Key Assignments
You will find explanations of the key names used here in the section of the
Author's Guide entitled Data Entry.
JAM key assignments for the IBM PC family:
EXIT = Esc TRANSMIT
= End HELP
= control-F1 FORM HELP
= alt-F1 LOCAL PRINT
= control-P RETURN
= Enter TAB
= Tab BACKTAB
= shift-Tab BACKSPACE
= control-H HOME
= Home PAGE UP
= Pg Up PAGE DOWN
= Pg Dn INSERT MODE
= Ins INSERT LINE
= control-K DELETE CHAR
= Del ERASE
= control-Pg Up CLEAR ALL
= control-Pg Dn ZOOM
= control-Z PF1
= F1 ... PF10
= F10 SPF1
= shift-F1 ... SPF10
JAM key assignments for the Wyse 85:
EXIT = F11 TRANSMIT
= Do HELP
= Help TAB
= Tab or control-I
= F12 HOME
= F14 BACKSPACE
= control-H DELETE CHAR
= Remove INSERT MODE
= Insert Here ERASE
= Select CLEAR ALL
= control-Z PAGE DOWN
= Next Scrn PAGE UP
= Prev Scrn RESCREEN
= Find ZOOM
= control-E PF2
= F6 ... PF6
= F10 PF7
= F17 ... PF10
= F20 SPF1
= PF4 1 ... SPF9
= PF4 9
Appendix B List of Supported Terminals and Emulators
The following list is subject to constant revision, usually by having more
things added to it. The mnemonics listed can be found as prefixes to key and
video files in the config subdirectory of your JAM distribution. As distributed
by JYACC, names of video files end in vid and names of key files end in keys.
You may find that you need to shorten or otherwise alter some of the names, to
suit your operating system or your own naming conventions.
Terminal mnemonic Description
5425t AT&T 4425 terminal.
7900 NCR 7900 M1+ terminal.
FT Fortune Systems terminal.
TV9220 TeleVideo 9220 terminal. Also found as NTV9220,
WTV9220 for 80- and 132-column modes
TVO TeleVideo 955 terminal with onscreen attributes.
W85 Wyse 85 terminal. Also found as NW85, WW85 for
80- and 132-column modes respectively.
a219 Ampex 219 terminal (in native mode).
ansi Color PC console for SCO XENIX.
avt HDS AVT terminal.
bw Monochrome monitor on MS-DOS system.
c108 Concept 108 terminal.
col Color monitor on MS-DOS system.
cpt200 Color PC with PCLINK emulating a PRIME PT200
d214 Data General Dasher 214 terminal (in DG mode).
f100 Freedom 100 terminal.
h0 Honeywell VIP 7300 terminal.
hds HDS model 200 terminal.
host Basic ANSI terminal or emulator, with color.
hostpc Stratus PCTERM emulator, monochrome or color.
hp Hewlett-Packard 2392a terminal.
iii TeleVideo 955 terminal, with onscreen attributes
j8, j8c Monochrome and color PC, respectively, with JYACC
jterm emulator and 8-bit control sequences.
jterm, jtermc Monochrome and color PC, respectively, with JYACC
opus220 Opus 220 terminal.
pc Either monochrome or color PC with generic VT-100
pt200, pt132 PRIME pt200 terminal, in 80- or 132-column mode;
also monochrome PC with PCLINK emulator.
pt200w PRIME pt200 in 48-line mode.
svt200 Sperry SVT1220 terminal.
ti931 Texas Instruments 931 terminal.
tvi921 TeleVideo 921 terminal with onscreen attributes.
tvi950 TeleVideo 950 terminal with area attributes.
tvi955 TeleVideo 955 terminal with area attributes.
v101 Stratus V101 terminal.
v102 Stratus V102 terminal.
vt100 DEC VT-100 terminal or emulator.
vt200 DEC VT-200 terminal or emulator.
vt220 DEC vt220 terminal or emulator.
wy30 Wyse 30 terminal, or HP 700/41 emulating the
wy50 Wyse 50 terminal.
wy75 Wyse 75 terminal.
x100, x100c Monochrome or color PC with Crosstalk emulating a
In this Index, library functions are displayed in
boldface, without the prefixes specific to the
language interface. Video and setup file entries
appear in ELITE CAPS, while utility programs and JPL
commands are in elite lower-case. Function key names
are in ROMAN CAPS.
data link 1-5, 1-6
A definition 1-10
application Dd2asc utility 1-7
design 1-1 dd2r4 utility 1-7
prototype 1-2 dd2struct utility 1-7
application environment 1-6 ddmerge utility 1-7
definition 1-10 display
application shell 1-2 definition 1-10
definition 1-10 display attribute
array definition 1-10
definition 1-10 display data 1-4
attached function 1-5 definition 1-11
definition 1-10 element
authoring environment 1-6 definition 1-11
definition 1-10 element number
authoring utility 1-7 definition 1-11
EXIT key 1-9
bin2c utility 1-7 F
border f2r4 utility 1-7
definition 1-10 f2struct utility 1-7
C definition 1-11
character edits field attachment
definition 1-10 definition 1-11
configuration 1-7 field edits
control field definition 1-11
definition 1-10 field number
control link 1-4 definition 1-11
definition 1-10 field validation
control path 1-6 definition 1-11
definition 1-10 form 1-4
control string 1-6 definition 1-11
definition 1-10 function key 1-4
cursor definition 1-11
definition 1-10 EXIT 1-9
D SPF2 1-9
data dictionary 1-6 SPF3 1-9
definition 1-10 SPF5 1-9
editor 1-7 SPF6 1-9
TRANSMIT 1-9 definition 1-12
function keys 1-3 prototype
function library 1-7 definition 1-12
function list 1-6
definition 1-11 R
H definition 1-12
definition 1-11 S
hook 1-5 scope 1-6
definition 1-11 definition 1-12
I definition 1-12
invoked function 1-4 screen editor
definition 1-11 definition 1-13
item scroll list
definition 1-11 definition 1-13
item number scrolling
definition 1-12 definition 1-13
J definition 1-13
JAM SMKEY setup variable 1-8
basic concepts 1-3 SMMSGS setup variable 1-8
getting started with 1-7 SMTERM setup variable 1-8
internals 1-5 SMVARS setup variable 1-8
overview of 1-1 SMVIDEO setup variable 1-8
jammap utility 1-7 SPF1 key 1-9
justification SPF2 key 1-9
definition 1-12 SPF3 key 1-9
SPF5 key 1-9
K SPF6 key 1-9
key2bin utility 1-7 status line
L status text
LDB 1-6 definition 1-13
definition 1-12 system date
library definition 1-13
definition 1-12 system time
link definition 1-13
local data block T
definition 1-12 term2vid utility 1-7
logical key transaction 1-3
definition 1-12 definition 1-13
logical keys 1-3 TRANSMIT key 1-9
menu 1-4, 1-5 user date
definition 1-12 definition 1-13
Modkey utility 1-7, 1-9 user time
Msg2bin utility 1-7 definition 1-13
occurrence var2bin utility 1-7
definition 1-12 vid2bin utility 1-7
definition 1-12 W
P definition 1-13
parallel array word wrap
definition 1-12 definition 1-13
definition 1-12 Z
protected field zoom