Most service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download
Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing.
If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.
XEROX
BUSINESS SYSTEMS
Systems Development Division
November 26. 1977
i1 SDD nCBlftS
~o a un~erstood
1 bave read an
To: User Interface Group
pages_------
To_-----
From: Dave Smith / SO at Palo Alto Date~_---
ReViewer-----_-;-ef.. .:::/ 1 '$ !? 12 ;:..32'1
Subject: On Janus Procedures f of pages_ -
Filed on: janus-procedures.press
Disclaimer: This paper has no relationship to the section that wilt go in the Janus Functional
Spec. It is strictly a "think piece" discussing what I think are interesting ideas concerning
procedures. The Functional Spec section will. of course, omit all of the philosophical discourse
(otherwise known as bullshit).
Second Disclaimer: There are various ideas floating around the Janus program as to what
"procedures" should be used for:
- automating repetitive tasks (me, Paul)
- data management (Richard, Peter Bishop, Linda, Ron Johnson?)
- information flow control (OfficeTalk, Richard?, Peter Bishop?, Ron Johnson?)
- others?
I don't think these are necessarily disjoint; in fact I expect the procedure design discussed here to
be applicable to all of the application areas above; certainly by the second or third release of
Janus. However focusing on an application has tended to lead the designers down different
paths. I am concentrating on procedures as recorded sequences 0/ user actions, I.e. as macros.
Therefore, to clarify that this is what I mean by "procedure", I will use the term "user macro" or
simply "macro" instead of "procedure" in this memo. Hopefully this will integrate with whatever
other procedure facilities people implement (e.g. records processing).
Goals
The user macro design described here is intended to accomplish two goals:
1. To permit the average user to "program" his Janus system. The main purpose of the
programming is to automate his repetitive tasks. A user who cannot program his
computer can only exploit a fraction of its power.
2
2. To make the programming no more difficult than the normal operation of the system.
This goal is, of course, not absolutely achievable; however I believe that this design comes
close.
If we can achieve goal #1, then programming will be available -- for the first time -- to a vastly
larger class of users. If we can achieve goal #2, then our users may find themselves doing quite a
lot of programming. Ideally they will come to rely heavily on programs in their everyday work
habits. Only when this happens can we rightly say that we have "automated the office".
Background
There are in existence today several good models for the type of user programming which I
would like to see incorporated into Janus (at least in the first release -- later releases will
probably require more complicated concepts).
The first thing to observe is that goal #2 has already been attained in limited contexts. Consider
Bravo.
Bravo "replay" transcripts
Bravo builds up a "program" in the background during every editing session. A replay
transcript is a "program" under any reasonable definition because it uses one or more
inputs (text files), contains a machine-executable sequence of instructions (the Bravo
commands), and produces one or more outputs (text files). (The fact that it operates only
on text files and only on the specific text files for which it was defined does not alter the
fact that a replay transcript is a program; it is simply a limited-capability program.)
The fact that Bravo builds a replay file in the background does not make Bravo any
harder to use than if it didn't build the file. Secretaries could use Bravo in either case.
(But a question to be investigated is whether generalizing the replay transcript notion will
keep it as easy to use.)
The next thing to observe is that goal #1 also has already been attained by various systems. One
of the earliest was the Unimate "robot". The following description of the Unimate is taken from
my thesis. It illustrates that a person does not have to be a "computer scientist" to program a
computer; in the Unimate case the programmer is a machinist.
Unimate robot
"The Unimate robot consists of a mechanical arm with 6 degrees of freedom mounted
above a large base containing electronics. It is a programmable manipulator designed for
industrial applications.
"The robot may be operated in either of two modes: training mode or production mode.
In training mode, the robot's are is guided through the steps necessary to perform a task
by a human 'trainer', The robot has a digital electronic memory in which it can
'remember' up to 1024 operations and their timing, Typical operations are 'rotate a joint',
3
'move to (x,y)', 'close the hand', etc. After the training phase the robot can operate in
production mode, automatically repeating the operations in its memory. It will repeat the
operations indefinitely, until stopped or until a pathological condition occurs.
"The robot has been particularly successful on assembly lines. General Motors is
presently using 26 Unimate robots to do 80% of the final welding on its Vega assembly
line. The primary practical deficiencies of the robot are the absence of (a) conditional
branching and (b) force or visual feedback. From a conceptual standpoint. the robot is a
relatively uninteresting computer since its only data structures are (x,y) coordinates.
"However the Unimate demonstrates the potential of dynamic, analogical programming.
Rather than writing an algorithm whose form bears no resemblance to the task to be
done, programming occurs by actually doing the task. Advantages:
"(1) The act of programming is analogous to the function of the program being written.
It is learning by doing. Programming is exceptionally clear and easy.
"(2) An untrained operator can program the robot. 'untrained' in the sense that he need
have little knowledge of computer programming -- he need only be familiar with the task
the robot is to perform. This makes the robot accessible to a large class of users.
"(3) Bug-free programs can be written the first time. Since programming involves doing
the task once, successful completion of the task means that a correct program has been
written (modulo mechanical and/or timing inaccuracies)."
These three characteristics are also desireable for programming in Janus. The principal advance
of the Unimate is its "analogical programming," in which the act of programming is analogous to
the purpose of the program. Another example of anological programming is the Hewlett-Packard
HP-65 pocket calculator. (The following description is paraphrased from my thesis.)
H P-65 Pocket Calculator
This was the first (and in my opinion is still the best) of the hand-held programmable
calculators. Programs are written simply by putting the calculator in "program" mode and
then pushing the desired sequence of keys, just as if one were doing the calculation. The
key-pushes are remembered on a magnetic strip. The magnetic strips can be taken out,
stored "off -line", and read back in later. Hewlett-Packard has published a library of
standard programs, and users typically make their own additions. In "run" mode the
programs can be executed or the calculator can be operated manually.
However a major defect in the design is that in "program" mode the display does not
show the current state of the calculation. Rather it shows a numerical representation for
the last key pushed (e.g. the 17th key). So programs normally have to be designed in
"run" mode, written down, and then entered in "program" mode. One cannot construct
anything but simple programs directly in "program" mode because it is too abstract.
4
Ojjicelalk "edit sequences"
Officetalk has also developed analogical programming in the context of forms fill-in. In
the ORG memo "A Forms Editor for Officetalk" (Oct. '76) Newman and Mott identified
three constraints which they felt a forms editor must satisfy:
"I. Officetalk distinguishes between those areas of a document that may be
altered by the user, and those that may not. The editor must take this distinction
into account.
"2. The user needs some way of repeating the sequence of edits involved in forms
entry and editing, in order to simplify the task of filling in the same form next
time.
"3. The user needs a 'calculator' for forms editing."
The last two are particularly relevant to Janus macros. Newman and Mott described a
scheme for capturing user actions in an "edit sequence":
"As the user edits, an edit sequence is built up in a special window. Each edit is
in the form of an 'assignment statement' indicating which field is filled in, and
which fields supply the information; edits that involve only parts of fields are not
added to the edit sequence. The next time the user performs the same task on the
same form, the previous edit sequence is retrieved. He can then either perform a
different sequence of edits. or use the old sequence. To use the old sequence, he
can either pick each edit from the displayed sequence, or use the next-edit
command (ESC key) to step through the sequence."
A typical edit sequence is:
Total +- Total + amount
Due +- Advance - Total
Signature +- input
Date +- OZ.date
Branch +- '580'
This is constructed by remembering the actions as the user does them and by generalizing
from the specific field used to the generic field it represents. Newman and Mott
developed a clever way to enter constants and run-time-needed inputs into edit sequences
(cf. the above mentioned memo). Janus user macros will incorporate something like this.
Note that their edit sequences record only actions that modify or use an entire field's
contents; intra-field edits are ignored. This is in sharp contrast to Bravo, which records
everything. My inclination is towards the Bravo interpretation.
Pygmalion "dynamic programming"
Another example of an articulate method of defining algorithms is the work in my thesis
(ahem): PYGMALION, A Computer Program to Model and Stimulate Creative Thought.
5
(Incidentally, it is now available from Birkhauser Verlag if you're interested.) In
PYGMALION I developed visual. interactive counterparts for the standard programming
concepts: conditionals. iteration. subroutines. etc. Since PYGMALION's emphasis was on
modelling existing computer science concepts, the work is not directly translatable to
Janus. (Janus is not aimed at computer scientists.) However. I think it provides an
existence proof that there are solutions to such problems as finding an analogical way to
do conditionals.
In PYGMALION. as in the systems above. there is a "remember" mode of operation. In
"remember" mode each operation. in addition to executing its internal semantics and
updating the display, adds itself to a list of instructions caJled a "code list". A code list
could be associated with an icon and re-executed on demand. Code lists contain only
generic operations, as in Officetalk; PYGMALION generalizes from the specific icon used
to the generic icon that it represented. This generalization is the core of the problem of
defining algorithms by dynamic interaction.
NLS command sequences
On a slightly different emphasis, the NLS (oN-line System) editor at SRI refined the
notion of user-editable interpretive commands. NLS commands are heavily syntax driven;
a typical command is:
MOVE (at) (to)
e.g.
MOVE WORD (at) BUG (to) BUG
where BUG represents a mouse selection. The "M" and the "W" are typed from the
keyboard, much as in Bravo, and the system expands them into the complete command
words. The command words are echoed in a feedback window at the top of the display
screen, again similar to Bravo.
Though we have explicitly rejected this modal, syntax-driven, teletype-oriented approach,
it does have an advantage which NLS exploits weI!. The user can construct (with the
editor) a statement consisting of a sequence of command strings like the MOVE command
above. NLS provides a command:
PROCESS (commands from statement at)
with which the user can execute a command sequence. Since each command in the
sequence consists of the text that the user constantly sees in the feedback window,
writing them down is easy and natural. Nearly all NLS users write command statements at
some time. In fact, people would broadcast to the whole community command statements
of which they were particularly proud or which they found particularly useful. Most
people had little difficulty in reading these sequences.
(A deficiency on which we were working when I left the NLS project is that command
statements have to be constructed statically with the editor, like any other text statement.
We were exploring techniques for recording commands as the user does them, but we had
not yet implemented it.)
6
A minor breakthrough pioneered by NLS was its way of describing a point in a document.
It developed the notion of a "link", A link is an ordered quadruple of the form:
(host, directory, file, statement>
(Formatting information could also be included in a link.) Any of the first three fields
could be omitted, in which case the defaults were: current (Arpanet) host, current (Tenex)
directory, current (NLS) file. The statement within a file could be described in several
ways: (1) as a position in the NLS tree-structured file, (2) as a number unique to the file
(there were actualIy two flavors of this), (3) as a user-specified name string, or (4) as the
statement containing a given string (associative retrieval). A typical type-l number is
"4b3", which says "the fourth top level statement in the file, then the second statement
under that, then the third statement under that." This is a dynamic description; the
4b3'th statement at execution lime would be designated.
All commands accept links as operands. For example, the and in
the MOVE command above would be links. The system automatically turns a mouse bug
into a link internally, so that links are the NLS representation for selections. I believe
that Janus may be able to use this concept, though I have not worked out the details.
Principles for Janus macros
To sum up: The above systems work, they are articulate, and they can teach us a lot about
programming machines. From their lessons I have extracted the following four principles for
Janus user macros:
Dynamic programming (remember mode)
Macro definition is based on the concept of a "remember" mode of operation. In this
mode all of the actions that one normally does on the system are available, but in
addition to executing each action, the system also records it.
Analogical programming (learning by doing, DWlD)
Macro definition proceeds by actualIy doing a task once. The user "teaches" the machine
what to do in a step-by-step demonstration. With this "Do What I Did" approach the
problem of writing a macro reduces to the problem of doing the task you want the macro
to accomplish.
Concrete programming (work with actual data)
Macro definition uses actual data. As a user guides the machine through the desired
steps, he does so on actual documents, folders, file cabinets, etc. The machine
generalizes, where appropriate, from actual to generic data.
System integration (human-readable macro representation)
Macros are displayable, printable, mailable, fileable, etc. They are displayable in an
intelligible fashion to the user, and he can edit them with the standard text editor. The
7
system also provides dynamic ways to edit and debug macros.
Design
Definition: A Janus user macro is a document containing a recorded sequence of Janus actions.
Definition: A Janus action is a selection or a command. A command may either be from the
keyboard or from a menu. The selection is taken to be the selection that exists when a command
is invoked. (Adjustments and re-selections are not recorded.)
Janus user macros are defined via the OWID approach. With one or two exceptions, all Janus
actions can be recorded.
A Janus macro document has all of the document capabilities (editable, printable, mailable,
fileable, etc.). In addition it is executable. There is a special rendering of a macro document to
indicate that it is executable (see Figure 1).
Every recorded action has a text representation; for example a MOVE command is represented by
the string "MOVE", In general the representation is the text on the key top or in the menu. The
representation for selections is yet to be determined. Each line in a macro document contains a
separate recorded action.
Implications of the design
Janus macros have exactly the same capabilities as a user doing the actions manually. The
system does not achieve any additional capabilities simply because a macro is running. In fact,
there is no difference to the system between a running macro and an (extremely fast) user doing
the actions.
There is no formal language for user macros (at least in the first release) beyond a rendering of
Janus actions. There is no static control language (conditionals, iteration), declarations, syntax,
compound expressions, etc.
Implementation
Two additional icons are introduced in order to implement this design:
RECORDER icon
This contains the functions necessary for the recording of user macros. The user's model
is based on a tape recorder metaphor. The functions and concepts involved are similar to
those existing on physical tape recorders, particularly cassette recorders.
CALCULATOR icon
Following Officetalk's lead, we introduce arithmetic into the system via a pocket
calculator metaphor. It is obvious that a user should be able to do arithmetic calculations
on a personal computer, quite apart from whether or not there are macros. Thus this is
8
introduced not solely for the sake of macros but also to remedy an omission in Janus.
The RECORDER
This is the core of the macro facility. The Recorder consists of a window and a set of commands
(see Figure 1). As in other function windows, the Recorder window can contain any number of
documents and/or folders. Like the Printer and Out Basket, the top document or folder is
processed first. All Recorder commands affect only the top entry in the window.
In the lower half of the Recorder window is the "Current Actions Area" and the "Next Action
Arrow". The Current Actions Area always displays the actions in the top macro document in the
Recorder window. (It may be empty if we are going to record a new macro.) The Next Action
Arrow always points to the next action that the macro will execute. This is the action with which
the PLAY, CONTINUE and SINGLE STEP commands begin executing.
** Note: The contents of the Current Actions Area can be scrolled, but the Next Action
Arrow remains fixed. Thus a side effect of scrolling is to bring a different action under
the Next Action Arrow. This gives the system a kind of primitive GO TO ability (perish
the thought).
Atl Recorder commands can themselves be recorded unless explicitly noted otherwise.
PLAY
To execute a user macro:
(a) select a macro document (or folder containing macro documents)
(b) MOVE or COpy it to the Recorder window
(c) execute PLAY.
PLA Y begins execution with the action pointed to by the Next Action Arrow.
Unlike the Printer, the user must explicitly invoke PLAY on each document to be
processed (because the user might want to RECORD it or SINGLE STEP it instead). Also
unlike the Printer, documents and folders are not deleted once they have been processed;
they are simply placed back on the Desktop. (The Printer should not delete them either,
just between you and me.)
When a folder is processed, the Recorder executes each document or folder in it in
sequence without requiring any user intervention. In this way a set of macros can be
packaged up and executed as a unit.
** Note: The PLAY command being recordable gives macros a subroutine capability. A
macro can select a macro document, place it in the Recorder, and execute PLAY, all as part
of its recorded actions. It can even execute PLAY on itself, producing recursion.
STOP
When RECORDing a macro, STOP ends the recording session. The session can be resumed at
any time by executing RECORD again. When PLAYing a macro, STOP aborts it. The only
9
time the user has the option of executing STOP during the running of a macro is when it
has executed a PAUSE. In either case. STOP removes the macro document from the
Recorder window and places it on the Desktop. just as if it had finished executing.
When not RECORDing or PLAYing a macro. STOP has no effect.
STOP itself cannot be recorded. since it used to take the system out of record mode.
RECORD
To record (define) a user macro:
(a) select a macro document
(b) MOVE or COpy it to the Recorder window
(c) execute RECORD.
All (recordable) actions will now be inserted into the macro sequence in the Current
Actions Area in front of the action pointed to by the Next Action Arrow. (If we are
defining a new macro. the Next Action Arrow will not point to any action.)
RECORD. like PLAY. affects only the top document in the Recorder window. (It must be a
document; it cannot be a folder.) If the macro document is non-empty. the system prints
a warning such as "macro is already defined. Do you want to modify it?" and a
YES/NO menu is displayed. If NO. the RECORD command is ignored. If YES. the system
begins recording. inserting actions before the Next Action Arrow.
** Note: Macros can be edited by SINGLE STEPping or scrolling to a given action. executing
RECORD. and adding new actions to the sequence. Actions can be deleted by selecting
them and executing DELETE, as with any other text. Actions can also be MOVEd, COPYed or
typed in by hand. but this is somewhat riskier since the user can create illegal actions that
way. The safest way to add new actions is to enter record mode and let the system add
them. The system only records legal actions.
RECORD itself cannot be recorded, as it would probably be confusing.
PAUSE
The PAUSE command temporarily suspends the running of a macro. When a PAUSE
command is recorded. the user is asked to supply a text string to use as a prompt. This
string is printed in the Message Area every time the PAUSE is subsequently executed. The
user then has the option of
- CONTINUEing it,
- STOPping it,
- SINGLE STEPping through it, or
- doing any number of Janus actions and then one of the above.
** Note: This macro design contains no conditionals. I think that conditionals require
considerably more understanding of programming than other Janus actions and that we
should defer them at least until the second release of Janus, even though this severely
limits the types of programs that can be written with this system. Eventually 1 expect
10
that we will come up with an articulate method for describing decisions, possibly like the
Pygmalion IF operator or perhaps like Richard Moore's records processing decision tables.
But I think that we should not attempt to incorporate it into the first release. As an
alternative, I suggest. we adopt the solution used in the HP-65 calculator. They also have
a PAUSE operation. When executed. the programs stops and the user looks at the state of
things and decides what to do next, either
- aborting the program,
- resuming it,
- going to a different program step, or
- doing any number of calculator operations and then one of the above.
This is a substantial simplification because the user must deal only with a concrete
situation requiring a decision instead of an abstract "every time" situation.
CONTINUE
The CONTINUE command resumes a PAUSEd macro with the action pointed to by the Next
Action Arrow. It is similar to PLAY. with one exception: if the system was in record
mode when the user executed PAUSE, the system is temporarily taken out of record mode
so that the user can do some non-recorded actions. In this case CONTINUE will put the
system baek in record mode, whereas PLAY will not
SINGLE STEP
This command permits the controlled execution, debugging and editing of macros. As
mentioned above, the Next Action Arrow always points to the next action that the macro
will perform. SINGLE STEP causes this action to be executed and the arrow advanced.
SINGLE STEP can be invoked when a macro has not yet begun running (Le. instead of
invoking PLAY) or when a macro has executed a PAUSE.
REPEAT
The REPEAT command is introduced as an amittedly clumsy attempt to get iteration into
the system. Like CONTINUE, REPEAT is similar to the PLAY command, with one exeeption:
it traps failures and resumes running with the next action following it
Every action in a macro either succeeds or fails when it is executed. It succeeds if
it works correctly; it fails if it is unable to carry out its semantics. For example,
when the last field in a form is selected, NEXT will fail because there are no more
fields to go to. The failure of any macro action automatically aborts the macro.
This characteristic of macro actions together with REPEAT give the system a kind of
iteration capability. REPEAT causes the action under the Next Action Arrow to be
executed (i.e. it does a GO TO to that action). Typically the user scrolls the Current
Actions Area until the desired action is specified. The action must be an action earlier in
the sequence, hence the name "repeat". This will cause the action sequence to loop
indefinitely, until finally an action fails. When that happens, the REPEAT action regains
control and causes the macro to proceed with the following action.
11
NEW MACRO
This is simply an optimization for creating a new macro document. When it is executed,
the system makes a copy of the System Blank Macro Document, puts it in the top of the
Recorder window, and enters record mode. It is ex.actly equivalent to the foI1owing
sequence of actions:
- select the System Blank Macro Document (wherever it is)
- COpy
- designate the top of the Recorder window
- RECORD
It is intended to make defining macros sufficiently easy to be widely used.
Comments
Comments may be added manually to a macro document by inserting comment text
enclosed in (parentheses).
12
The CALCULATOR
The Calculator consists of a window and a set of commands (see Figure 2). It not only permits
macros to contain arithmetic operations, but it also remedies the lack of arithmetic ability in
Janus.
The calculator model and functions should be very carefully designed, something I have not yet
done. The model presented here is just to give you the flavor of what I am thinking about. If
anyone has a good model for a calculator, I would appreciate hearing about it. (Sample
problems: Should there be a stack or not? Should there be registers? Memory locations? What
functions? Log functions? Trig functions? Inverse trig functions?)
In the simple-minded model here, there is a field in the Calculator window called "X" and an
internal "accumulator". All commands operate on the current selection as an operand. Unary
operations (e.g. square root) operate only on the current selection; binary operations (e.g.
addition) operate on both the accumulator and the current selection. If there is no selection
when a Calculator command is executed, the X field contents are used as the selection. After
every operation, the result is stored in both the accumulator and the X field. In addition, after
every operation the contents of the X field contents are selected so that operations can be
chained easily. Numbers can be entered from the keyboard by typing them into the X field. As
an (admittedly inconsistent) optimization, if a number is typed into the X field whi1e its contents
are selected, the typed number replaces the contents. Otherwise a DELETE would have to be done
every time you wanted to type in a number. (On the other hand, virtually all calculators work
that way.)
The Calculator can operate on extended selections, in which case it iterates performing the
operation on each number in the selection. In particular a row or column of a table can be
selected and used as the operand for a Calculator function. Entries that are not legal numbers
are skipped.
The Calculator is floating point, to some reasonable precision.
Calculator Commands
Calculator commands are postfix, as are all commands in Janus.
clear X,accumulator ~ 0
+ X,accumulator ~ accumulator + selection
X,accumulator ~ accumulator - selection
* X,accumulator ~ accumulator * selection
/ X,accumulator ~ accumulator / selection
% X,accumulator ~ accumulator * selection * 0.01
13
lis X,accumulator +- 1 I selection
s2 X,accumulator +- selection
