This is performed by adding entries to the NAMES file of the servers in question. For each remote server one can define up to 16 generic name patterns, each of which may include wild-cards. For more details see the example below. Updates may be sent to remote IBM machines, VAXes connected via Interlink and Unix machines using the CSPACK software.
Note that the default for VM systems is to send the updates using the SENDFILE exec. This can be overridden for individual entries either by sending the updates to a gateway machine, as described later, or by specifying an alternate exec, as for the entry FMVAX.
:nick.FATSERVERS
:list FMSACLAY FATCAT FMIN2P3 FMRAL FMVAX
:nick.FMVAX
:userid.fmsmc
:node.vxcrna
:DIR1.//cern/smc/dst/*
:exec.fat2vax
:nick.FMSACLAY
:userid.fmsmc
:node.frsac12
:DIR1.//cern/smc/dst/*
:nick.FMIN2P3
:userid.fmsmc
:node.frcpn11
:DIR1.//cern/smc/dst/*
:nick.FMRAL
:userid.fmsmc
:node.ukacrl
:DIR1.//cern/smc/dst/*
:nick.FATCAT
:userid.fmfatcat
:node.cernvm
:DIR1.//cern/smc/dst/*
In the preceeding example, all updates referring to generic names beginning //CERN/SMC are sent to the server defined by the name FATCAT, whereas only updates referring to names beginning //CERN/SMC/DST are sent to the servers at SACLAY, IN2P3 and RAL. Note the the FMFATCAT account is in fact a gateway into the Unix-world (using the program in PATCH FATCAT in the FATMEN PAM file and that FMVAX is an account of a VAX linked to the IBM via Interlink, but this is completely transparent to the server.
On systems other than CERNVM, updates that are to be sent to non-VM systems should pass via a gateway service machine.
:nick.FATDESY :userid.R01H1
:node.dhhdesy3
:DIR1.//cern/h1/*
:protocol.mvsjob
:gateway.fmgate at cernvm
:nick.FATVAX :userid.fmh1
:node.vxdesy
:dir1.//cern/h1/*
:protocol.tcpip
:gateway.fmgate at cernvm
:receive.yes
In the above example, updates destined for FATDESY and FATVAX are not send directly, but pass via an intermediate service machine. wakes up at predefined intervals and transfers any files to the specified remote nodes. In the case of the entry FATVAX, files are also retrieved from the remote system.
This method should only be used at CERN. For other systems, a gateway service machine should be used. See the description below for setting up a gateway service machine.
Files sent from IBM VM/CMS systems via the Interlink VM-DECnet gateway will arrive in the default directory for the FAL DECnet object, typically
SYS$SPECIFIC:[ FAL$SERVER ]
By default, the files will be named FATMEN.RDRFILE. At CERN a small modification has been made to the Interlink software so that the files arrive as VAXUSER.FILENAMEFILETYPE, thus files sent to FMOPAL would be called
FMOPAL.FATMEN_RDRFILE
These files can be copied to the correct directory using the command file
FATRL.COM, included in the PATCH DCL of the FATMEN pamfile.
The names file configuration is exactly the same on VMS, MVS and Unix
systems as on VM nodes. The processing of the names file is performed by a
FORTRAN program, FATSEND, which uses the CERN program library routine
NAMEFD and the updates are transferred using the CSPACK routines.
For each remote server, a subdirectory should be created. (If the
subdirectories are note created, they will be created as required by the
server). In the case of the example names file shown below, we would have
the subdirectories [.TOD0SG01 ], [.TOD0SF01 ]and so on (VAX/VMS systems).
The FATMEN server copies all updates into each of these subdirectories and
the program FATSEND copies the updates to the specified remote nodes,
using either TCP/IP or DECnet, and deletes those files that are
successfully copied. DECnet transfers are only possible between VAX/VMS
systems.
On MVS systems, the protocol BITNET is also valid for transmission of
updates to remote VM systems. This is done using the TSO transmit command.
An example names file is shown below.
In this example, servers connecting the the machine D0SG01 will
transmit updates in both directions, rather than the default, which is to
send updates only. This option is useful for the transmission of updates
to a machine that does not accept incoming connections, as is the case
with VAX systems running the UCX TCP/IP software, the Cray at CERN and MVS
systems.
If the tag :queue is specified, the updates are placed in the
specified directory. If not, they are placed in the subdirectory
todo of the account that is used to performed the transfer.
If a subdirectory TOVM exists, the FATMEN server will attempt to send all
updates via Interlink to CERNVM. This option is only intended for use at
CERN.
To send updates from a VM node into a non-VM system, use the :gateway tag
to define a gateway service machine. The VM service machine will send all
updates to this gateway machine, which in turn will transmit them by the
specified protocol at regular intervals using the program FATSEND.
Valid protocols are TCPIP, BITNET and MVSJOB. TCPIP, which is the default,
results in the files being transferred using the CSPACK routines, as
described above. One should normally also set the :receive.yes option so
that updates are also retrieved from these remote systems.
Specfiying BITNET together with a gateway machine permits updates to be
sent to remote nodes at specified intervals, rather than immediately.
Although it is possible to use SENDFILE to send files to MVS nodes, these
files are generally unreadable and hence the preferred method is to
specify the protocol MVSJOB. This will result in an IEBGENER job being
submitted to the remote node, which will copy the updates to a temporary
file in the input queue of the specified server. The usual restrictions on
remote job submission apply.
Configuring servers on VMS, MVS and Unix systems
:nick.FATSERVERS
:list FMSGI FMVAX
:nick.FMSGI :userid.fmd0
:node.d0sg01
:protocl.tcpip
:dir1//fnal/d0/*
:receive.yes
:queue:USR$ROOT37:[FMD0.TODO]
:nick.FMVAX :userid.fmd0
:node.d0sf01
:protocl.tcpip
:dir1//fnal/d0/*
Using a gateway service machine on VM systems