.NONUMBER
.LM 0
^PY^-
.PAGE SIZE 58,85
.LM 10
.RM 75
.NO FILL
.NO JUSTIFY
#
.SKIP 5
.CENTER
The RSX Multi-Tasker
.CENTER
December, 1986
.SKIP
.CENTER
^IS144^G"Illegitimus Non Carborundum Est"^IS204^G
.SKIP
.CENTER
Fine Realtime Commentary Since 1975
.SKIP 6
.CENTER
^&Table of Contents\&
.SKIP 2
.TAB STOPS 60
Food for Thought	RSX-1
The Editor's Corner	RSX-1
  Keeping the Faith	RSX-2
  Submitting Articles to the Multi-Tasker	RSX-3
  And That's The Way Things Are	RSX-3
Call for RSX Mail Working Group	RSX-4
The Bag of Tricks:  MACRO-11	RSX-5
Automatically Running Command Files at ...	RSX-6
The RSX Songbook:##Part I	RSX-11
Full-Duplex Terminal Driver Hooks for ...	RSX-12
.JUSTIFY
.FILL
.PAGE
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT The Editor's Corner
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
#
.SKIP 7
.AUTOPARAGRAPH
.CENTER
^&Food for Thought\&
.SKIP
	"... there's nothing of any importance in life - except how well
you do your work.  Nothing.  Only that.  Whatever else you are, will come
from that.  It's the only measure of human value.  All the codes of ethics
they'll try to ram down your throat are just so much paper money put out by
swindlers to fleece people of their virtues.  The code of competence is the
only system of morality that's on a gold standard."
.SKIP 2
.INDENT 30
^IS144^G- Ayn Rand^IS204^G
.INDENT 30
^IS144^G##Atlas Shrugged^IS204^G
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT The Editor's Corner
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.SKIP 9
.CENTER
^&The Editor's Corner\&
.SKIP
.CENTER
Bruce R. Mitchell
.SKIP
	First things first.  An apology by the Editor.  I ^&had\& intended to
print the results from the puzzle contest in this issue, but I ^&hadn't\&
figured in an extra month delay from mailing of the finished proofs to
publication of the final issue.  It's late October now, and responses
are just beginning to roll in well. So - the contest results will be
published in the January issue.
	The Fall 1986 Symposium was a huge success.  Many new sessions were
presented, along with repeats of old favorites.  The perennially popular
"Hamster Theory of RSX" drew a large crowd, as usual.  The SIG pirating
of the VMS Magic session will go down in history as one of our bolder moves.
And a full week of Photon#(c) wars among the SIG Steering Committee earned
us a new reputation as promoters of physical fitness.
	A new SIG coat-of-arms was unveiled at the Magic session.  We'd love
to print it here, but pity has stayed our hand.  "It's a pity that there are
blue laws", said the SIG Chair, when asked about it.
	Now, if we can just manage to keep our charter after the DECUS Executive
Board finds out about these things ...
	In this issue, we have a "Bag of Tricks" which brings forth a
feature of which even sophisticated users may be unaware.  An article on
a command file submitter program will be welcomed by RSX-11M users, on whose
systems there is no batch queue.  To round out the issue, there are notes
from the Symposium session on ACDs.  And the song.  Yes, the song is here.
	In future issues we'll be bringing forth more articles generated by
the Fall Symposium, particularly the Q/A sessions and those which are
relevant to the future of RSX.
	Again, the editor thanks each and every respondent to the continuing
call for more articles.  Keep them coming; I've got a little something for all
submittors.  Sometimes it may even be useful. And - oh yes, if you don't want to
^&write\& an article, at least drop a line telling what kind of articles
you'd like to ^&see\& in the Multi-Tasker.
	And now, ladies and gentlemen, here's something upon which you may well
ruminate - or fulminate - as you cut purchase orders for new equipment.
.TEST PAGE 5
.SKIP 2
.CENTER
----- Keeping the Faith -----
	Once upon a time, there was a small computer company called Digital
Equipment Corporation.  They built their business in a market that no company
had addressed until they came along.  The market they addressed was that of
small laboratory, scientific and industrial users.
	Time went on and Digital introduced the PDP-8.  They built
