Trailing-Edge
-
PDP-10 Archives
-
BB-H138E-BM
-
6-1-documentation/tops20.doc
There are 37 other files named tops20.doc in the archive. Click here to see a list.
TOPS-20 Doc File
05 Sep 85
Version 6.1(7030)
COPYRIGHT (C) DIGITAL EQUIPMENT CORPORATION 1976, 1985. ALL RIGHTS
RESERVED.
THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE
INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER
COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY
TRANSFERRED.
THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT
CORPORATION.
DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
TOPS-20 Doc File, V6.1 (7030) Page 2
05 Sep 85
CONTENTS
of the
TOPS-20 Doc File, V6.1
1.0 Function of this Document . . . . . . . . . . . . . 3
2.0 Critical Cautions and Corrections (Read these
carefully) . . . . . . . . . . . . . . . . . . . . . 3
2.1 LINK V6 Required . . . . . . . . . . . . . . . . . 3
2.2 New DLUSER . . . . . . . . . . . . . . . . . . . . 3
2.3 RP20 Disks . . . . . . . . . . . . . . . . . . . . 3
2.3.1 Serial Numbers . . . . . . . . . . . . . . . . . 3
2.3.2 DX20 Microcode . . . . . . . . . . . . . . . . . 3
2.4 Common File System . . . . . . . . . . . . . . . . 4
2.4.1 MASSBUS Disk - both ports to same KL . . . . . . 4
2.4.2 CI Disk Configurations . . . . . . . . . . . . . 4
2.4.3 PS: Structure Name and CFS . . . . . . . . . . . 4
2.4.4 Breaking Away from the Cluster . . . . . . . . . 4
2.4.5 %Drive forced offline because a running system
hasn't joined cluster . . . . . . . . . . . . . 5
2.4.6 MSCP Server . . . . . . . . . . . . . . . . . . 5
2.5 Non-Wheel Access to Bootable Packs . . . . . . . . 6
2.6 Running V5.1 on a machine with a CI20 or NIA20
Installed . . . . . . . . . . . . . . . . . . . . 6
2.7 DIL and EDT20 in Separate Directories . . . . . . 6
2.8 Patches to BASIC . . . . . . . . . . . . . . . . . 6
3.0 Less Critical Problems . . . . . . . . . . . . . . . 7
3.1 Bundled software . . . . . . . . . . . . . . . . . 8
3.2 New Microcode and One Word Global Byte Pointers . 8
3.3 Password Encryption . . . . . . . . . . . . . . . 8
3.4 Job Numbers . . . . . . . . . . . . . . . . . . . 8
3.5 Swapping Space . . . . . . . . . . . . . . . . . . 9
3.6 New RSX20F . . . . . . . . . . . . . . . . . . . . 9
3.7 New SYSDPY . . . . . . . . . . . . . . . . . . . . 9
3.8 MASSBUS Device Designations . . . . . . . . . . . 9
3.9 Reconstruction of Index-Table during Startup . . 10
3.10 PDVOP% JSYS call on .PONAM function code may
fail. . . . . . . . . . . . . . . . . . . . . . 10
3.11 Alternate Password Validation Algorithms . . . . 10
3.12 MMAILR and the use of POBOX: . . . . . . . . . . 11
3.13 MAILER . . . . . . . . . . . . . . . . . . . . . 12
4.0 DUMPER Beware File . . . . . . . . . . . . . . . . 12
5.0 Beware Entries for the EXEC . . . . . . . . . . . 12
6.0 Beware Entries for GALAXY V5. . . . . . . . . . . 13
6.1 Dismounting Disks under CFS . . . . . . . . . . 13
6.2 MOUNTR.CMD No Longer Used . . . . . . . . . . . 13
6.3 DEVICE-STATUS.BIN now on PS:[SYSTEM] . . . . . . 13
6.4 Two Structures of the Same Name . . . . . . . . 14
6.5 DECnet Node Online/Offline Messages . . . . . . 14
6.6 MOUNTR Compatibility with V5.1 . . . . . . . . . 14
6.7 GALAXY Components have System Priority . . . . . 15
7.0 Beware Entries for DECnet support . . . . . . . . 15
8.0 Beware Entries for TCP/IP support . . . . . . . . 15
TOPS-20 Doc File, V6.1 (7030) Page 3
05 Sep 85
9.0 Directory of front-end file system . . . . . . . . 15
TOPS-20 Doc File, V6.1 (7030) Page 4
Product Summary 05 Sep 85
1.0 Product Summary
TOPS-20 V6.1 includes all the facilities of TOPS-20 V6.0 plus support
for the NIA20 Ethernet port, DECnet Phase IV via NI, CI and DN20,
TCP/IP via NI, CI and AN20, LAT terminal concentrators, CTERM remote
command terminals and Common File System for two DECSYSTEM-20s.
TOPS-20 V6.0 was an interim release providing the software required to
use HSC50 controllers and RA81/RA60 disks by providing support for the
KL 2060/2065 interface to the CI (the CI20) and the software
interfaces to the new disk subsystem.
TOPS-20 V6.0 and V6.1 are products only on the KL10 based 2060/2065
systems. TOPS-20 V6.1 includes updates from TOPS-20 V6.0 and from
Autopatch tape 11.
There is a major update to the TOPS-20 documentation set along with
this release.
TOPS-20 Doc File, V6.1 (7030) Page 5
Product Summary 05 Sep 85
1.1 TOPS-20 V6.1 System Facilities Specification
The following list outlines the major points of support in V6.1
introduced since V5.1, as well as certain restrictions.
1. TOPS-20 V6.1, the CI20 and the NIA20 require a KL10 Model B
Processor.
2. TOPS-20 V6.1, the CI20 and the NIA20 are not be supported on
KL10 Model A or KS10 processors.
3. There can be a maximum of one CI20 and one NIA20 installed in
a KL10 processor and the CI must be a dual path CI.
4. TOPS-20 V6.1, the CI20, and the NIA20 work with legal
combinations of internal (MF20, MG20, or MB20) memory.
5. The CI20 and NIA20 are not supported on external memory if
the system uses SA10s, DX10s or if the external memory is
other than MH10 or MF10, configured in 4-Bus mode.
6. The CI20 and NIA20 are not be supported on a system without
cache (2040s).
7. TOPS-20 V6.1 always contains the code for the CI and NI
support whether or not the system has a CI20 or an NIA20.
8. TOPS-20 V6.1 requires a MINIMUM of 768K words of memory, one
megaword for CFS configurations.
9. TOPS-20 V6.1 supports a MAXIMUM memory configuration of 4
megawords.
10. TOPS-20 V6.1 supports RA81 and RA60 disks on the HSC50, but
does not support TA78 or other HSC-based tape drives.
11. TOPS-20 V6.1 does not support the use of an HSC50 disk as a
PS: structure.
12. At system start up the program PS:[SYSTEM]IPALOD.EXE will be
run by job 0 to cause the CI20 microcode to be loaded.
During normal operation, the monitor will automatically
reload the CI20 microcode if required.
13. The NIA20 microcode will initially be loaded at system start
up by a program called SYSTEM:KNILDR.EXE, running under
SYSJOB. During normal operation, this program will
automatically reload the NIA20 microcode if required. KNILDR
can also be run manually by a privileged user.
14. A Maximum of 3 HSC50s per CI is recommended.
TOPS-20 Doc File, V6.1 (7030) Page 6
Product Summary 05 Sep 85
15. TOPS-20 V6.1 supports a maximum of 24 RAxx drives per HSC50.
16. TOPS-20 V6.1 supports a maximum of 60 RAxx drives per CI.
17. An RA81 disk structure may consist of 1 to 4 spindles.
18. TOPS-20 V6.1 supports up to 32 LAT terminal concentrators
with a total of up to 128 terminal sessions connected to a
DECSYSTEM-20 at a time by any path.
19. DECnet
1. TOPS-20 V6.1 supports DECnet communication via the DN20
as in previous releases, and also supports the NI
(Ethernet) and the CI.
2. TOPS-20 V6.1 supports DECnet Phase IV routing, either as
a level 1 router or as an Ethernet End Node. In either
case, V6.1 fully participates in a Phase IV network with
one exception: links which pass through a DN20 are
restricted to the local routing area, since the MCB is a
Phase III node and thus can only address nodes with
addresses up to 285 in a single area. Links over the NI
and the CI can address the full Phase IV network of up to
63 areas of up to 1023 nodes each.
3. DECnet-20's Network Management can downline load and
upline dump dependent nodes across the DTE20 (eg, DN20)
and across the Ethernet (eg, LAT servers). An additional
special case allows Network Management to downline load
the communication processor Remote Console Facility (eg,
in a Terminal Server).
20. TCP/IP-20
The TCP/IP-20 facilities are available with TOPS-20 V6.1
utilizing the AN20, the CI (to other TOPS-20 systems), and
the NIA20. These facilities are now packaged separately
(QT090). Customers who previously were licenced for QT031
(TOPS-20AN), will become licenced for both QT023 (TOPS-20)
and QT090.
2.0 Software Capabilities
TOPS-20 Doc File, V6.1 (7030) Page 7
Software Capabilities 05 Sep 85
2.1 Features Which Were New To V6.0
This section contains a brief description of the new features in
TOPS-20 V6.0 which have been carried forward to V6.1.
1. SCA support
SCA provides protocol support for the the CI. This includes
JSYS level SCA support for user mode diagnostics. SCA is a
corporate protocol which provides process-to-process
communications on the CI.
2. CI20 Support
CI20 support includes facilities which load the port
microcode, provide error logging of hardware detected errors,
and provide support for user mode diagnostics.
3. HSC50 Disk, Host support
TOPS-20 V6.1 fully supports the HSC50 and its disks.
4. Diagnostic Support
Additional facilities have been added to the DIAG JSYS for
user mode diagnostic support, primarily in the area of the
CI20.
5. Multi-Fork Capabilities in the EXEC
Multiforking is an EXEC feature that organizes a job's memory
into separate, parallel areas called "forks." Each fork
contains one program and its inferior forks, if any. This
organization of memory means users can run several programs
simultaneously. Furthermore, by placing program forks in the
"background," the terminal is free for other work. Once
loaded in memory, program forks can be invoked without
reinitializing. This means that a user can go from a
compiler to an editor and back again without reloading either
program.
6. Maintainability Enhancements
1. BUGCHK Information
The TOPS-20 monitor provides the capability to notify the
operator on a BUGCHK and other warning message cases.
The macro defining BUGCHKs has been modified to allow the
setting of a flag for operator notification.
2. SPEAR Sequence Counter
TOPS-20 Doc File, V6.1 (7030) Page 8
Software Capabilities 05 Sep 85
A sequence number is added to each ERROR file entry. The
sequence number is incremented across system crashes.
3. Auto-Reload of CI20 Microcode
Upon detection of a potentially recoverable failure of
the CI20 microcode, TOPS-20 automatically reloads the
CI20 microcode.
7. Password Encryption
TOPS-20 password encryption facility increases system
security by making it much more difficult to steal passwords
and gain unauthorized access to system resources/services.
Customers may use the DEC-supplied encryption algorithm or
they may write their own. An important feature is a password
encryption version number that allows changes to or
replacement of encryption algorithms without affecting
passwords encrypted with the older algorithm.
8. CHECKD
This utility has had a large amount of maintenance work,
especially in terms of error handling (bad arguments, etc.),
as well as an update to use extended addressing (separate
sections for code and data), thus allowing for dealing with
larger structures and for mapping in DDT.
9. PTYCON
This utility was updated to use the COMND% JSYS for its
command parsing, making it compatible with standard TOPS-20
command syntax.
10. PPN support
To implement more complete support of PPNs in TOPS-20, a word
was added to the directory and IDXTAB was extended to include
a PPN. Changes were made to DUMPER, DLUSR, CHECKD and the
EXEC build command.
11. Active Dual Porting of Massbus Disks
Support was added to allow for dual porting massbus
disks(RP04,RP06,RP07) to two different channels within the
same KL, allowing for the use of one channel when the other
is active. Be sure to see the TOPS20.BWR file entry
pertaining to this feature.
12. Address Space
TOPS-20 Doc File, V6.1 (7030) Page 9
Software Capabilities 05 Sep 85
In order to incorporate a large amount of new code and data,
extensive use has been made of extended addressing
techniques. Users adding features to the monitor or looking
at crashes will need to familiarize themselves with the
extent of these changes. Appendix A and Appendix B provide
information about some of these changes.
13. Galaxy Changes
Galaxy has been enhanced to support new features in TOPS-20
V6.1, particularly those relating to the CI, in particular:
o BUGCHK/BUGINF/Device-problem information to OPR
o Password Encryption
o HSC50 and RA81
o CI20 support
o QUEUE% JSYS support
2.2 New Features in V6.1
This section contains a brief description of the new features in
TOPS-20 V6.1 which have been introduced since V6.0. Many of these
features involve Ethernet support.
2.2.1 Monitor Features
1. Auto-Reload of NIA20 Microcode
Upon detection of a potentially recoverable failure of the
NIA20 microcode, TOPS-20 will automatically cause the NIA20
microcode to be reloaded.
2. LAT Support
V6.1 supports Ethernet terminal concentrators using Digital's
Local Area Transport (LAT) protocol. These concentrators
include LAT-11, DECSA and DECserver-100. V6.1 provides a LAT
Control Program (LCP) subsystem in OPR to control LAT.
3. NI% JSYS
V6.1 includes an NI% JSYS which provides direct user mode
access to the Ethernet. A user program can open an Ethernet
protocol type and then send and receive datagrams with very
little monitor overhead.
TOPS-20 Doc File, V6.1 (7030) Page 10
Software Capabilities 05 Sep 85
4. Ethernet Diagnostic Support
V6.1 includes an LLMOP% JSYS which provides support for
Ethernet Low-Level Maintenance Operation functions (LLMOP).
This JSYS is used by the unsupported tool RMTCON which will
access the Remote Console Facilities on some Ethernet
servers. The LLMOP% JSYS is also used by various diagnostics
available to Field Service personnel.
5. V6.1 provides DECnet Phase IV in the KL host.
1. The DN20, CI and NI are all supported DECnet data links.
The NI is the only fully supported Phase IV DECnet
connection to TOPS-20 systems. The CI is supported only
for communication with other TOPS-20 systems. The MCB
software in the DN20 is the same as delivered with
Autopatch Tape 10. It remains a Phase III DECnet node.
2. V6.1 acts as a DECnet Level 1 Router or as an Ethernet
End Node. As a Level 1 Router, V6.1 can participate in a
DECnet Phase IV network through any of its supported
communication devices. As an Ethernet End Node, V6.1
will only communicate by way of the Ethernet, and will
not incur the CPU overhead of DECnet routing. The choice
between level 1 routing and Ethernet End Node must be
made at system startup with a command to SETSPD. See the
DECnet Installation Guide.
Since V6.1 is a Phase IV DECnet node, the NODES program
is now obsolete.
3. V6.1 provides full Phase IV Network Management, including
Ethernet Downline Load/Dump and Event Logging, but
excluding a Permanent Database and the Ethernet
Configurator Module. DECnet Event Logging includes
multiple local and remote event sinks, console (OPR)
logging, file (ERROR.SYS) logging and fully selectable
event filters.
4. V6.1 continues monitor mode support for TOPS-20's
homogeneous NRT terminal protocol. In the past, incoming
NRT connections were accepted by the MCBNRT program and
then handed over to the monitor with a special MTOPR.
Under TOPS-20 V6.1 incoming NRT connections are fully
handled in the monitor, so the MCBNRT program and its
special .MOANT MTOPR are obsolete.
5. V6.1 includes support for Digital's Remote Command
Terminal (CTERM) protocol. Incoming connections are
handled by a monitor module called CTHSRV. Outgoing
connections are handled by a user mode program called
CTERM-SERVER. The EXEC has a new SET HOST command which
will first call CTERM-SERVER to try to make a connection,
then, if that fails, try to run the program pointed to by
TOPS-20 Doc File, V6.1 (7030) Page 11
Software Capabilities 05 Sep 85
the NRT: logical name. NRT: might be set up to point to
the unsupported SYS:HOST.EXE program, or some other
user-provided terminal protocol handler.
6. NFT and FAL are the same as V5.1 with maintenance
updates.
7. V6.1 adds hooks for outgoing VMS-style Proxy Access.
Outgoing DECnet connections which to not supply a source
process identifier will have a new default source PID.
This PID is used by VMS systems to implement proxy
access.
6. Added SETSPD Functions
The TOPS-20 configuration program SETSPD has added functions:
* Dumps are copied to device DMP:.
* Daylight savings time can be turned off.
* Telephone hangup on LOGOUT is now selectable.
* TOPS-20 LAT's initial state can be changed from ON to
OFF, either to reduce overhead if LAT is not to be used,
or to allow LCP commands to change LAT parameters before
starting LAT.
* Some DECnet parameters which cannot be changed once the
system is running can be changed with SETSPD. Examples
are the DECnet address, buffer size, router/endnode
status.
7. DUMPER has been modified to address a number of SPRs and to
incorporate V6.1 features (eg. password encryption).
Performance has been enhanced in some areas. New
documentation covers all changes and new features.
8. RSX20F provides support for the MCA25 cache and the MG20
memory. RSX20F has also been enhanced to provide CFS
support. RSX20F can now Autobaud at 9600 baud. XON and XOFF
are now handled by the Console Front End.
9. LINK V6 loads multi-section programs. It requires at least
Autopatch 8 to run on V5.1. LINK V6 is required to build the
TOPS-20 V6.1 monitor.
10. PPN support has been added.
TOPS-20 Doc File, V6.1 (7030) Page 12
Software Capabilities 05 Sep 85
11. The EXEC RESET command is now synchronous: it will not
return until all its effects have been completed.
12. V6.1 includes new JSYSs:
* XPEEK%, extended memory version of PEEK.
* WSMGR%, for managing working sets.
* NTINF% to report general network information. The first
NTINF% function reports the host network node of a remote
terminal for SYSTAT.
* CNFIG% to report system configuration.
* SCS% (for DIGITAL diagnostic use only, not supported for
customer use).
* Some NODE% JSYS functions have been added, some have been
made obsolete.
13. Things that will surprise you:
1. Rebuilding index table takes a long time the first time a
V6.0 or V6.1 monitor is run.
2. Numbers are in decimal (units, controllers)
3. SYSJOB and its command file now contain version number in
filespec
2.2.2 Internal Monitor Changes
1. V6.1 makes extensive use of extended addressing. Many data
aggregates are in their own section. For instance, the all
CST's but CST5 are in section 5. DECnet and TCP/IP code has
been moved to section 6. Most code runs in section 1 and
some code runs in its own sections (e.g. DECnet and TCP/IP).
EDDT and MDDT also run in non-zero sections.
2. Global job numbers are assigned across a whole CFS
configuration.
3. The V6.1 BOOT offers faster dumping and the ability to BOOT
from subdirectories.
4. The V6.1 DDT has many improvements for extended sections.
User-mode DDT itself runs in section 37. The program is now
called XDDT.
TOPS-20 Doc File, V6.1 (7030) Page 13
Software Capabilities 05 Sep 85
2.2.3 EXEC Enhancements
1. A colon after device name is now optional in the following
commands: ASSIGN, BACKSPACE, DEASSIGN, DEFINE, DISMOUNT,
EOF, MOUNT, REWIND, SKIP, INFORMATION STRUCTURE, INFORMATION
VOLUMES, and INFORMATION LOGICAL-NAMES.
2. The BUILD and ^ECREATE commands have new features:
* The PERMANENT and WORKING subcommands take INFINITY as an
argument.
* Subcommand PRESERVE
* Subcommand TOPS10-PROJECT-PROGRAMMER-NUMBER nn,nn
* No password typeout
3. The ^ECEASE command has new features
* Requires confirmation, types node name to assure the
operator is shutting down the desired system, downtime
can be announced.
* The NOW subcommand to initiate shutdown immediately after
the confirmation. Equivalent to +00:00.
4. The COPY command has a new subcommand
* SUPERSEDE with ALWAYS, NEVER, OLDER, and NEWER
5. The DDT and MERGE commands have a new subcommand OVERLAY
which will force overlaying of existing pages.
6. Recognition now works in the DEFINE command.
7. The DIRECTORY command has a new subcommand
* The COMPLETE subcommand will cause a display of a full
filespec of each file
8. The INFORMATION CLUSTER command is added. Formatted much
like INFORMATION DECNET, it returns the names of all CFS
nodes and HSCs on a CI.
9. INFORMATION DECNET now allows a node name to be specified.
10. INFORMATION LOGICAL-NAMES now accepts wildcards in logical
name.
11. INFORMATION MAIL SYSTEM checks on system mail.
12. INFORMATION JOB now outputs TCP/IP or DECnet host names.
TOPS-20 Doc File, V6.1 (7030) Page 14
Software Capabilities 05 Sep 85
13. INFORMATION SUPERIORS returns number of superior processes of
this EXEC level.
14. INFORMATION VERSION prints decimal version numbers if VI%DEC
bit is on in version word.
15. LOAD-class-commands have new switches:
/10-BLISS /36-BLISS
/FAIL /PASCAL
/SAIL /SNOBOL
/ABORT /[NO] FLAG-NON-STANDARD
/[NO] WARNINGS /[NO]MACHINE-CODE
16. The LOGIN command has new features
* /FAST switch for logging in without taking command files,
etc. The feature can be controlled with
^ESET [NO] FAST-LOGINS-ALLOWED and SETSPD's
ENABLE/DISABLE FAST-LOGIN-OPTION command.
* Displays date and time of last LOGIN
* New system-wide LOGIN.CMD
* New system-wide BATCH.CMD
17. LOGOUT takes the new system-wide LOGOUT.CMD.
18. The new PERUSE command runs EDITOR: with the appropriate
read-only option.
19. The PUSH command now runs the EXEC pointed to by
DEFAULT-EXEC:.
20. One can now RECEIVE or REFUSE USER-MESSAGES from the newly
unprived TTMSG JSYS as used by the new SEND command.
21. The new SEND is equivalent to the privileged ^ESEND command,
but is available for unprivileged users.
22. Both SEND and ^ESEND have a new user name argument.
23. A new SET HOST command runs SYS:CTERM-SERVER or, if that
fails, the program pointed to by the logical name NRT:.
24. SET MAIL-WATCH takes two arguments, a user name whose mail is
to be watched and a number which sets number of times notice
of new mail is displayed.
25. SET STATUS-WATCH provides a settable control character which
will cause the EXEC to type out file status information.
26. SYSTAT displays originating hostname of DECnet, LAT, and
TCP/IP connections.
TOPS-20 Doc File, V6.1 (7030) Page 15
Software Capabilities 05 Sep 85
27. The ^ESET has new features:
* [NO] LEVEL-ONE-MESSAGES
* [NO] LEVEL-ZERO-MESSAGES
* [NO] WORKING-SET-PRELOADING
28. The SET DIRECTORY PASSWORD command is changed so that the old
password is not requested in certain cases.
29. The SET [NO] TRAP JSYS command has the added switches
/DEFINED and /UNDEFINED.
30. New TERMINAL commands are
* [NO] INHIBIT for graphics terminal.
* [NO] RECEIVE advice, user messages, etc.
* VT200-SERIES
The TYPE command has a new subcommand UNFORMATTED to type
files without CCOC translation.
31. MULTIFORKING FEATURES
* /STAY can be used on the START or CONTINUE commands for
output only programs.
* /BACKGROUND can be used on the START or CONTINUE commands
for any program which requires input.
* /NORMALLY can be used on the START or CONTINUE commands
to keep forks in the foreground.
* INFORMATION FORK-STATUS lists current forks.
* The COMPILE command has a /STAY switch to cause the
compilation to run in the background.
* The CONTINUE n command takes an optional Fork-name or
Fork-number and may have one of the following switches:
/BACKGROUND, /NORMALLY, /STAY.
* The START command may have one of the following switches:
/BACKGROUND, /NORMALLY, /STAY.
* The FORK n command takes an optional Fork-name or
Fork-number and sets the current default fork to n.
* The KEEP command prevents a fork from being killed unless
the user specifically RESETs it.
* The UNKEEP command removes KEEP status from a fork,
causing it to be killed when a new fork is to be started.
TOPS-20 Doc File, V6.1 (7030) Page 16
Software Capabilities 05 Sep 85
* The FREEZE command stops a fork.
* The RESET x command kills one or more forks. x can be
* to reset all but kept forks
. to reset the current fork
fork name, to reset a fork by name.
fork number, to reset a fork by number.
* The SET NAME command sets the current fork's name.
* The ERUN command runs a system program with EPHEMERAL
status.
* The SET FILE [NO] EPHEMERAL command sets ephemeral status
for a program file every time it is run. If a program is
ephemeral, it will not kill another fork to start, and it
will be killed when it finishes. It will appear to have
been an internal EXEC command.
* The SET DEFAULT PROGRAM command sets status for a program
name, so that every time a program with the indicated
name is run it will have the indicated status. The
argument can be one of [NO-]EPHEMERAL, [NO-]KEEP or NONE.
* The INFORMATION DEFAULT PROGRAM command types default
program status.
* The SET PROGRAM command is a single-use form of the SET
DEFAULT PROGRAM command. Its arguments can be one of
o NONE
o [NO-]EPHEMERAL,
o KEEP (AND) CONTINUE or START or RE-ENTER
A kept program will be reinvoked when its name is
typed as an EXEC command. The extra argument to KEEP
indicates how the program is to be invoked; the
default is to START.
2.3 KL Microcode Enhancements
1. XJRST
TOPS-20 Doc File, V6.1 (7030) Page 17
Software Capabilities 05 Sep 85
XJRST has been added to complement the XJRSTF instruction.
XJRST requires a single word address, the XJRSTF instruction
requires a two word flags, address pair.
2. OWGBP in section 0
One Word Global Byte Pointers are now legal in section zero.
This makes application programming easier, since a routine
which uses OWGBPs can now be called safely either from
section 0 or from an extended section.
The fact that OWGBPs are legal in section zero may cause some
existing programs to fail, if they use byte pointers with P
fields larger than 44. The new microcode will try to
interpret these previously illegal values.
3. Speedups of OWGBPs, byte instructions in general
The new microcode speeds up byte instructions in general, and
OWGBPs in particular. OWGBPs are now approximately the same
speed as the new faster standard byte pointers.
3.0 The TOPS-20 V6.1 Software Package
The TOPS-20 software package consists of the following:
1. Cover Letter
2. 1600 bpi Installation Tape
3. 1600 bpi Distribution Tape
4. 1600 bpi Tools Tape
5. Three floppy disks for RSX20F, KL microcode, and front end
software.
The TOPS-20 DECnet (QTD04) package consists of the following:
1. Cover Letter
2. 1600 bpi DECnet Distribution tape
3. 1600 bpi DECnet Tools tape
The TCP/IP-20 (QT090) software consists of the following:
1. Cover Letter
2. 1600 bpi TCP/IP Distribution tape
For Source Sites, the package includes one or more (depending on
licenses) of the following source media:
1. TOPS-20 Monitor Source Tape
2. EXEC Source Tape
3. DECnet Source Tapes (DECnet and TOPS-20 Source License)
TOPS-20 Doc File, V6.1 (7030) Page 18
The TOPS-20 V6.1 Software Package 05 Sep 85
4. TCP/IP Source Tape (QT090 and TOPS-20 Source License)
5. RSX20F Source Disk
The TOPS-20 V6.1 software package contains the same software shipped
with V5.1 except for the following:
1. Components updated as part of V6.0 development.
2. Components updated as part of V6.1 development.
3. Components updated as part of V5.1 maintenance. Autopatched
components are at the same level as Autopatch Tape 11.
The TOPS20.BWR (beware) file indicates those components which have not
been updated and which are not Autopatched. Since sites may have
local edits in this software, customers are advised (in the cover
letter) to read the beware file before superseding anything on their
system.
4.0 System Performance Information
TOPS-20 V6.1 is larger than V5.1 and some of the code paths,
especially those for I/O, are longer in order to accommodate CI disks
and to provide a base for Common File System support. Customers
should anticipate a performance degradation of up to %10 on the same
physical configuration. While Digital expects that this degradation
will be less in most environments, it is difficult to be more
definitive. CI20 performance for a single user is roughly equivalent
to an RP06. When multiple users are accessing HSC50 disks, the total
throughput can approach RP07 speed.
TOPS-20 V6.1 makes greater use of the MCA25 than does V5.1. In most
environments, V6.1 will perform better on a 2065 (with MCA25) than
V5.1 does on a 2060 (no MCA25) where both systems have more than one
megaword of memory.
APPENDIX A
V6.0 ADDRESS SPACE WORK
The address space changes in TOPS-20 V6.1 were made in two stages.
Since some customers have seen the first stage of changes in V6.0, the
changes are presented here in two separate appendices. This appendix
deals with those changes which went into V6.0 and are carried forward
to V6.1. The next appendix deals with those changes made since V6.0.
A.1 Introduction
This document describes the work performed in Release 6.0 in order to
make the monitor fit into its available virtual address space.
A.2 Strategy
When the monitor conversion to extended addressing was begun, sections
0 and 1 (both code and data) were mapped together. Little by little,
code has been changed, and new code has been written, to obey the
rules for running in extended sections. Such code was therefore able
to reference data in any section, and some data (the DST, directories,
etc.) had been moved before TOPS-20 V6.1. All code continued to run
in sections 0 or 1.
The following sections provide a brief description of the changes made
in V6.0.
A.2.1 Movement of Data to Extended Sections
V6.0 ADDRESS SPACE WORK Page A-2
Strategy 05 Sep 85
A.2.1.1 Static Data
Three new macros (RSE, NRE, and NRPE) allow the assignment of extended
addresses to resident and swappable data locations. The related new
PSECTs (ERVAR, ENVAR, and EPVAR) are assigned to an extended section
by statements in STG (or PARAMS). EDEFST and EMSKST provide the
extended equivalent of DEFSTR and MSKSTR.
A.2.1.2 Dynamic Data
A new routine, ASGVAS, provides for dynamic allocation of space in an
extended section. This is used for creating a section map for SCA.
CST0, CST1, CST2, and CST3 have been moved to an extended section.
Space for these tables is allocated at system startup.
Resident free space can be allocated from an extended section if the
caller requests it. The following list contains each new user of
extended free space:
Terminal data
Timer data
DECnet data
In addition, new code written for SCA and CFS uses extended section
free space.
Swappable free space can also be allocated from an extended section.
ENQ/DEQ and IPCF use this.
A.2.1.3 Other Data
DDT's symbol table no longer lives in a separate map, but is allocated
in an extended section.
The descriptions of BUGINFs, BUGCHKs, and BUGHLTs are moved into an
extended section at system startup.
A.2.2 Movement of Code
We have taken a first step toward allowing code in sections other than
0 and 1.
Executive DDT and MDDT now run in their own section.
V6.0 ADDRESS SPACE WORK Page A-3
Strategy 05 Sep 85
Caution
Users executing JSYSs in MDDT will use a
global stack pointer and may crash the
system if the JSYS isn't prepared for
it.
A.2.3 Isolation of Section 0 Code
As more data has been moved out of the code sections, more code has
been converted to run in section 1. The style of some code makes such
conversion difficult, however.
Since code running in section 0 cannot reference data in extended
sections, we have needed to protect ourselves against accidentally
running in section 0. And since this case is not readily detected, we
have decided to remove code from the section 0 map wherever possible.
Thus V6.0 and V6.1 are the first releases in which sections 0 and 1
are mapped separately.
Resident code that can run in section 1 is allocated to the RSCOD
PSECT. It and all swappable code exist only in section 1. Resident
code that must run in section 0 is allocated to the SZCOD PSECT and
mapped to both sections. This allows us to call it from section 1,
and to convert it gradually to run in section 1.
A.3 Effects
A.3.1 Configurations
Many data structures whose size varied according to the configuration
have now been moved to extended sections. Thus we will no longer be
able to squeeze some extra space by reducing configurations. Each
time we need more space, we will have to move new data or code, and
test the effects.
A.3.2 Performance
At a minimum, referencing data outside of the code section requires an
indexed or indirect reference. It seems likely that we have increased
the frequency of pager conflicts. All of these will have a negative
effect on performance.
V6.0 ADDRESS SPACE WORK Page A-4
Effects 05 Sep 85
A.3.3 Changes to Monitor Build Procedures
Because of the limitations of LINK, the PSECTS that exist in extended
sections are created in a nonstandard way. This has caused changes to
the procedures for building monitors.
APPENDIX B
V6.1 ADDRESS SPACE WORK
During the development of V6.1, it became necessary to put monitor
code in to non-unary (neither 0 nor 1) address sections. This
required changes to the way data was accessed and the methods of
interacting with routines in other sections. The following document
was written prior to moving any of this code and outlines
opportunities and problems. Subsequently, the problems were overcome
and code (specifically DECnet and TCP/IP) were made to work in
non-unary sections. This document is provided for customers who may
need to understand the techniques to either debug their systems or to
be able to add local facilities.
B.1 Need for Address Space Work For V6.1 (August 1984)
The V6.1 monitor cannot be loaded to its full extent into a single
section. The symbol table has to be truncated, leading to missing
symbols at runtime and problems with programs that use the SNOOP%
JSYS. Additional linked image address space is required in order to
support a full-sized symbol table.
In order to support a full monitor configuration with 128 jobs and 120
terminals, approximately 25 pages of runtime address space are
required. To support a DECnet/Arpanet monitor with 80 jobs and
terminals, approximately 35 pages are required.
With the advent of LINK version 6.0 and its capability to load
multi-section programs, the linked image problem can be completely
remedied and a mechanism for moving code to extended sections
relieving section 0 address space can be put in place. The actions
are:
o Link the symbol table into an extended section.
o Use a PDV to point to the symbol table, enabling EDDT/MDDT to
be in another section than the symbol table.
V6.1 ADDRESS SPACE WORK Page B-2
Need for Address Space Work For V6.1 (August 1984) 05 Sep 85
o Create a new runtime section that will contain the new
extended code psects XRCOD and XNCOD.
Note that this project will only provide a mechanism for moving code
to extended sections. The actual moving of code is not included.
A few terms:
o Linked image - the EXE file output by LINK
o POSTLD image - the EXE file produced by POSTLD. This image
maps 1-1 into what BOOT loads into physical memory
o Runtime - after paging is set up and turned on
B.2 Overview: Linking the Symbol Table into an Extended Section
LINK version 6.0 will put the symbol table in any section, and this is
used to load the 6.1 symbols into section 6. However, in order for
EDDT to access the symbols before paging is turned on, the symbol
table has to be moved to section 0 of the POSTLD image by POSTLD.
When paging is turned on, the symbols can be moved out of section 0
and put in their runtime location in section SYMSEC.
B.3 Overview: Using a PDV in the Monitor
The symbol table is currently defined by .JBSYM and .JBUSY in the
JOBDAT area. The symbols have to be in the same section as EDDT/MDDT
since the pointers in .JBSYM/.JBUSY are 18-bit quantities.
This restriction can be relieved if the symbol table is pointed to by
a PDV. In addition, this will simplify EDDT/MDDT.
B.4 Overview: Moving code to Extended Sections
The goal is to move already existing code into non-0/1 sections.
Currently, EDDT and MDDT are the only code pieces running in extended
sections.
Existing code makes local (18-bit) references to other code and data
parts of the monitor. It is therefore desirable that extended code
can continue to do this as much as possible. It is suggested that a
new monitor section (symbolic name XCDSEC) is created. The map
(XCDMAP) for the section will be filled with indirect pointers back to
the section 0/1 map. The extended code obviously has to go somewhere
V6.1 ADDRESS SPACE WORK Page B-3
Overview: Moving code to Extended Sections 05 Sep 85
in XCDSEC, and it is suggested that it overlays the NRCOD part of
XCDSEC.
This means that code that makes local references to resident code and
data, as well as to the JSB and PSB, can be moved. However,
references to the swappable monitor code has to be changed to use
30-bit addresses. Note that LINK will not be able to detect any such
references, so this may cause obscure bugs.
The extended code psects will be linked into section 6. XRCOD and
XNCOD will make local references to addresses in another section (i.e.
section 0 where RSCOD/RSDAT/... are linked). LINK would normally
generate a warning message for each such reference. However, LINK
cannot distinguish between a section-local reference and a section 0
address, and no undesired warning will therefore be generated. (The
LINK group assures that there are no plans to change this).
B.5 The Monitor PDV
The monitor will have a PDV defined with the following format:
MONPDV ------> PDVBLK: EXP .PVSYM+1 ;.PVCNT
[ASCIZ /MON/] ;.PVNAM
EXP 0 ;.PVSTR
EXP 0 ;.PVREE
EXP VRSN ;.PVVER
EXP 0 ;.PVMEM
EXP .+1 ;.PVSYM
(symbol table) EXP 7 ;Count
.R50D!len ;Defined symbols!length
PDVSYM: address ;Address of symbols
0
.R50U!0 ;Undefined!length
PDVUSY: address ;= address above
0
This means that only PDVSYM and PDVUSY have to be changed when the
symbol table is moved.
The monitor PDV will live in the RSDAT psect.
B.6 Linked Image
The output of LINK will be a linked image of the following layout (the
actual psect boundaries will vary with the size of the monitor):
Page(s) Contents
0 Absolute storage
V6.1 ADDRESS SPACE WORK Page B-4
Linked Image 05 Sep 85
1-223 RSCOD
224 SZCOD
225-231 INCOD
232-240 RSDAT
241-244 <space for PPVAR>
245-360 <space for RSVAR>
361-377 <space for NRVAR>
400-415 <space for PSVAR>
416-473 <space for JSVAR>
474-721 NRCOD
722-767 <space for NPVAR>
770-777 <currently free>
6000 <Not used>
6001-6017 BGSTR
6020-6022 BGPTR
6023-6267 Symbol table
6270-6473 <future expansion of symbol table>
6474-x XRCOD
x+1-6721 XNCOD
6732-6747 ERCOD (EDDT)
6750-6774 ENCOD (MDDT)
6775-6777 <Not used>
37775-37777 POSTCD
POSTCD must run in an extended section in order to access section 6 of
the linked image. The monitor start address in the entry vector will
be set to 37,,SYSGO. (SYSGO is the start address of POSTLD). POSTLD
will later set another entry vector that contains the monitor runtime
start address.
B.7 POSTLD
The image produced by BOOT is loaded into physical memory as is, i.e.
all things that must be accessible with paging turned off must be put
in section 0 of the image corresponding to the lowest physical 256K.
These are:
o Resident code (RSCOD/SZCOD/INCOD) and resident initialized
data (RSDAT)
o Space for map pages (PPVAR) and resident variables (RSVAR)
o The symbol table
o EDDT (ERCOD)
V6.1 ADDRESS SPACE WORK Page B-5
POSTLD 05 Sep 85
o Space for BOOT (pages 750-777)
NRCOD has to be moved out of section 0 in order to make room for the
symbol table. The symbols can overlay NRVAR/PSVAR/JSVAR/NRCOD/NPVAR
but must leave a 10 page gap at the end before the start of EDDT. (10
pages = number of CST's in extended section * 2 pages to map 512K of
physical memory). Temporary CST's are built into that gap during
pager initialization.
Section 1 of the POSTLD image contains all other psects, i.e.
BGSTR/BGPTR, NRCOD, XRCOD, XNCOD and ENCOD. BGSTR/BGPTR, X?COD and
ENCOD are moved into the same address within the section as they had
in the linked image in section 6. NRCOD cannot be moved into 'its'
location in section 1, since X?COD are already there. Hence, NRCOD
will be put right after BGSTR/BGPTR in section 1. The CST tables are
put in physical memory between NRCOD and XRCOD, so there has to be a
gap of at least 4 * 20 = 100 (octal) pages (assuming 4M of core)
between the top of NRCOD and the beginning of XRCOD. This leads to
the following layout of the POSTLD image:
Page(s) Contents
0-240 Absolute storage, RSCOD, SZCOD, INCOD, RSDAT
241-360 Space for PPVAR and RSVAR
361-625 Symbol table
626-721 Future expansion of symbol table
722-731 Reserved for temporary CST's
732-747 ERCOD (EDDT)
750-777 Space for BOOT
1000 <Not used>
1001-1017 BGSTR
1020-1022 BGPTR
1023-1250 NRCOD
1251-1373 <Currently free>
1374-1473 Permanent physical location of CST tables
1474-x XRCOD
x-1721 XNCOD
1722-1747 <Not used>
1750-1774 ENCOD (MDDT)
1775-1777 <Not used>
POSTLD will write some variables so the monitor initialization knows
where things are. These variables are:
o FREMEM - address of the first free page after the symbol
table. This is where the temporary CST's are built.
o PNRCOD - address of NRCOD after moving it to section 1
V6.1 ADDRESS SPACE WORK Page B-6
POSTLD 05 Sep 85
o PDVSYM/PDVUSY - symbol table pointers
B.8 EDDT in user mode
When EDDT is run in user mode, it must be mapped out of its POSTLD
location in section 0 to an extended section in order to be able to
reference all of the multi-section image. NRCOD must be mapped into
its runtime location in section 0. This means that the symbol table
has to be moved out of section 0 to make room for NRCOD. To support
patching of code in the extended psects (living in section 1 of the
image) the pages containing FFF must be mapped into section 1.
Finally, page 0 of section 0 has to be mapped into page 0 of section 1
to make the breakpoint blocks accessible in all sections.
The default section for EDDT in user mode should be changed to be
section 0.
The DDTU (entry to EDDT) and DDTCZ (on ^Z) will be busy routines, and
DDTU needs to do the following:
o Map symbol table and EDDT into section 37
o Map NRCOD into its runtime location in section 0 from its
POSTLD location in section 1
o Map XRCOD and XNCOD into XCDSEC, and set up the rest of
XCDSEC to map 1-1 to section 0.
o Put indirect pointers from 1,,RSDAT to 0,,RSDAT to enabling
patching of section 1 code. (FFF is located in psect RSDAT).
o Put an indirect pointer from page 1,,0 to 0,,0 to map the
EDDT/MDDT breakpoint block into section 1.
DDTCZ will undo this mapping.
Patching to SWPF in extended psects will not be supported in user mode
EDDT.
The consequences to the user mode EDDT user are:
o Slower startup and exit from user mode EDDT
o No changes for referencing code in section 0.
o Patching to SWPF is not allowed in extended psects.
V6.1 ADDRESS SPACE WORK Page B-7
EDDT in user mode 05 Sep 85
o Break points that are set in user mode may not be hit before
location DDTIBP in PGRINI has been executed (i.e. until
paging is turned on). Warning messages may be generated if
breakpoints are set into SYMSEC in user mode EDDT.
B.9 BOOT
BOOT has to be modified to ignore a PDV entry in the monitor's EXE
directory. No other changes are needed to BOOT.
B.10 Monitor Initialization
The pager initialization routine (PGRINI) starts off with the two
sections of physical memory loaded by BOOT, and has to build the
virtual environment that the monitor is going to run in. The runtime
layout of sections 0/1, 5 and 6 are:
Page(s) Contents
<Section 0 is mapped 1-1 with section 1 (currently)>
1000 Absolute storage
1000-1223 RSCOD
1224 SZCOD
1225-1231 INCOD
1232-1240 RSDAT
1241-1244 PPVAR
1245-1360 RSVAR
1361-1377 NRVAR
1400-1415 PSVAR
1416-1473 JSVAR
1474-1721 NRCOD
1722-1767 NPVAR
1770-1777 <Currently free>
5000 Mapped indirectly to section 0
5001-5017 BGSTR
5020-5022 BGPTR
5023-5267 Symbol table
5270-5367 CST tables
5370-5731 Unmapped, for future expansion
5732-5747 ERCOD (EDDT)
5750-5767 ENCOD (MDDT)
5770-5774 Unmapped, for future references
5775-5777 MDDT private space, mapped to area in PSB
6000-6473 Mapped indirectly to section 0/1
6474-6..x XRCOD
6..x-6721 XNCOD
V6.1 ADDRESS SPACE WORK Page B-8
Monitor Initialization 05 Sep 85
6722-6767 Mapped indirectly to section 0/1
A few changes need to be made to the pager initialization code to
support the new locations of psects, and the new code section and
extended psects. These are:
o The symbol table is currently moved into a temporary location
just after monitor start. This move, along with the
variables SYMMV1/SYMMV2/SYMMV3, is not needed any more since
POSTLD will put the symbols in the temporary location itself.
o There is a new permanent physical location for the CST's.
o Page 0 of SYMSEC is set up with an indirect pointer to
section 0/1. (EDDT/MDDT breakpoint blocks). No other parts
of SYMSEC are mapped 1-1 with section 0/1. Unused pages in
SYMSEC should have a zero in the page map.
o The symbol table is mapped out to SYMSEC.
o The XCDSEC section is created.
o XCDSEC should be set up with indirect pointers to the section
0/1 map.
o XRCOD and XNCOD are mapped into XCDSEC.
o There is a new POSTLD location for NRCOD, defined by PNRCOD.
o There is a new location for BGSTR/BGPTR psects.
B.11 EDDT in Executive Mode
Since the monitor now provides a PDV, it will be simpler for EDDT to
find the symbol table. EDDT should pick up the pointer to the monitor
PDV from MONPDV, and use that to find the symbol table.
MDDT makes a few local references to data, currently relying on parts
of section 0/1 being mapped into section 5. Since this will no longer
be true, the following references to the following section 0/1
locations have to be made global:
o DDTCZ
o MONPDV
o FORKX
o MDDLCK
o MDDFX
o MRETN
V6.1 ADDRESS SPACE WORK Page B-9
EDDT in Executive Mode 05 Sep 85
o SWPMWE
o SWPMWP
The EDDT and MDDT breakpoint blocks (EDDBLK and MDDBLK) must be mapped
into any section in which a breakpoint may be set. The breakpoint
blocks live in page 0, and will be accessible from section 0/1, 5 and
6.
B.12 Other Monitor Work
The routines SWPMLK, SWPMUL, SWPMWE and SWPMWP have to include the
extended code when they are applied.
B.13 The Symbol Table
The symbol table lives a colorful life:
o It is loaded into section 6 by LINK.
o POSTLD moves the symbol table to section 0 in order for the
symbols to be accessible to EDDT before paging is turned on.
o If user mode EDDT is run, then the symbols have to be mapped
out of section 0 (routine DDTU) to make room for NRCOD in
section 0. (Note: this requires that EDDT is also mapped
into a non-zero section).
When the user exits user mode EDDT, then the symbols have to
be mapped back into section 0 (routine DDTCZ).
o The symbols will be mapped into SYMSEC by PGRINI after boot.
The following relation must be true to fit the symbol table into
section 0 at boot time:
symbol_table_size <= ERCOD - 1 - 10000 - NRVAR
I.e. the symbols are put at virtual address NRVAR in section 0, and
must leave a gap of 10 pages (for temporary CST's) before the
beginning of EDDT.
The SNOOP% jsys has to be changed to locate the symbol table through
the PDV.
V6.1 ADDRESS SPACE WORK Page B-10
The Symbol Table 05 Sep 85
Issue: is there any other code that relies on .JBSYM/.JBUSY?
B.14 How to Move Code to Extended Sections
All of section 0/1 except NRCOD will be mapped into the extended code
section. The extended code can make local references to all of the
resident code, to swappable variables (NRVAR) and to resident free
space (NPVAR). To call routines in the swappable monitor, or to call
a subroutine and transfer to section 1, use the XCALL, XJSP or
XCALLRET macro.
These are used in the following way:
XCALL (MSEC1,ASGRES)
XJSP (CX,MSEC1,XYZW)
XCALLRET (MSEC1,MRETN)
There is no psect containing data local to section 6. Data storage is
defined either in section 0/1 with the RS/NR-type macros, or in
extended storage with the RSE/NRE-type macros.
All entry points to extended code have to use the XRENT or XNENT
macro. The XRENT macro defines an entry point to extended resident
code, and XNENT an entry point to extended swappable code.
Assume that an entry point D36INI is defined. The format should be:
;D36INI - runs in extended swappable code
XNENT D36INI
STKVAR <A,B>
code ....
The XNENT macro will do the following things:
o Define a label D36INI in NRCOD.
o Define a label XD36INI in psect XNCOD
o Jump to label XD36INI in section XCDSEC from D36INI in NRCOD.
A routine in section 1 can call an extended routine defined in the way
described by a simple
CALL D36INI
since the transfer to XCDSEC will be made at D36INI in NRCOD. Note:
the caller has to be in section 1.
V6.1 ADDRESS SPACE WORK Page B-11
PSECT Restrictions and Boundaries 05 Sep 85
B.15 PSECT Restrictions and Boundaries
POSTLD will check for psect overlaps and other restrictions concerning
the relations of modules. The symbols 'psect' and 'psectZ' define the
beginning and end of each psect. The following relations are checked
and enforced:
;First module
RSCOD==1000
;Psect overlaps in section 0
SZCOD > RSCODZ
INCOD > SZCODZ
RSDAT > INCODZ
PPVAR > RSDATZ
RSVAR > PPVARZ
NRVAR > RSVARZ
PSVAR > NRVARZ
JSVAR > PSVARZ
NRCOD > JSVARZ
NPVAR > NRCODZ
NPVARZ <= 777777
;Psect overlaps in section 6
BGPTR = 6001000
BGPTR > BGSTRZ
SYPSX > BGPTRZ SYPSX has symbol table
XRCOD & 777777 = NRCOD & 777777 At NRCOD offset
XNCOD > XRCODZ
XNCODZ & 777777 < NPVAR & 777777
ERCODZ & 777777 < 750000
ENCOD > ERCODZ
ENCODZ < 6775000
;Symbol table goes at offset NRVAR and must leave 10 pages before
; EDDT for temporary CST's
symbol_table_size <= ERCOD - 1 - 10000 - NRVAR
;Verify that NRCOD and permanent CST's will fit between BGPTR and
; XRCOD.
XRCOD & 777777 - BGPTRZ & 777777 >=
NRCODZ - NRCOD + 100000
;Verify that FFF is in RSDAT, and that RSDAT, when mapped into section
; 1 by user mode EDDT, will overlay NRCOD
RSDAT <= FFF <= RSDATZ
PNRCOD & 777777 <= RSDAT <= (PNRCOD & 777777) + NRCODZ - NRCOD
;Verify that EDDBLK and MDDBLK is in page 0
EDDBLK < 1000
MDDBLK < 1000