The Path editor is used for creating and editing the path buffer stored in the Setr.exe application. The contents of this buffer define the path to the node in the remote CU (Morse Communication Unit). By using command !p all service requests from Setr.exe will be directed to this CU. This enables remote configuring and diagnostics of such an CU that is temporarily or permanently unavailable for normal routing.
From MORSE main menu type p Enter.
Path32 editor (c)lear (h)elp (1) ... (q)uit >>
(c)lear | — clears whole path | ||||||||||
(h)elp | — instructions for editing path buffer type h Enter
|
Example of how to enter path:
type 1m Enter
type 2c0300 Enter Enter
Path32 editor (c)lear (h)elp ( 1) 690F8100 ( 2) 690F0300 (q)uit >>
The simplest way of making a connection to a remote station is by
using command !h with the address of the opposite station,
e.g. !h690F0300. The pathway from the initial CU to the
destination CU and back can be either trivial or goes through another
CUs which provide for store-and-forward retranslation. All CUs concerned
must have appropriate entries in their respective routing tables. It is
then possible to send packets to this address or carry out path tests
using command !.
The same result can be achieved by compiling short paths in the
Path editor with the initial address on the first line and the
destination address on the second line. The path is activated using
command !p and thereby the path is set-up.
Between the initial address and destination address it is possible
to add one or more addresses. The path between each neighbouring address
pair must then be defined in the retranslation tables, i.e. from
(1) to (2) and back, from (2) to
(3) and back etc. Each of these added addresses becomes the
destination address for the relevant section of the path packet and
according to this address the path is searched in the retranslation
tables. Therefore it is possible to create a new path combined from
several sections, where each of these sections is defined in routing
tables.
The route from the initial to destination CU or some of its
sections can be created from direct defined steps without the need to
use retranslation tables. If so the whole of this section has to be
described in detail, which means that all steps must be there. Each step
is labelled in the path editor with a label, which is a row of zeros
inserted before the step address. The step address is then set according
to the same standards that are valid for addresses in the routing
tables. During the passage of a packet through a Node a path defined in
such a way appears as follows: address 00000000 is found at the place of
the next destination address, which means that the address of the next
step is not searched for in the tables, but the following address in the
path table is used, i.e. the address of the direct defined step. The
resulting entry of the relevant section in the Path editor is now made
up from the initial and destination addresses of the section, between
which are written address pairs from which the first is
00000000 and the second is the address of the direct
step.
Example:
Path32 editor
(c)lear
(h)elp
( 1) 690F8100 starting address of the 1st section
( 2) 690F0300 target address of the 1st section,
which is led on retranslation tables
( 3) 00000000 label 2.1
( 4) 690F8606 directly defined step 2.1
( 5) 00000000 label 2.2
( 6) 69501500 directly defined step 2.2
( 7) 69501500 target address of the 2nd section,
which is created by the directly defined steps
( 8) 69501000 target address of the 3rd section,
which is led on retranslation tables
(q)uit>>!p – activation of path
path 69501000h>! | — dispatch of path packet |
u S02 690F8100 R01 29/ 87 690F0300 R01 25/ 84 690F8606 R01 29/ 92 69501500 S00 S01 69501400 - - 69501401 S00 S02 69501000 serd serd 69501000 S02 S00 69501401 - - 69501400 S01 S00 69501500 R01 26/ 96 690F8606 R01 26/ 90 690F0300 R01 30/ 77 690F8100 u~S02 path 69501000h>
With a !pxxxx command e.g. !p1401 it is possible to
change the last address in the current path and thereby operatively
change the destination of the path packet. This possibility is useful
for creating variant paths, where their last section is found in the
retranslation tables.
The Path packet in the whole listed range is functional from version 4.31.