external interfaces for PDP-8s, for a wide variety of devices.
They supported more than one operating system for the PDP-8, each specialized
for its application.  The PDP-8 addressed the needs of their original market
even better than before.  The users had faith that Digital would
continue to address their needs.  And Digital took that faith for granted,
and continued to supply their desires.
	More time slipped by.  Digital introduced the PDP-11.  Again, they
built external interfaces for PDP-11s, for a wide variety of
devices.  Again, they supported more than one operating system for the PDP-11,
each specialized for its application.  The PDP-11 addressed the needs of
their original market even better than before.  The users had faith
that Digital would continue to address their needs.  And Digital took that
faith for granted, and continued to supply their desires.
	Yet more time passed.  Digital introduced a new computer.  The highly
respected and well known "Programmable Data Processor" mark was not good enough
for this new processor.  It was called a VAX instead.  Digital built external
interfaces for VAXes - for tape, disk and terminals.  They supported one
operating system for VAXes.  VAXes completely ignored the needs of their
original market.
	Unsurprisingly, some of those users felt that Digital had broken
faith with them.  The answer from Digital was that they could buy VAXes
or take a hike.
	It's notable that many of those original users are into physical
fitness, and are now doing just that - hiking.  Motorola Park and the Intel
National Monument are currently popular hiking areas.
.TEST PAGE 5
.SKIP 2
.CENTER
----- Submitting Articles to the Multi-Tasker -----
	Please submit machine readable media when possible.
RX01, RX02, RX50, or 9 channel magtape at 800 or 1600 BPI are best.
Any format is acceptable except ROLLIN, PRESRV or VMS backup.  ANSI, BRU and DOS
FLX formats are well-liked by the Editor's tape drive.
	Submissions which aren't machine readable take longer to get into
print.  The editor is lazy and types mass quantities only once a month when
progress reports are due.
	If you preformat a submission in RUNOFF format, please set
left margin 10, right margin 75, and when changing margins use
incremental changes rather than absolute.  The editor blesses you for
the consideration.
	Send all submissions to:
.SKIP
.NO FILL
.NO JUSTIFY
Bruce R. Mitchell
Machine Intelligence and Industrial Magic
PO Box 816
Byron, MN   55920
.JUSTIFY
.FILL
.TEST PAGE 5
.SKIP 2
.CENTER
----- And That's The Way Things Are -----
	_... this month in Pool Lowbegone, where
the need for real-time is strong, the simplicity of RSX-11M V3.2 is
good-looking, and the system uptime is above average.
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT Call for RSX Mail Working Group
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 7
.CENTER
^&Call for RSX Mail Working Group\&
.SKIP
.CENTER
Bruce R. Mitchell
.CENTER
Machine Intelligence and Industrial Magic
.CENTER
PO Box 816
.CENTER
Byron, MN###55920
.SKIP
	Readers of this article may remember that Digital's RSX and DECnet
implementation groups put two VMS / DECnet compatible mail systems on the Fall
SIG tape five years back.  They still work fine, by the way.
	However - The source supplied with those packages is of the "midnight
hack" flavor.  Documentation is sparse, and some of the source is in
Basic-Plus-2.  While the task images supplied with the packages still run,
someday those task images will stop running.
	Before that happens, it is hoped that enough users can get together to
form an RSX Mail Working group.  This group will have, as objective, the
following items:
.LIST
.LE
Recode the RSX Mail system in a supportable language/s.
.LE
Document the RSX Mail system.
.LE
Specify and possibly add desired features such as store-and-forward.
.LE
Check the result against VMS Mail and DECmail.
.LE
Put the result on an RSX SIG tape for general use.
.END LIST
	Interested users with Macro and DECnet experience, and at least 8
hours per month to spend on this project, should contact me at the address
above.  Final organization and recognition of this group will depend on the
level of interest shown.  We'll need at least five people with significant
interest to make it fly.
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT The Bag of Tricks
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 7
.CENTER
^&The Bag of Tricks:  MACRO-11\&
.SKIP
.CENTER
Barton F. Bruce
.CENTER
Cambridge Computer Associates
.CENTER
222 Alewife Brook Pkwy
.CENTER
Cambridge, MA###02138
.SKIP
	^IS144^GThis is one of the better magic tricks I've seen in
many moons.  My compliments to the author. #--- The Editor^IS204^G
.SKIP
	In this month's article we examine a code segment useful to
