Trailing-Edge
-
PDP-10 Archives
-
6.1_emacs_manuals_1er
-
manuals/tops20.doc
There are 37 other files named tops20.doc in the archive. Click here to see a list.
TOPS-20 DOC FILE
November , 1984
Version 6(6356)
COPYRIGHT (C) DIGITAL EQUIPMENT CORPORATION 1976, 1984. 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 RESPONSIBLITY FOR THE USE OR RELIABILITY OF
ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
Page 2
1.0 PRODUCT SUMMARY
TOPS-20 V6.0 will provide the software required to use
HSC50 controllers and RA81/RA60 disks, by providing support
for the KL 2060 interface to the CI (the CI20) and the
software interfaces to the new disk subsystem.
TOPS20 V6.0 will be a product only on the KL10 based 2060
systems. It will ship in support of the CI20/HAS50/RA81/RA60
hardware and will ONLY ship to those sites which order that
hardware. It will not, therefore be a full distribution to
the field (and thus will not supercede v5.1 at all sites). It
will include updates from the latest Autopatch distribution at
the time of its delivery (Autopatch tape 8). There will be a
major update to the TOPS20 documentation set along with this
release, though it will be distributed in 'soft-copy' on an
additional magtape and not as a hardcopy update to the
existing manual set.
Page 3
1.1 TOPS-20 V6.0 System Facilities Specification
The following outlines some of the major points of support in
v6.0, as well as certain restrictions:
1. TOPS-20 V6.0 and the CI20 require a KL10 Model B
Processor.
2. TOPS-20 V6.0 and the CI20 will not be supported on KL10
Model A or KS10 processors.
3. There can be a maximum of ONE CI installed in a KL10
processor and that must be a dual path CI.
4. TOPS-20 V6.0 and the CI20 will work with legal
combinations of internal (MF20 or MB20) memory.
5. CI20 will not be supported on external memory if the
system uses SA10's, DX10's and/or if the external memory
is other than MH10 or MF10, configured in 4-Bus mode.
6. The CI20 will NOT be supported on a system without cache
(NOT 2040's)
7. TOPS-20 V6.0 will always contain the code for the CI
support whether or not the system has a CI20.
8. TOPS-20 V6.0 will require a MINIMUM of 768K words of
memory
9. TOPS-20 will support a MAXIMUM memory configuration of
3.072 megawords.
10. TOPS-20 V6.0 will support RA81 and RA60 disks on the
HSC50, but will not support TA78 tapes.
11. TOPS-20 V6.0 will NOT support CFS configurations. This
support will be available with the next full Tops-20
distribution.
12. TOPS-20 V6.0 will NOT support the use of an HSC50 disk as
a PS: structure.
13. CI-20 RELOAD
The CI-20 micro-code will initially be loaded at system
start up by a program running under SYSJOB. During normal
operation, this program will automatically reload the
CI-20 microcode if required. The file containing this
microcode must be located on the massbus disk serving as
PS:.
14. A Maximum of 3 HSC50's per CI is Recommended
Page 4
15. TOPS-20 V6.0 will support a maximum of 20 Raxx drives per
HSC50
16. TOPS-20 V6.0 will support a maximum of 60 RAxx drives per
CI
17. An RA81 disk structure may consist of 1 to 4 spindles.
18. ARPA (TCP/IP)
1. TCP/IP support will be distributed seperately from the
standard Tops-20 package and will ONLY be distributed
to ARPA customers (ie those currently supported uner
QT031)
2. TCP/IP Maximum Configuration
Tops-20 v6.0 monitors built to support BOTH ARPA
(TCP/IP) and DECNET networks will not support maximum
configurations ( jobs,TTY's, memory,etc). At a
minimum, such monitors will support those
configurations possible under v5.1 of Tops-20. (This
was approximately 80 jobs, 2 meg W memory, 10 pages
less JSB free space )
3. All Tops-20 monitors will have DECNET support built
in. NON-DECNET builds of Tops-20 will not be
supported, except for the special case of ARPA. Given
that we will be restricting the configurations
possible for ARPA/DECNET monitors, we will continue to
make it possible to build non-DECNET monitors (through
the use of an build parameter, as is now the case) in
combination with ARPA.
4. TCP/IP will NOT have NCP Capability
The TCP/IP implementation will not include NCP
capability. NCP is in the release 5 alpha test of
TCP/IP and provides the ARPA customer with a method of
transitioning between the two protocols. By the time
v6.0 is released, there should not be a need for this
facility.
2.0 DELIVERY
TOPS20 V6.0 will be delivered as an update to all
customers who:
1. Have ordered CI hardware (CI20/HSC50/RA81/RA60) and
Page 5
2. Who are eligible for QT023 or QT031 and
3. Who have a KL 2060 or 2065 processor
It will not be available to 2020, 2040 nor "model A (QT010)"
customers.
It will be delivered as part of the CI hardware shipments.
2.1 Hardware
New Hardware (including microcode and diagnostics)
1. CI-20 -- CI bus channel
2. CI bus (star coupler)
3. KL-microcode
4. HSC50 disk subsystem
This includes the RA81 fixed media disks, the RA60
removable disks
Required Hardware
1. Minimum system configuration for 2060 or 2065 system
2. At least 768K memory
Page 6
Configurations
Minimum Maximum
------- -------
Memory
768K 3 meg
KL's per CI 1 2 (with CFS-20)
HSC's per CI 0 3
CI disks
per HSC 1 20
per CI 0 60
Ra81's per Tops-20
structure 1 4
RA60's per Tops-20 1 4
structure
3.0 SOFTWARE CAPABILITIES
This section contains a brief description of each new feature
in TOPS20 V6.0.
1. SCA support
This task will provide support in the Monitor to implement
the SCA protocol on 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
Provide Monitor software to drive the CI on a KL10 using
the CI-20 hardware. This task includes producing software
to: load the port microcode, provide error logging of
hardware detected errors, and support for user mode
diagnostics.
3. HSC50 Disk, Host support
This is the disk driver module in TOPS20 which
communicates with the HSC50 disk or equivalent using the
MSCP protocol.
4. Diagnostic Support
This task will add additional facilities to the DIAG JSYS
for user mode diagnostic support, primarily in the area of
the CI-20.
Page 7
5. Larger main memory configurations
The amount of memory that TOPS20 can support will be
increased to 3.072 megawords from (about) 2.5 megawords.
This will be done my moving the Core Status Tables to a
non-zero section.
6. Multi-fork capabilities in 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.
7. RAMP Support
1. BUGCHK Information
The Monitor will provide the capability to notify the
operator on a BUGCHK and other warning message cases.
The macro defining BUGCHKs will be modified to allow
the setting of a flag for operator notification.
2. Spear sequence counter
A sequence number be added to each ERROR file entry.
The sequence number will be implemented to increment
across system crashes.
3. Auto-reload of CI-20 Micro-code
Upon detection of a potentially recoverable
failure of the CI-20 Micro-code, Tops-20 will
automatically cause the CI-20 micro-code to be
reloaded.
8. 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 effecting passwords encrypted with the
older algorithm.
Page 8
9. 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.
10. DUMPER
The only development changes being made to DUMPER for
Tops-20 v6.0 are the inclusion of the changes necessary
for supporting Password encryption and PPN-support.
11. PTYCON
This utility was updated to use the COMND Jsys for its
command parsing, making it compatible with standard
Tops-20 command syntax.
12. 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.
13. 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 .
14. ARPANET TCP/IP
The TCP/IP support currently in the field with Tops-20
v5.4 has been integrated into the v6.0 monitor.
15. Address space: While not part of the user functionality,
there does exist a major sub-project within v6.0 of
Tops-20 which is aimed at supplying sufficient
code-section address space to create reasonable monitor
configurations.
See appendix A for more details.
16. Galaxy Changes
Galaxy has been enhanced to support the change in Tops-20
v6.0, particularly those relating to the CI, in
particular:
o BUGCHK/BUGINF/Device-problem information to OPR
o Password Encryption
Page 9
o HSC and RA81
o CI support
o QUEUE% JSYS support
4.0 TOPS-20 V6.0 SOFTWARE PACKAGE
The TOPS-20 V60 package is a normal distribution kit
except for the inclusion of a documentation tape.
All sites receive the following:
1. Cover Letter
2. Software Product Description (SPD) in letter form
3. Printed copies of the TOPS-20.BWR (beware) and TOPS-20.DOC
files
4. Installation Tape
5. Distribution Tape
6. Floppy Disks for RSX20F and microcode
7. TOPS-20 V6.0 Documentation Tape
In addition, TOPS-20AN (QT031) customers receive:
1. A TCP/IP Binary tape
For Source Sites, the package includes one or more (depending
on licenses) of the following source media:
1. TOPS-20 Source Tape
2. EXEC Source Tape
3. TCP/IP Source Tape (QT031 and TOPS-20 Source License)
4. RSX20F Source Disk
The TOPS-20 V6.0 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 V5.1 maintenance.
Autopatched components are at the same level as Autopatch
Tape 8.
The TOPS-20.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
superceding anything on their system.
Page 10
5.0 SYSTEM PERFORMANCE INFORMATION
TOPS-20 V6.0 is larger than V5.1 and some of the code
paths, especially 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
%12 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
approaches RP07 speed.
TOPS-20 V6.0 makes greater use of the MCA25 than does
5.1. In most environments, V6.0 will perform better on a 2065
(with MCA25) than 5.1 does on a 2060 (no MCA25) where both
systems have more than one megaword of memory.
APPENDIX A
A.1 INTRODUCTION
This document describes the work performed in Release 6 in order to make the
monitor "fit" into its available virtual address space. Unlike the CI
projects, this project does not provide new facilities to the user, nor does
it involve the creation of new modules. Rather, it consists primarily of
changes to existing code.
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.0. All code continued to run in sections 0 or
The following sections provide a brief description of the changes made in v6.
A.2.1 Movement Of Data To Extended Sections
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.
Page A-2
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
NSP 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.
NOTE
Caution, users executing jsys's in MDDT will use
a global stack pointer and may crash the system,
if the jsys isnt prepared for it.
Page A-3
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 is the first release 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. Worse, some changes have led us to the use of OWGBPs.
It seems likely, too, that we have increased the frequency of pager conflicts.
All of these will have a negative effect on performance.
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.