Trailing-Edge
-
PDP-10 Archives
-
QT020_T20_4.1_6.1_SWSKIT_851021
-
swskit-documentation/ddp.mem
There are 5 other files named ddp.mem in the archive. Click here to see a list.
+---------------+
! d i g i t a l ! I N T E R O F F I C E M E M O R A N D U M
+---------------+
TO: List
DATE: March 26, 1979
FROM: Peter Hurley
DEPT: LCG S. E. Dept.
LOC: MR1-2/E37 EXT: 6183
FILE: DDP.MEM
PDM #: PMH-79-012-00-S
SUBJ: DECSYSTEM-20 Distributed Processing Strategy
Distribution List
Dick Snyder
Larry Portner
Jack Mileski
George Plowman
Gordon Bell
Ulf Fagerquist
George Hoff
Per Hjerppe
John Jorgensen
Leslie Hruby
Bill Johnson
LCG Software Engineering Managers and Supervisors
THE DECSYSTEM-20 DISTRIBUTED DATA PROCESSING STRATEGY
Abstract
The term "Distributed Data Processing" (DDP) is growing in popularity.
The term is used for everything from dial up terminals and remote job
entry to a truly distributed database where interactive inquiries
could cause accesses to data stored at any node in the network.
However, most DDP systems have one major flaw, they are limited to
inter-system links of 56 K baud or less. The DECSYSTEM-20 DDP
strategy not only covers the traditional lower speed data
communication facilities but it also encompasses high speed local
networks and multiple processor systems. The latter facilities are
aimed at greater ease of use, lower cost, and higher availability, all
of which are often sacrificed in the traditional DDP systems.
1.0 TRADITIONAL DISTRIBUTED DATA PROCESSING SYSTEMS. . . . . . 2
1.1 DECnet-20. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 TOPS-20 Release 3A - . . . . . . . . . . . . . . . . . . 3
1.1.2 TOPS-10 Release 4 -. . . . . . . . . . . . . . . . . . . 3
1.1.3 TOPS-20 Release 5 -. . . . . . . . . . . . . . . . . . . 3
1.2 Other Traditional DDP Facilities On The DECSYSTEM-20 . . . 4
2.0 DEFICIENCIES OF THE TRADITIONAL DDP APPROACH . . . . . . . 5
3.0 LOCAL HIGH SPEED NETWORKS. . . . . . . . . . . . . . . . . 6
3.1 Ease Of Use. . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Lower Staff And Administrative Costs . . . . . . . . . . . 8
3.3 Growth Potential . . . . . . . . . . . . . . . . . . . . . 9
3.4 High Availability. . . . . . . . . . . . . . . . . . . . . 10
3.5 Performance. . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Hardware Requirements. . . . . . . . . . . . . . . . . . . 13
3.7 Restrictions . . . . . . . . . . . . . . . . . . . . . . . 14
4.0 20/VAX COMPATIBILITY . . . . . . . . . . . . . . . . . . . 14
4.1 20/VAX Growth Strategy . . . . . . . . . . . . . . . . . . 16
To: List Page 2
Subj: DECSYSTEM-20 Distributed Processing Strategy
1.0 TRADITIONAL DISTRIBUTED DATA PROCESSING SYSTEMS
The recently published Distributed Systems Handbook describes
distributed processing systems as covering an extensive range
of possibilities. The range starts with distributed access
via dial-up terminals and remote job entry. After distributed
access comes distributed processing using autonomous systems
without any communications links. In this environment each
computer has its own data base. The only data transfer
between these computers is usually by magnetic tape. This
type of system is only classified as distributed processing
when each of the computers is accomplishing some part of an
overall objective. The next step in distributed processing is
to link the computers together with communications links.
However, because of the limited speed of the communications
lines and because of the complexity of designing distributed
data processing applications most of the processing and data
access remains local to each computer. The ultimate form of
distributed processing would be a network of computers that
share the data processing load and where data access to remote
data bases is as easy as it is to a local data base. However,
there are very few of these systems commercially available
today.
IBM offers a large number of distributed processing products.
However, these are limited to functions such as remote job
entry, remote job execution, file transfer, and limited file
access. A recent release of CICS/DOS/VS introduces the
Inter-System Communications (ISC) facility which gives the
user the ability to access files and data bases on a remote
CICS/VS system. Each of these facilities is based on
traditional communications links of up to 56 K baud. The
aggregate communications transfer rate is also very limited
(e.g., the new 4331 processor (.88 to .99, the speed of a
370/138) can handle an aggregate rate of only 64 K baud).
1.1 DECnet-20
DECnet-20 provides the basis for all of the distributed
processing facilities that are available on the DECSYSTEM-20
family of computers. The DECnet-20 program started in 1977
with the birth of DECnet and it continues to closely track the
corporate DECnet program.
To: List Page 3
TRADITIONAL DISTRIBUTED DATA PROCESSING SYSTEMS
1.1.1 TOPS-20 Release 3A -
DECnet-20 FCS
DECnet-20 was first introduced in Release 3A. This first
release of DECnet-20 supported a single physical link between
a DECSYSTEM-20 and any other Phase 2 DECnet system. Although
the first release of DECnet-20 was a complete implementation
of NSP, only task-to-task communications was supported by
DEC-supplied software. Nonetheless, this has allowed
DECSYSTEM-20 customers to start building distributed
processing networks.
1.1.2 TOPS-10 Release 4 -
Point-to-Point Connections
Release 4 of TOPS-20 will be the second release of DECnet-20.
This release will allow at least 4 physical connections to be
made from a DECSYSTEM-20 to other DECnet Phase 2 (or Phase 3)
systems. Release 4 DECnet-20 will support any combination of
point-to-point connections. Task-to-task DECnet
communications can be established between any two DECnet
systems between which there is a direct physical link.
File Transfer
Release 4 will expand the DECnet-20 facilities to include file
transfer and directory control features such as listing the
file names within a directory and deleting files.
1.1.3 TOPS-20 Release 5 -
Complex Topologies and Routing
Release 5 of TOPS-20 proposes to support even more DECnet
facilities. Specifically, the DECnet-20 implementation will
be upgraded to be a Phase 3 DECnet product. DECnet Phase 3
will support route-through and complex topologies. This will
allow communications to be established between any two
computers in the network even though a direct physical link
does not exist between them.
Network Virtual Terminals
Release 5 will also support Network Virtual Terminals. This
To: List Page 4
TRADITIONAL DISTRIBUTED DATA PROCESSING SYSTEMS
facility will allow users with access to a terminal that is
physically connected to a DECSYSTEM-20 system or a DN200
remote job entry station in the network to logically connect
that terminal to any other DECSYSTEM-20 in the network and use
that terminal as if it were directly connected to that
DECSYSTEM-20. It is our intention that the Network Virtual
terminal protocol created during this development period
become a DECnet standard. Since several other systems are
implementing Network Virtual terminal support during the same
time frame, we will be working with those groups to ensure
that the implementations are compatible with each other. This
goal is extremely important in our effort to promote
ease-of-use across all of DEC's products and to allow
coexistence between DECSYSTEM-20 and VAX systems.
Data Access Protocol (DAP) and RMS-20
In order to increase compatibility between files created by
the various DECSYSTEM-20 languages as well as between other
DECnet systems, Release 5 will implement the Data Access
Protocol (DAP). The basic file opening and sequential I/O
facilities of DAP will be supported by the TOPS-20 MONITOR.
The Data Access Facilities of DAP will be implemented by
RMS-20. The GALAXY system will also be enhanced to support
the submission and execution of jobs to other DECnet systems
in the network.
Network Mail Facility
Release 5 of TOPS-20 will formally support a DECnet mail
facility. Although this facility exists today on the
DECSYSTEM-20 ARPA system, it will be revised for Release 5 to
conform to the corporate mail protocols currently being
specified. This facility will allow DECnet users to send mail
from one DECnet system to users on another DECnet system.
1.2 Other Traditional DDP Facilities On The DECSYSTEM-20
Remote Job Entry
Release 4 of TOPS-20 will support a PDP-ll based Remote Job
Entry station. The RJE station will be a DN200 with a line
printer, a card reader, and a console terminal. The DN200 RJE
facility will be enhanced in Release 5 to support Remote
Terminal concentration as well as the line printer and card
reader. The Release 5 DN200 RJE station will do local echoing
and editing of terminal input. This will make the
responsiveness of remote terminals close to that of local
terminals. Terminals connected to the remote DN200 will also
To: List Page 5
TRADITIONAL DISTRIBUTED DATA PROCESSING SYSTEMS
be useable as Network Virtual Terminals.
2780/3780 Emulation and Termination
Release 3 was the first DECSYSTEM-20 release to support
2780/3780 emulation and termination. These products made it
possible for the DECSYSTEM-20 to act as a Remote Job Entry
station on an IBM system, and for the DECSYSTEM-20 to receive
jobs and print output on 2780/3780 Remote Job Entry stations.
This facility also allows disk data to be passed to and from
IBM systems using the "Card Reader" and "Card Punch" devices.
Hasp Multi-Leaving
Release 4 of TOPS-20 will support IBM Hasp Multi-leaving
emulation and termination. This facility is similar to the
2780/3780 facility in that jobs can be submitted from the
DECSYSTEM-20 to an IBM system or from a HASP Multi-leaving
Remote Job Entry station to a DECSYSTEM-20 system. The
Multi-leaving protocol allows multiple job streams to be
active at once and allows the DECSYSTEM-20 operator to find
out the status of the jobs that have been submitted to the IBM
system.
Gateways
Starting with Release 5 we plan to implement Gateways to
several external networks. Since the X.25 Gateway is the most
important, Release 5 will implement an X.25 Gateway. This
will allow DECSYSTEM-20 systems to connect to each other
through an X.25 based network. We will also be looking at
supporting the X.25 terminal protocols so that terminals on
the X.25 network can connect to a DECSYSTEM-20 .
The knowledge and experience gained with X.25 will lead the
way for other gateways. During the Release 6 development
period we will evaluate the requirements for support of SNA
and ACS networks.
2.0 DEFICIENCIES OF THE TRADITIONAL DDP APPROACH
Over the next few releases the DECSYSTEM-20 will be moving
rapidly into the traditional Distributed Data Processing
areas. The DECSYSTEM-20 will support interconnections to
DECnet systems, IBM systems, and X.25 networks. Users of the
network software will be able to transfer files between
systems, connect their terminals to different hosts in the
network, and access files on other systems in both sequential
and random access modes. The structures for building
To: List Page 6
DEFICIENCIES OF THE TRADITIONAL DDP APPROACH
distributed processing applications will all be present.
Although the plans for providing a base for distributed
processing on the DECSYSTEM-20 meet all of the current
requirements for competing in this marketplace, there is one
large deficiency with this approach. The data transmission
bandwidths that are currently available are too low to allow
large quantities of data to be transferred across the network.
For example, table 1 indicates how long it would take to copy
a file containing the TOPS-20 monitor (330 pages, where 1 page
= 512 36-bit words) from one system to another and how long it
would take to transfer the data from one 2400 foot reel of
tape (about 13000 pages) from one system to another.
K Baud Pages/Sec File Transfer Tape Transfer
+---------------+---------------+---------------+---------------+
! 2.4 ! .078 ! 70.4 min ! 46.2 hours !
+---------------+---------------+---------------+---------------+
! 4.8 ! .156 ! 35.2 min ! 23.1 hours !
+---------------+---------------+---------------+---------------+
! 9.6 ! .312 ! 17.6 min ! 11.6 hours !
+---------------+---------------+---------------+---------------+
! 19.2 ! .625 ! 8.8 min ! 5.8 hours !
+---------------+---------------+---------------+---------------+
! 56.0 ! 1.82 ! 3.0 min ! 2.0 hours !
+---------------+---------------+---------------+---------------+
Time to transfer a 330 page file or a 2400 ft tape
(assumes 60% line efficiency)
TABLE 1
It should be quite evident from this table that transferring
large amounts of data over the synchronous communications
lines takes exorbitant amounts of time. Therefore, the
current distributed processing systems have all been
restricted to doing most of their work locally with occasional
data transfers between systems.
3.0 LOCAL HIGH SPEED NETWORKS
The traditional distributed data processing approach is
definitely required for those instances where the systems in
the network are geographically far apart and where the network
is composed of heterogeneous systems. However, there is an
alternative approach that has not been fully exploited yet.
In the cases where the network of computers is highly
localized (e.g. the same building or cluster of buildings),
then a high speed local network provides many benefits. The
DECSYSTEM-20 distributed processing strategy proposes to
provide both the traditional form of distributed data
To: List Page 7
LOCAL HIGH SPEED NETWORKS
processing and a local high speed network capability. The
local network will consist of a homogeneous network of
DECSYSTEM-20 computers. The network will not be limited to
just one type of DECSYSTEM-20, but any mix of computers from
the entire DECSYSTEM-20 family (provided that the appropriate
hardware interconnects are built). The high speed local
network is being designed to provide our customers with growth
potential, ease of use, lower cost, and higher availability.
It should be remembered that the local network being presented
here is applicable only to a homogeneous network of
DECSYSTEM-20s and that the traditional distributed processing
facilities such as DECnet, IBM 2780/3780 and HASP, and X.25
probably represent a larger and more important market
especially in light of the recent growth of networking in the
computer industry.
3.1 Ease Of Use
The DECSYSTEM-20 local high speed network is being designed to
provide the greatest possible ease of use. The following
features will be a basic part of the design of the local
network.
File System Transparency
The fact that the computer facility is made up of a network
of separate systems will be transparent to the user. The
user can log into any system in the network and access all
file structures in the network. The file structures within
the network will all be named with network-wide unique
names (however, this is not a fixed requirement).
Therefore, node names need not be included in the
specification of a file. This also allows structures to be
transparently moved from system to system thereby providing
higher availability in case of hardware failures. Users
will be able to run all of the DEC supported languages and
applications without modification even though the files or
data bases being referenced are on disks that are
physically connected to other systems in the network. This
includes doing simultaneous access and update to network
wide data bases. Users will be able to "CONNECT (to)" and
"ACCESS" directories on any file structure in the network
(subject to the normal protection mechanisms) regardless of
which system the directories reside on.
Network Wide ENQ/DEQ Facility
The ENQ/DEQ facility that is offered on the single
processor DECSYSTEM-20 will be expanded to support network
To: List Page 8
LOCAL HIGH SPEED NETWORKS
wide use. This means that applications that have been
written to allow simultaneous file access using ENQ/DEQ
will run without change in the local network environment.
Network Wide IPCF and INFO
The local network will support inter-system messages using
the Inter-Process Communications Facility (IPCF). There
will be a network wide INFO process for signing out process
names and for determining the PIDs of other processes in
the network.
Increased Programmer Productivity
Because the programming habits of the applications
programmer does not have to change to write distributed
processing applications for the local network, the
productivity will be increased. Likewise, the ease-of-use
qualities of the network will lower the number of bugs in
these local network applications.
3.2 Lower Staff And Administrative Costs
One of the primary goals of the local network project is to
reduce the cost of running the network. In general, the staff
and administrative costs associated with operating a local
network will be significantly lower than the cost of operating
each system separately. To achieve this goal, the following
facilities will exist.
Central Operator Work Station
From a single terminal anywhere in the network, the
operator will be able to perform all of the normal operator
functions. These include controling the line printers,
card readers, disk and tape mount requests, user requests,
the batch streams, and the external network links.
Central Accounting
The accounting and billing facilities will be centralized.
The accounting data from each system can be collected and
processed together. This provides as much uniformity
across the network as is desired.
Central File Backup and Archiving
The disk backup and archiving procedures for the whole
network can be performed using a central tape library.
To: List Page 9
LOCAL HIGH SPEED NETWORKS
This simplifies the management of the file system
immensely. Since the file system backup and archiving
activity can be performed on a central set of tape drives,
the number of tape drives required in the network will be
substantially lower. Likewise, the number of reels of tape
required to maintain the network's file system archives
will be reduced.
Central Spooling and Shared Devices
The line printer and card reader spooling will be
centralized. This means that fewer line printers and card
readers will be required, lowering the equipment costs
significantly for the smaller systems in the network.
Central Access Control
The access control algorithms set up by the network
administrator can be common throughout the entire local
network. This reduces the amount of programming effort
required to support the individual systems. This also
provides a uniform level of security throughout the
network.
3.3 Growth Potential
The local network facility will allow DECSYSTEM-20 customers
to incrementally expand their computing facilities until it
reaches about 6 to 10 times the capacity of the largest member
of the DECSYSTEM-20 family. Assuming that the required
hardware links are built, customers will be able to link
together any type of computer from the DECSYSTEM-20 family in
any combination. Depending on the requirements of the
customer, the systems in the network could be managed as
either a single facility with one operational and
administrative staff or as a set of individual systems linked
together by the high speed network.
There are many market places for local networking. The
following is a list of the most important markets.
High End Systems
There are a number of DECSYSTEM-20 customers who currently
own the largest system in the DECSYSTEM-20 family. These
customers have no way to expand. Local high speed
networking permits these installations to easily expand
their capacity without incurring extensive extra management
or operational costs. This local high speed network
To: List Page 10
LOCAL HIGH SPEED NETWORKS
solution works in the general purpose time sharing
environment as well as in a shared data base environment
without requiring any reprogramming of existing
applications.
Schools or Businesses with a Limited Yearly Budget
Consider the small schools or businesses that have a
limited yearly computer budget. These organizations can
never justify purchasing in a single year all of the
computing power that they require. However, they could buy
a smaller member of the DECSYSTEM-20 family in the first
year and then incrementally expand their system by adding
another small system each year thereafter. This approach
is also valid for businesses whose computer usage is
predicted to start slowly and build up over several years.
Computer Managers Faced with Decentralization
There are many companies that are large enough to purchase
computers to be located in different departments. In many
cases the manager of the central computer facility would
like to control all of the computing resources in the
company but cannot because of the diversity of the
requirements. Local networking provides the facility that
the manager needs to control each system and yet not
jeopardize the goals set for each individual system. The
leverage that could be gained by selling local networks as
a means for retaining centralized control over
decentralized systems should be significant.
3.4 High Availability
Another of the major benefits of the local network is high
availability. There are varying amounts of availability that
can be achieved depending on the amount of hardware redundancy
that is designed into the network. At a minimum, the mere
addition of the second system into the network raises the
availability of the computing resources significantly. The
following features of the local network increase its
availability.
Loosely Coupled Multiple Processors
As systems are added into the network, the probability of
at least one of these systems being up at any point in time
rapidly approaches 1.0 (excluding catastrophic failures
such as power failures that affect all of the systems at
once). If one system is down, users can dial into another.
To: List Page 11
LOCAL HIGH SPEED NETWORKS
The load may be increased, but at least the computer
facility is still available.
Since the systems in the local network are loosely coupled
(each system is a separate stand alone system connected
only by a single cable), there is minimal chance either
electrically or through software that one system can
adversely affect any other system. This physical isolation
greatly increases the overall reliability of the systems in
the network. It is also this architecture that permits
large numbers of processors (as well as different
processors of the same family) to be connected together
instead of just two as is common with the tightly coupled
systems.
Dual Ported Disks and Tapes
If some of the systems in the network are physically close
to each other, then it will be possible to dual port the
disks and tapes between them. In this case, when one of
these systems is down, its disk and tape drives can be
switched to the other system.
Since the disk file structures all have a unique name
across the network, the structures can be moved from one
system to another without requiring any modification of
user procedures. This allows disk packs to easily be moved
from a system that is down to another system in the network
thereby providing high availability for the important files
and data.
Automatic Recovery on a Crash
If a system in the network crashes, all of the users using
that particular system will have to log in again and
restart from their most recent checkpoint. However, the
users who were logged into another system in the network
and who were reading or writing files on a disk connected
to the system that crashed, these users will not lose any
of the I/O that was in progress. The monitor will
accomplish this by reestablishing the state of the open
files after the crashed system is reloaded. In the case of
two systems whose disks are dual ported between each other,
when one system crashes, the other system will
automatically take over the disks that were in use by the
crashed system and will reestablish the state of each file
that was open at the time of the crash. In this case, the
delay noticed by a user of files on that disk will only be
a few seconds instead of the normal system reload time.
To: List Page 12
LOCAL HIGH SPEED NETWORKS
3.5 Performance
Table 2 describes the disk I/O rates that are commonly
experienced (or predicted) on the various members of the
DECSYSTEM-20 family. The average rate represents what a
loaded system typically sustains over a period of several
hours. The peek rate might be reached for short periods
during file transfers or other heavy I/O activities. It
should be noted that these rates include both swapping and
file I/O. The rates in table 2 (and table 3) are specified in
terms of pages per second. A page, the minimum size disk
transfer ever made by DECSYSTEM-20s, is made up of 512 36-bit
words (4 128-word disk sectors).
Average Peek
System Pages/Sec Pages/Sec
------ --------- ---------
Minnow 15 - 20 30 - 40
2020 20 - 30 40 - 50
2040 40 - 60 70 - 90
2060 100 - 120 150 - 200
Dolphin 250 - 300 350 - 450
TABLE 2
Table 3 describes the net data transfer rates that could be
achieved over various high speed network links. The table
also indicates the worst case degradation in response that
could result due to the added time required to transmit the
data over the link. These worst case response values are
given as a percentage of the response time that could be
achieved on a system whose disks were all locally connected.
The I/O transfer rates assume that the links are utilized at a
60% efficiency level.
Worst Case
Link Speed Net Rate Responsiveness
---------- -------- -------------
1 Mega Baud 32.5 Pages/Sec 33 %
5 Mega Baud 162.8 Pages/Sec 71 %
10 Mega Baud 325.5 Pages/Sec 82 %
50 Mega Baud 1627.6 Pages/Sec 95 %
(Assumes 60% Efficiency)
TABLE 3
From these two tables it should be evident that a link of 5
mega baud will be sufficient to support two 2060s linked
together without undue degradation in throughput. However, it
would still be possible with some programs to incur noticeable
To: List Page 13
LOCAL HIGH SPEED NETWORKS
degradation in response time if all of the file I/O is done
over the link. In this case and in the case of more than two
2060s linked together, the link should be closer to 10 mega
baud to achieve reasonable throughput and responsiveness. The
50 mega baud link guarantees that the throughput and
responsiveness will be satisfactory for a multiple 2060
network.
3.6 Hardware Requirements
ICCS Bus
The HYDRA project is designing a high speed inter-system
bus called the Inter-Computer Communications Switch (ICCS).
As currently planned, the ICCS bus will be a triaxial cable
of up to 150 feet in length and it will be capable of
running at a gross speed of 50 mega baud (with an expected
net efficiency of 60%). The ICCS bus will support a star
configuration and will allow up to 16 components to be
inter-connected.
The ICCS bus is definitely a requirement for providing
large transparent multiprocessor configurations using 2060s
or Dolphins. For configurations that can be set up to
minimize the I/O traffic across the inter-system link, the
high speed ICCS bus would not be necessary.
Ring Net
Since the high speed ICCS bus is limited to very short
distances (150 feet), a longer system inter-connect is
needed to satisfy the network configurations that span an
entire building or cluster of buildings. However, the
trade-off for longer distances is slower transmission
speeds. There are several possible approaches available
for providing longer links. MIT has developed an 8-10 mega
baud link called "Ring Net" that is capable of being run up
to 1000 feet between nodes (or between repeaters) for up to
256 nodes. This design has one restriction in that it
requires that the network be in the shape of a ring. DEC
is also looking at building a slower speed version of the
ICCS bus that would run at about 5 mega baud for distances
of 1000-2000 feet.
These slower speed links would be well matched for the
smaller members of the DECSYSTEM-20 family or for
configurations where the file I/O being performed on an
individual system in the network is reasonably localized to
that system.
To: List Page 14
LOCAL HIGH SPEED NETWORKS
MX20
As a backup strategy, we could implement the local network
software using two 2060s linked together by an MX20 and
shared memory. This approach would allow the local network
software to be developed for inclusion in Release 5 of
TOPS-20 without out the risk of the ICCS bus slipping out
of the Release 5 time frame.
3.7 Restrictions
Shared Writable Pages
There is one restriction with this local network approach.
It will no longer be possible to use shared memory for
process synchronization unless the processes are all
running on the same CPU. Although there is no restriction
on having shared writable memory, the processes using this
facility must use ENQ/DEQ and UFPGS to avoid race
conditions.
4.0 20/VAX COMPATIBILITY
This section discusses how the DECSYSTEM-20 distributed
processing strategy fits in with the corporate VAX strategy.
It is very clear that DECSYSTEM-20 users will never be able to
merely pick up their programs, bring them to a VAX system, and
run them without out modification. However, there are a
number of steps that we are taking to make it easier for
DECSYSTEM-20 and VAX systems to coexist together.
DECnet
The DECSYSTEM-20 and VAX processes can already communicate
to each other using DECnet task-to-task links. With the
future releases the DECnet networking capabilities will be
enhanced to support complex topologies and routing.
File Transfer via DECnet and ANSI Tapes
Release 4 of TOPS-20 will support file transfers to and
from VAX systems using both DECnet and magnetic tapes. The
DECnet file transfer capability will be based on the Data
Access Protocol (DAP). Magnetic tape compatibility between
To: List Page 15
20/VAX COMPATIBILITY
the DECSYSTEM-20 and VAX will be based on the ANSI Tape
Label Standard.
Inter-system Job Submission
Release 5 of TOPS-20 will allow DECSYSTEM-20 users to
submit jobs over a DECnet link to a VAX system for
execution. This facility will be implemented using the DAP
protocols.
Network Virtual Terminals
Perhaps the most important part of 20/VAX compatibility
will be the network virtual terminal facility. This
mechanism will allow DECSYSTEM-20 users to set their host
to be the VAX system. They will then be able to use the
VAX system as if they were directly connected to it. By
using a combination of the file transfer facility, the
inter-system job submission facility, and the network
virtual terminal facility, DECSYSTEM-20 users will be able
to gradually start converting old applications and writing
new applications for the VAX system while continuing to run
their "bread and butter" production DECSYSTEM-20 programs
without perturbation.
It should be noted that the current VAX plans only address
being able to support network virtual terminals between VAX
systems. However, the DECSYSTEM-20 will support linking
terminals to VAX systems as well as other DECSYSTEM-20s.
This means that users who need to switch back and forth
between the two systems must be using a terminal that is
physically connected to the DECSYSTEM-20.
Network Mail
A corporate network mail protocol is currently being
developed. This will allow both VAX and DECSYSTEM-20 users
to correspond between their systems.
Data Interchange Utility
A utility to interchange data between DECSYSTEM-10/20
systems and VAX systems is currently being designed. The
goal of this project is to allow easy conversion of data
files from the 36-bit format to the 32-bit format.
To: List Page 16
20/VAX COMPATIBILITY
4.1 20/VAX Growth Strategy
As the corporate VAX strategy starts to take effect, the
number of VAX systems in the field will increase dramatically.
Likewise, the range and flexibility of the VAX family will
also grow. It will become more and more desirable for
DECSYSTEM-20 customers to coexist with VAX systems. The tools
described above provide the basis for this coexistence. For
example, consider a DECSYSTEM-20 installation faced with the
problem of expansion in 1985. By that time the
price/performance offerings of the VAX family will have
surpassed those of the DECSYSTEM-20 family. The installation
may decide that it is time to expand by purchasing a VAX
system and to put all new applications on the VAX system. In
the mean time, the older production jobs will continue to be
run on the DECSYSTEM-20. The VAX system would be brought in
and linked to the DECSYSTEM-20 with one of the supported
inter-connect strategies described previously. The use of
network virtual terminals, file transfer, and the Data
Interchange Utility would then permit an easy transition
between the two systems. This transition should be
considerably less traumatic than switching to any other
vendor.