almost every programmer who codes for production systems.
	When a task is finally debugged to the point where it can be released
for production use, it is often necessary to replace a previous production
version of the task.  Keeping track of various copies of task images - some
current, some not - can become a major headache for system managers.
	There are two common solutions to this problem.  The first is to keep
track of task versions by file creation date.  This would be OK, were it not
for a teeny little problem which causes PIP's default to be ^&no\& preservation
of file creation date.  Thus, an old task moved with PIP can appear to be a new
version of the task.  The same problem occurs with task file version numbers.
	Another solution is to use the Macro .IDENT directive, or the
Taskbuilder IDENT option.  This is a good solution, as long as the programmer
remembers to update the IDENT ^&every\& time the source is changed.
	This subroutine code, called from a Fortran mainline, solves these
problems neatly.  The Taskbuilder has the ability to create a reserved
_.PSECT with the name $$DBTS (slightly documented in Appendix E of the
Taskbuilder manual.) This .PSECT, normally used by debuggers, contains the
task true creation date and time.
	This subroutine extracts this information and converts it to printable
ASCII form, then returns to the caller.  Ideally, this should be done when a
task starts, and the task should print a logging message containing the task
creation date on the system console, CO: .
	This neatly solves, in one sweep, all
problems associated with keeping track of which task is current.
One needs only to run the task and ^&see\& which is current.
.SKIP 3
.NO FILL
.NO JUSTIFY
;       TBUILT gets the task's build date and time, converts them
;       to ASCII, and returns them in a passed buffer.  As it is
;       written, it should be called with a buffer of at least 16
;       bytes.  If called as a function, string length is also
;       returned.
;
;       Calling sequence:  LEN = TBUILT (TIMBUF)
;                     or:  Call TBUILT (TIMBUF)
;
;       Inputs:  $DBTS - TKB-supplied date and time buffer
;                2(R5) - Address of output buffer
;
;       Outputs:  @2(R5) - ASCIZ date and time string
;                 R0 - Length of ASCII portion of output string
;
;       Register dispositions:  R0, R1, R2 destroyed


TBUILT::MOV     2(R5), R0      ; Load return buffer address in R0
        MOV     _#$DBTS, R1     ; Point at task's time/date field
        CALL    $DAT           ; Convert date to ASCII
        MOVB    _#40, (R0)+     ; Separate date/time with a blank
        MOV     _#2, R2         ; Convert in format HH:MM
        CALL    $TIM           ; Convert time to ASCII
        CLRB    (R0)           ; Append null for .ASCIZ format
        SUB     2(R5), R0      ; Compute length (excluding null)

        RETURN                 ; And return to the caller


;
;       TKB extends PSECT $$DBTS, filling with date/time of build
;

        _.PSECT  $$DBTS, D, RW, LCL

$DBTS::                        ; Storage area for TKB time/date
.FILL
.JUSTIFY
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT Automatically Running Command Files at Any Future Time
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 7
.CENTER
^&Automatically Running Command Files at Any Future Time\&
.SKIP
.CENTER
Judah Levine
.CENTER
Joint Insitute for Laboratory Astrophysics
.CENTER
National Bureau of Standards / University of Colorado
.CENTER
Boulder, Colorado###80309
.SKIP 2
.RM -5
.LM +5
.CENTER
NOTE
.SKIP
This material is based on our operating experience using RSX-11M, and
is necessarily specific to that software.  It should not be taken to
imply endorsement by the National Bureau of Standards.
.RM +5
.LM -5
.SKIP
	It is often useful to run indirect command files
late at night or on a certain day each month.  As distributed, INDirect
does not provide an easy way to do this.  This note describes a task that
can submit an indirect command file at any time
in the future.
	We use this task to perform certain operations at 01:00:00
on the first day of every month, but the principle may be easily adapted
to other situations.  The task is named RUNIND, and the FORTRAN text is
shown below.
	RUNIND is controlled by a command file - DR1:[5,1]INDTXT.DAT.  A
sample command file is shown below.  The first line specifies the date
as three integers specifying month, day and year on which the operation is
to be performed.  The second line contains the full name of the file to be
submitted to INDirect.
	The task is automatically started by the Exec every day at
