no. 3257938 filed 21.30.03 fri 3 feb 1989
from chiv
to chiv
cc comm
subj Ipsanet Strategy
This message annouces major changes to Ipsanet, including the introduction of Reuternet access. These changes will eventually affect ALL users. The text is 4 pages long. The message is bcc'ed to:
canem east eurem koala usemp reuters@ipsa agent davos siss temp tlc tmt uan
WHY ARE CHANGES NEEDED?
Four main reasons:
* Ipsanet is the communications network for the Reuters
Historical Information Group. So it must provide efficient access to Textline, Country Reports and other non-APL systems, as well as to APL systems.
* To deliver products which are more sophisticated, efficient and easier to use.
* The Alpha minicomputers are now obsolete. It is impossible to implement the additional features on the Alpha.
* When Ipsanet was first developed, it was almost unique. Now there are many established network standards. It is more efficient to use standard equipment and software where available, to which IPSA adds value.
WHAT CHANGES? Changes to the technology are happening throughout Ipsanet:
* The connections between host APL systems and Ipsanet are being migrated to standard X.25 connections, replacing our proprietary 3705 software.
* New Beta nodes, using PC hardware and IPSA software, are replacing the Alphas. Already over 10 per cent of operational nodes are Beta nodes.
* Pads are replacing Alphas as the network equipment to which most users connect.
* A new style of user access is being provided, called 'Reuternet', with a new sign-on procedure.
THE EFFECT OF THESE CHANGES
All these changes are carefully planned and executed to causeminimum inconvenience to users, eventually producing a more versatile, more reliable, faster and cheaper communications service. But some changes are visible.
The most important change is in the interaction between the user and the network, including changes to the sign-on procedure.
There are now two asynchronous standards: 'Reuternet' for the new universal standard, and the original 'Ipsanet'. There will be a migration over several years, after which all access will be through Reuternet ports. Ipsanet ports will be retained as long as is needed to smooth the transition.
* Reuternet ports
From a Reuternet port you may connect directly to both APL and non-APL systems.
In most cities, the same phone number will provide dial-up Reuternet service for any terminal speed, with the option of error correction.
As Ipsanet expands into new cities, or as faster speed dial-up is introduced in existing cities, the new services will only be provided on Reuternet ports.
Although these are very important benefits, the penalty is a lack of upward compatibility, especially in the sign-on procedure. If today you type the sign-on process, then the change to a Reuternet port is very simple: you will need to to change the commands you enter before you get a sign-on blot. See the example at the end of this message. However if your sign-on is currently semi-automatic, for example because you use 'Connect' on a PC, then the automatic process will fail: you will need a new version of your PC comms software or a new sign-on script.
* Ipsanet ports
From an Ipsanet port you may connect directly only to a Sharp APL system.
Most existing users connect to Ipsanet ports, provided either on an Alpha, or on a Pad which is configured to emulate an Alpha as closely as possible. In some cities users are being transferred from Alphas to Pads.
Pad emulation ports differ from Alpha ports in sign-on procedure, flow control, interrupt handling and input buffering. In most cases existing PC software will cope with the change without modification, and most users are not aware of the change. However, there will be a few users with non-standard applications which will need changes.
NEED MORE INFORMATION?
If you are a developer of PC applications which connect to Ipsanet, or if you are responsible for the support of a product, then you will need more information about the changes. The Communications department, mailbox 'comm', can help you.
* They can tell you how you are currently connected, what changes are planned, and suggest ways in which you can test either an Ipsanet Pad or a Reuternet connection.
* Developers who need specifications should request copies of the Asynchronous Users' Guides for Ipsanet and Reuternet by mailbox to 'tnetadmin'.
EXAMPLES
The following examples show how the change from an Ipsanet to a Reuternet port affects one of the commonest cases: connecting to the IPSA internal system from a hardwired terminal.
Input from the terminal ends with Carriage Return. In the examples, <lf,lf,bel> represents the network prompt of two linefeeds followed by a bell; <blot> represents the APL sign-on blot.
IPSANET PORT
|
From Terminal |
Response |
Comments |
|
. |
<lf,lf,bel> |
Only necessary on PAD ports. |
|
|
|
Both Alpha and PAD ports |
|
)zoo |
<blot> |
Connect to APL. |
REUTERNET PORT (current procedure)
|
From Terminal |
Response |
Comments |
|
|
|
Reuternet pad:10 port:04 |
|
|
|
|
Select service: |
PAD sends banner message and |
|
|
ips |
com <lf,lf,bel> |
|
|
|
|
|
|
|
|
)zoo |
<blot> |
|
|
Development is under way to simplify the procedure for connecting to an APL system from a Reuternet port; it is hoped to introduce this change in 2nd quarter 1989.
For dial-up connections to Reutemet ports, the procedure is similar, except that initially '....' must be sent from the terminal in order to receive the PAD banner message.