01:00:00.  The task reads the first line of the command file and compares
the requested date with the system date.  If the dates do not match, then
nothing happens.  The task exits and is automatically re-scheduled by the
executive at the same time on the next day.  If the dates match, the
second line is read, formatted and submitted to INDirect.
The file may contain any of the usual commands recognized
by the indirect command file processor.
	There are two unusual aspects of the procedure.  The first is the
requirement to log in before the file can
be processed.  Because RUNIND is started automatically by the Exec,
its issuing terminal is taken to be pseudodevice CO:, which is usually
physical device TT0: (See the MCR Operations Manual, p. 3 - 158).  If
the command file is simply submitted to MCR directly, the operation
fails with the diagnostic, "Not Logged In," as (hopefully) nobody is logged in 
on the terminal.  Therefore, the task spawns HELLO to log it in.
	The login sequence uses account XXXXXX with password
YYYYY.  For simplicity, user XXXXXX should be privileged.  When the operation
completes, BYE is spawned to perform the logout sequence.  This also
assumes that nobody is logged on device CO: when RUNIND is activated.
This is not important in our situation, but it is a limitation.
	The second important point is that all files referenced in
RUNIND, and in any of the files that it invokes, must be specified using
their full name including physical device and UIC.  This is because the 
default UIC and device for the indirect command processor are taken from
values associated with user XXXXXX, and it is not desirable to
have a process fail to find the correct file if user XXXXXX changes
his default device or directory.
	The task is compiled and built using the following commands:
.skip 1
F77 RUNIND=RUNIND
.BREAK
TKB RUNIND/-CP/PR:0=RUNIND
	The task is built privileged, but is not mapped to the 
executive.  The task is then installed and initiated from a privileged
terminal:
.skip 1
INS RUNIND
.BREAK
RUN RUNIND 01:00:00 /RSI=24H
	In our version, the task is activated only once per day at a given
time.  This may be changed as necessary.  As the actual operation may
be many days in the future, it is possible that the system may crash
before the requested day arrives.  To ensure that RUNIND is installed and
restarted following a restart, commands to install and run
the task should be added to the system startup file.
.SKIP 2
.NO FILL
.NO JUSTIFY
      Program RUNIND
C
C     This program runs an INDirect command file at some time in
C     the future.  As written, it submits the file at 01:00:00 on
C     the given day, but that may be easily modified.
C
C     The program is driven by file DR1:[5,1]INDTXT.DAT.  Line 1
C     of the file contains three integers giving month,day and
C     year to run the file.  Line 2 gives the full name of the
C     file.  When the given date arrives, the file is sent to
C     ...AT. via a spawn of MCR.
C
C      Written by Judah Levine, JILA
C
<FF>
C
C     Data begins
C
      Integer*2 M, D, Y, MO, DY, YR, MCR (2)
      Byte NAME (80), HEL (20), BYE (10)
C
      Data MCR /3RMCR,3R.../
<FF>
C
C     Code begins
C
C     Get current date
C
      Call IDATE (MO, DY, YR)
C
C      Open driver file.
C
      Open (Unit=1, Name='DR1:[5,1]INDTXT.DAT', Type='OLD',
    + Access='SEQUENTIAL', Form='FORMATTED', Readonly,
    + Carriagecontrol='LIST', Dispose='SAVE')
C
C     Read effective date from driver file.  The file may be
C     prepared using any text editor.  A sample file entry would
C     look like:
C
C     2,1,86
C     DL2:[5,2]CHGSTR.CMD
C
C     where line 1 is the date (1-Feb-86), and line 2 is the AT.
C     command line to be spawned.
C
  10  Read (1, *, End=999) M, D, Y
C
C     If date read matches current date, then read file name
C
      If ((M .EQ. MO) .AND. (D .EQ. DY) .AND. (Y .EQ. YR)) Then
        Read (1, 2) IL, (NAME(I),I=1,IL)
    2   Format (Q, 80A1)
C
C       Shift filename right one place, terminate with a null,
C       and add the @ symbol in the first position.  This builds
C       the command line to be spawned to MCR.
C
        Do 3 I = 1, IL
          NAME(IL-I+2) = NAME(IL-I+1)
    3   Continue
        NAME(IL+2) = 0
        NAME(1) = '@'
C
C       Since this task runs in real time, its TI: is TT0:.  If
C       the command line were simply sent to MCR, it would not
C       be processed as it appears to come from a terminal on
C       which no one is logged in.  Therefore, we must first
C       log in to TT0:
C
C       Build log-in command line.  XXXXXX is username, YYYY is
C       password.  To simplify matters, XXXXXX should be priv.
C
        Encode (15, 33, HEL)
   33   Format ('HEL XXXXXX/YYYY')
        HEL(16) = 0
C
C       Spawn MCR with log-in command line
C
        Call SPAWN (MCR, 5, 1, 6,,,, HEL, 16,,, IDS)
C
C       Wait for MCR to finish, wait 10 sec more and go!
C
        Call WFLOR (6)
        Call WAIT (10, 2)
C
C       Now spawn indirect command processor by sending command
C       @<filename> to MCR.
C
        Call SPAWN (MCR, 5, 1, 6,,,, NAME, IL+1,,, IDS)
        If (IDS .NE. 1) Type *, 'RUNIND spawn rejected'
C
C       Wait for INDirect to finish the file
C
        Call WFLOR (6)
        Call WAIT (10, 2)
        Type *, 'RUNIND completed'
C
C       Now log out.  Prepare command line and send it to MCR.
C       Note the BYE must have a blank after it.
C
        Encode (4, 34, BYE)
   34   Format ('BYE ')
        BYE(5) = 0
        Call SPAWN (MCR, 5, 1, 6,,,, BYE, 4,,, IDS)
C
C       Wait for BYE to finish.  Since RUNIND is priv, BYE is not
C       able to abort it. Then go read again for more lines.
C
        Call WFLOR (6)
        Call WAIT (10, 2)
      End If
      Goto 10
C
C     End of file detected.  Clean up and exit to RSX.
C
 999  Close (Unit=1, Dispose='SAVE')
      Call EXIT
      End
.JUSTIFY
.FILL
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT The RSX Songbook:  Part I
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 7
.CENTER
^&The RSX Songbook:  Part I\&
.SKIP 2
	^IS144^GAs sung at the RSX Magic Session, the VMS Magic
Session, by popular request, and that's all I'm going to say
about it. #--- The Editor^IS204^G
.SKIP 2
.NO FILL
.NO JUSTIFY
^&The RSX VMS Lovers Song\&
("Wow, there's lots of stuff on that VAX")
To the tune of:  "He's Got the Whole World in His Hands"
.SKIP 2
He's got lotsa crud, on his VAX,
He's got lotsa crud, on his VAX,
He's got lotsa crud, on his VAX,
He's got lotsa crud on his VAX.
#
He's got DEC star couplers, on his VAX,
He's got Britton Lee, on his VAX,
He's got full DECservice, on his VAX,
He's got expensive crud on his VAX.
#
He's got real-time, on his VAX,
He's got Datatrieve, on his VAX,
He's got VMS, on his VAX,
He's got slow crud on his VAX.
#
He's got office automation, on his VAX,
He's got All-in-Zero, on his VAX,
He's got security up the ying-yang, on his VAX,
He's got management on his VAX.
#
He's got VAX/ELAN, on his VAX,
He's got ANSI DIBOL, on his VAX,
He's got RPG, on his VAX,
He's got useless crud on his VAX.
#
He's got gigundo disks, on his VAX,
He's got max warp speed, on his VAX,
He's got unlimited POOL, on his VAX,
He's got some decent stuff on his VAX.
#
He's got BLISS-16, on his VAX,
He's got TOPS-20 emulation, on his VAX,
He's got Fidonet, on his VAX,
He's got bizarre crud on his VAX.
#
He's got 1000 users, on his VAX,
He's got 40 LAT servers, on his VAX,
He's got the King James Bible, on his VAX,
He's got the whole world on his VAX.
#
He's got lotsa crud, on his VAX,
He's got lotsa crud, on his VAX,
He's got lotsa crud, on his VAX,
He's got lotsa crud on his VAX!
.JUSTIFY
.FILL
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT Full-Duplex Terminal Driver Hooks for ACD Processing
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 7
.CENTER
^&Full-Duplex Terminal Driver Hooks for ACD Processing\&
.SKIP
.CENTER
Dale R. Donchin
.CENTER
Digital Equipment Corporation
.SKIP 2
.NOTE
This document is supplied as informational material only.  It is not guaranteed
to be accurate and is subject to change.  The ACD interface and user-written
ACDs are not supported by Digital.
.END NOTE
.SKIP
	The list below details the hook points within the full-duplex
terminal driver for ACD processing.  (See ACD loader source file [12,10]ACD.MAC
for further information.)#
	For each hook point, there is a unique entry in
the ACD dispatch table.  The bits in UCB offset U.AFLG describe the action which
should occur when the ACD returns control to the driver.  The default action is
set by the driver before calling the ACD.  In this way, the ACD can execute
a simple RETURN if it does not want to alter the normal processing which would
occur at that particular point in the driver had the ACD not been present.
Alternatively, the ACD can manipulate those bits to obtain the desired action.
	Each hook point described below lists the bits which pertain to it,
including the default setting.
	Note:  In ^&all\& cases, the ACD is passed
a pointer to UCB offset U.TSTA via R5.  This is how the ACD knows the terminal
for which the processing is being done.
	Further note:  All registers except R0 must be preserved.  APR6 mapping
must also be preserved.
	It is important to note that ACB symbol A.RES defines the start of ACD
specific offsets.  These offsets can be used to contain any information the
ACD needs to keep on a per-line basis.  It is assumed that the prototype ACB
has been created with A.FLEN at least equal to the size of a full ACD (32
octal bytes).  Any additional offsets needed should be added to A.FLEN.  As an
example, if the ACD needs 2 additional word offsets, the prototype ACB should
be created with A.FLEN = 32 +4 = 36 octal bytes.
.HL 1 I/O Request Acceptance
	Entered when a task has issued an I/O request.  The context of the
task is still available for validation of buffer parameters.  At this point,
the ACD can change the I/O function, such as changing a read to a
read-after-prompt.  In this case, the prompt buffer address and length are
passed in A.SMAP, A.SBUF and S.SLEN.
	This entry point is called only if the appropriate bit in A.MAS or
A.MAS+2 is set for the function code specified by the request.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R1 - Function code * 2
########R3 - Address of I/O packet
#
Output:  UA.ALL - Set if request should be accpeted.
##################Clear if request should be rejected, returning
###################error code passed in first word of A.IOS.
#
Default:  UA.ALL
.JUSTIFY
.FILL
.HL 1 I/O Request Dequeue
	Entered when a previously received I/O request is extracted from the
queue and is about to be processed.  The context of the task which issued
the request is not necessarily available.
	This entry point is called only if the appropriate bit in A.MAS or
A.MAS+2 is set for the function code specified by the request.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R1 - Function code * 2
########R3 - Address of I/O packet
#
Output:  UA.ALL - Set if request should be accpeted.
##################Clear if request should be rejected, returning
###################error code passed in first word of A.IOS.
#
Default:  UA.ALL
.JUSTIFY
.FILL
.HL 1 Powerfail
	Entered when power is restored after a powerfail has occurred.
.HL 1 Input request completion
	Entered when an input request terminates, successfully or otherwise.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R3 - Address of I/O packet
########A.IOS - Reason for completion
#
Output:  UA.TRA - Set if characters transfer from ACD buffer to
###################task buffer per A.SMAP, A.SBUF and A.SLEN.
##################Clear if characters transfer from TT: driver
###################buffer to task buffer.
########A.IOS - Reason for completion.  Can be changed by ACD.
.JUSTIFY
.FILL
.HL 1 Output request completion
	Entered when an output request terminates, successfully or otherwise.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R3 - Address of I/O packet
########A.IOS - Reason for completion
#
Output:  A.IOS - Reason for completion.  Can be changed by ACD.
.JUSTIFY
.FILL
.HL 1 Connection
	Entered when a terminal is set to this ACD.  Any initialization and
memory allocation necessary for this link can be done at this point.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R0 - Address of ACB
########A.IOS - Low byte of first word is zero
#
Output:  A.IOS - First word low byte nonzero to refuse connect.
##################Nonzero value returned to task requesting the
##################connect as the error status.
.JUSTIFY
.FILL
.HL 1 Disconnection
	Entered when a terminal is unlinked from this ACD.  Any clean-up
required for this link should be done at this point.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R0 - Address of ACB
.JUSTIFY
.FILL
.HL 1 Input Character Reception
	Entered when an input character is received.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R2 - Character received
#
Output:  R2 - Character received.  Can be changed by ACD.
#########UA.ACC - Set if character is to be accepted.
##################Clear if character is to be flushed.
#########UA.PRO - Set to enable normal processing of character.
##################Clear to enable read-pass-all for character.
#########UA.ECH - Set to enable character eacho when processed.
#########UA.TYP - Set to force character into typeahead buffer.
#
Default:  UA.ACC, UA.PRO, UA.ECH
.JUSTIFY
.FILL
.HL 1 Input Character Processing
	Entered when an input character is processed.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R2 - Character to process
#
Output:  R2 - Character to process.  Can be changed by ACD.
#########UA.ECH - Set if echo should occur.
#########UA.SPE - Set if special ACD supplied echo to be output.
###################Echo buffer passed via A.IMAP, A.IBUF, A.ILEN.
#########UA.PUT - Set if character to be put into input buffer.
#########UA.COM - Set if input request should be completed.  If
###################set, reason for completion must be in A.IOS.
###################ACD will be reentered at completion point.
#########UA.CAL - Set if ACD needs to be called back at interrupt
###################level point after echo completes to deallocate
###################buffers and/or begin another echo string.
#
Default:  UA.ECH, UA.PUT
.JUSTIFY
.FILL
.HL 1 Interrupt Level Callback
	Entered when the ACD has specified, by setting the UA.CAL bit,
that it needs to be caled back after input character echo is complete.
An example might be to initiate more echo from another buffer.
	This entry point is called after the previous echo completes.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R2 - Character being echoed
#
Output:  R2 - Character to process.  Can be changed by ACD.
#########UA.CAL - Set if ACD should be called back again at this
###################point after echo completes to deallocate
###################buffers and/or begin another echo string.
.JUSTIFY
.FILL
.HL 1 Output Translation
	Entered during output I/O request processing just before the
characters from the task's buffer are copied to terminal driver buffers.
This gives the ACD the opportunity to determine what characters will be
output.
.NO FILL
.NO JUSTIFY
.SKIP
Input:  R3 - I/O packet address
#
Output:  UA.TRN - Set if ACD wants to translate output stream.
###################A.SMAP, A.SLEN must point to buffer of chars
###################to be output.  ACD is called back here after
###################the buffer is copied.
##################Clear if the task's buffer is to be output.
.JUSTIFY
.FILL
.HL 1 System State Callback
	Entered when the ACD has indicated, by setting the UA.TRA bit, that
it needs to be called back after the previous buffer has been transferred
to the task during input I/O completion.
	This entry point is called after the previous transfer completes.
The ACD can use this entry point to know when to deallocated its buffer
and/or to transfer more characters from another buffer.
.NO FILL
.NO JUSTIFY
.SKIP
Output:  UA.CAL - Set if ACD needs to be called back at this
###################point after ACD buffer described by A.SMAP,
###################A.SBUF, A.SLEN is appended to task buffer.
.JUSTIFY
.FILL
.SKIP 2
	There are certain restrictions on ACDs, as noted below.
.LIST
.LE
If an ACD wishes to transfer input characters from its own buffers to
a task's read buffer, it must not set UA.PUT during input character
processing.  Instead, it must buffer the characters itself, set the UA.COM
flag when the read is complete, and set UA.TRA at the input completion
entry point.
.LE
All buffer transfers must be of nonzero length, and not exceed 4K words.
.LE
The ACD is responsible for not transferring more characters to the task
than the task has requested.
.LE
For the moment, ACDs cannot use the UA.TRA mechanism to transfer characters
which are part of an unsolicited input request.
.END LIST
	The format of an ACB and a list of ACB offsets follow.
.PAGE
.CENTER
Format of the Ancillary Control Block (ACB)
.SKIP 2
.CENTER
Prototype ACB (linked off $ACDHD listhead)
.SKIP
.NO FILL
.NO JUSTIFY
         +------------------------------+
A.REL    |       Relocation bias        |          0
         +------------------------------+
A.DIS    |    Dispatch table address    |          2
         +------------------------------+
A.MAS    |   Function mask doubleword   |          4
         +---                        ---+
A.MAS+2  |         second word          |          6
         +------------------------------+
A.NUM    |   ID number   |  ACB length  |  A.FLEN  10/11
         +------------------------------+
A.LIN    |          Link word           |          12
         +------------------------------+
A.ACC    | Access count  | Status byte  |  A.STA   14/15
         +------------------------------+
.JUSTIFY
.FILL
.SKIP 2
.CENTER
Full ACB (linked off U.ACB)
.SKIP
.NO FILL
.NO JUSTIFY
         +------------------------------+
A.REL    |       Relocation bias        |          0
         +------------------------------+
A.DIS    |    Dispatch table address    |          2
         +------------------------------+
A.MAS    |   Function mask doubleword   |          4
         +---                        ---+
A.MAS+2  |         second word          |          6
         +------------------------------+
A.NUM    |   ID number   |  ACB length  |  A.FLEN  10/11
         +------------------------------+
A.IMAP   |  Interrupt buffer APR bias   |          12
         +------------------------------+
A.IBUF   |   Interrupt buffer address   |          14
         +------------------------------+
A.ILEN   |   Interrupt buffer length    |          16
         +------------------------------+
A.SMAP   | System state buffer APR bias !          20
         +------------------------------+
A.SBUF   | System state buffer address  |          22
         +------------------------------+
A.SLEN   |  System state buffer length  |          24
         +------------------------------+
A.IOS    |    I/O status doubleword     |          26
         +---                        ---+
A.IOS+2  |         second word          |          30
         +------------------------------+
A.RES    | Reserved for use by the ACD  |          32
         v                              v
.JUSTIFY
.FILL
.PAGE
.CENTER
ACD Offset Definitions
.CENTER
Extracted from PKTDF$
.SKIP 2
.NO FILL
.NO JUSTIFY
;
;       Define ACB offsets to locations
;

A.REL:  .BLKW 1             ; ACD relocation bias
A.DIS:  .BLKW 1             ; ACD dispatch table pointer
A.MAS:  .BLKW 2             ; ACD function mask words
A.NUM:  .BLKB 1             ; ACD identification number
A.FLEN: .BLKB 1             ; Length of ACD in bytes
A.LIN:  .BLKW 1             ; ACD link word
A.ACC:  .BLKB 1             ; ACD access count
A.STA:  .BLKB 1             ; ACD status byte
A.PLEN = .                  ; Prototype ACB length in bytes
_. = A.LIN                   ; Full ACB overlays prototype ACB
A.IMAP: .BLKW 1             ; Interrupt buffer relocation bias
A.IBUF: .BLKW 1             ; Interrupt buffer address
A.ILEN: .BLKW 1             ; Interrupt buffer length
A.SMAP: .BLKW 1             ; System state buffer relocation bias
A.SBUF: .BLKW 1             ; System state buffer address
A.SLEN: .BLKW 1             ; System state buffer length
A.IOS:  .BLKW 2             ; ACD I/O status
A.RES:  .BLKW 2             ; Start of ACD private section of ACB

;
;       Define the flag values in the offset U.AFLG
;

UA.ACC =     1              ; Accept this character
UA.PRO =     2              ; Process this character
UA.ECH =     4              ; Echo this character
UA.TYP =    10              ; Force this character into typeahead
UA.SPE =    20              ; Character has a special echo
UA.PUT =    40              ; Put character into the input buffer
UA.CAL =   100              ; Call ACD back after the transfer
UA.COM =   200              ; Complete the input request
UA.ALL =   400              ; Allow processing of this request
UA.TRN =  1000              ; Translate characters from output
UA.TRA =  2000              ; Transfer chars when I/O completes

;
;       Define ACD entry points (offsets into dispatch table)
;

_. = 0
A.ACCE: .BLKW 1             ; I/O request acceptance
A.DEQU: .BLKW 1             ; I/O request dequeue
A.POWE: .BLKW 1             ; Power failure
A.INPU: .BLKW 1             ; Input completion
A.OUTP: .BLKW 1             ; Output completion
A.CONN: .BLKW 1             ; Connection
A.DISC: .BLKW 1             ; Disconnection
A.RECE: .BLKW 1             ; Input character reception
A.PROC: .BLKW 1             ; Input character processing
A.TRAN: .BLKW 1             ; Output character translation
A.CALL: .BLKW 1             ; Call ACD back after transfer

;
;       Define status bits in A.STA of the prototype ACB
;

AS.DLT =     1              ; ACD is marked for delete
AS.DIS =     2              ; ACD is disabled
.JUSTIFY
.FILL