TWiki> FipDoc Web>SyndicationGuide (15 Feb 2005, DotFingerPost? )EditAttach

FingerPost Syndication and Library System Guide

 

FIP Syndication and Library System Guide

This Guide is copyright info.FingerPost Ltd.

Index

Introduction

1. The Basic Concept

2. The Editorial Side

3. Making a Transmission

4. Managing the Syndication System
List of the management commands

5. Using the Transmission Parameter files

5.1 The SYN Layered approach
5.2 What does a Parameter File look like

6. Copy Flow

7. Library System

8. The System in more detail
8.1 The Parameter Files
8.2 Programs
8.2.1 syn
8.2.2 ipsyn
8.2.3 ipsynd
8.2.4 ipsynf
8.2.5 iplibfilter
8.2.6 Other Fip programs
8.2.7 Scripts
8.3 System Files
8.3.1 GROUPS
8.3.2 PORTS
8.3.3 FIRST &amp LAST
8.3.4 BANNER &amp COPYRIGHT
8.3.5 Log Files
8.4 Queues
8.5 Unix

9. Changing the system</a >

9.1 Installation</a >
9.2 Adding Clients</a >
9.3 Adding Groups</a >
9.4 Adding Ports</a >
9.5 Adding Non-standard SYN clients using IPSYNF</a >
9.6 Adding Library Databases
</a >

10. Running the System

10.1 Well-known errors
10.2 Eclectic errors

11. Examples of Sundry Files

11.1 CLIENT files
11.2 ROUTE files
11.3 REMSYS files
11.4 Transmission Log
11.5 Item Log

INTRODUCTION

The Syndication system is used for the transmission of messages to a number of diverse clients using differing systems via a number of routes. It is generally used where low traffic volumes mean start-stop communications. Generally the system has been designed for the News Information Provider such as a news service, or as a transmission medium between editorial systems and major library databases such as NEXIS and PROFILE.

The process normally follows a fixed procedure : Either a number of messages are stored until all are ready or at a specific time; the client is connected to; the files transmitted and the connection closed.

Broadcast - where the connection is left open - is also available where traffic volumes are higher.

Those clients who wish to receive the service via fax or telex are catered for by a connection to the FIP fax and telex sub-systems.

Similarly clients who prefer to dial-in, browse through a selection of messages and extract those of interest, can do so via a connection to the FIP Simple Mailbox system.

The Syndication system uses the base FIP system for all incoming text from the main editorial front-end. It runs on standard Sun info.MicroSystems computers and Spider systems networking products. Existing modems and x25 pads can be used.

Text can be reformatted to the requirements of the client. There is no limit to the number of files to be sent.

SYN manages the resources you have allocated to it. Hence it will queue clients who need to use the same output port. It also notes when communication problems have aborted a transmission and resends the remaining items.

Each transmission is broken into its constituent parts and each section is defined by parameter files. New clients using routes and systems you already have parameter files for, can be added in seconds and tested without affecting the rest of the system. New routes can be added quickly by non-computer personnel.

1. THE BASIC CONCEPT

The basic concept is that you fit in with the client's needs.

Often in the past, news suppliers have insisted that clients install new lines and equipment in order to receive the service. Nowadays the supplier has to supply text in the format of the client's system via a network he believes is the cheapest and easiest.

The SYN system re-uses existing equipment at both ends of the link - at the source: no port, modem or pad is dedicated solely to one client; at the destination: connections for remote journalists, wire servces or mailbox systems are often used.

In essence, whether or not a new prospect signs for the service should be based purely on commercial grounds. There should be no technical reason why you cannot deliver copy to a new client.

2. THE EDITORIAL SIDE

No technical knowledge is required of the editorial staff who feed syndication. The editor sends each file once with a destination code describing where he wants it to be routed. This code can be the name of a single client, the name of a group of clients or a combination of clients and/or groups. The system automatically breaks this code apart and notes where each file is to be sent.

The editor needs not know how the client gets the text - by the syndication system, fax, telex or simple mailbox. As clients with different delivery paths can be mixed at will in the same group.

For example :
If you have a group called ASIA which includes clients :
tokyo
manila
singapore

and a second group called EUROPE which represents :
paris
rome
brentcross

Valid addreses can be :

paris
which means send to paris only
asia-toyko
which means send to manila and singapore
asia+europe-brentcross
which means send to everywhere but brentcross.

Any wrongly addressed messages are sent back to the editor to adjust accordingly.

The same process is used by the Library staff who prepare the page files for transmission to the full-text databases such as NEXIS and PROFILE.

3. MAKING A TRANSMISSION

Transmissions can be started manually by anyone authorised whether in systems, editorial, library or any other department. Alternatively the system can automatically start transmissions at set times of the day and week.

Transmissions can be made to any combination of clients and groups. As there are normally more transmissions than output ports, the system arbitrates who should go via which port and when. As transmissions finish, the system automatically starts the next.

Occasionally transmissions fail due to line drops or system failures (at the remote site naturally). These occurences are logged by the system which then clears the communication and attempte to restart at the file it was in the process of sending.

After 5 failures, the system looks to see if there is an alternative route for that client and will attempt to use it for 5 attempts. If after all, there are files still waiting to go, the operator is asked to check out the particular area which keeps failing at whichever site or PTT before the transmission is restarted again.

4. MANAGING THE SYNDICATION SYSTEM

At any time the operator can review the progress of transmissions, check what happened and make what alterations are deemed necessary.

Sundry management commands are for locking out ports with malfunctioning modems or PTT lines and unlocking them when they are working again.

All files from the editorial system are archived and, if a client loses his files after transmission, these can be resent.

All happenings are logged - whether it is the start or end of a transmission or as each file is sent to each client or whether a problem occured during a transmission. These items are logged in a separate syndication log while major catastrophies are also noted in the main FIP log so the system manager may act accordingly.

In addition there is a unique transaction log for each and every transmission with details of which port was used, when, who sent which files and how the remote system replied.

These management commands include :

  • Transmit to a client, group or combination.
  • Transmit to a single client from a different queue for special, one-off transmissions.
  • Review the status of transmissions in progress and hose wating to go.
  • Display the list of all clients and groups.
  • Display which clients would be a particular combination of groups and clients.
  • Check the log
    • - for the last files sent.
    • - for the last few transmission failures.
    • - for any occurence of a particular item.
    • - scroll through the whole log.
    • - check what happened for a client.
  • Check what files are waiting for which clients.
  • Resend items for a client from the archive.
  • Read on-line help messages and prompts.
  • Use the unix command TELNET to check a port.
  • Lock a port that is attached to a non-working line or modem, so it is not used temporarily.
  • Unlock a locked port to start using it again.
  • Kill a transmission in progress.

5. USING THE TRANSMISSION PARAMETER FILES

For each client, the system uses three parameter files.

Firstly the CLIENT file itself describes what the remote system is and which route is taken to send copy plus any site and network-specific fields such as logon, password and telephone number to ring.

Secondly a ROUTING parameter file describes how to connect to the remote system using whatever communications devices and networks that are available.

Lastly a REMOTE-SYSTEM file describes how to logon and logoff (if necessary), which message header to use and other formatting instructions.

Often parameter files for the ROUTING and REMOTE-SYSTEM already exist, making it very quick and easy to add or change clients.

For example, parameter files exist for :

Routing :
  • Dial-up via Hayes-compatible modems at various speeds and protocols.
  • Dial-up via non-standard modems such as the ADCOMM or CDS 2224.
  • X25 Packet Switching via a Dynatech Pad.
Remote Systems :
  • Public mailbox services such as :
    Dialcom, including force-delivery.
    Mercury M7500
    Easylink
    IP Sharp
    GEISCO / Quickcomm
  • Message switching systems such as :
    Case Beeline
    ITT Hermes
  • Editorial systems such as :
    Atex
    SII
    Camex / CSI
  • Normal press message formats :
    ANPA
    IPTC
    IATA

The Transmission continued ...

5.1 Every transmission irrespective of client, route or remote-system can be broken down into a series of sections. Not all parts are required for all systems but the concept is to have facilities available if they are needed.

The approach used is to use a small parameter file to describe each section.

These sections and what they are used for, are :

1. PREPARATION
  • what is the text format of remote system; line length
  • maximum take size required.
  • do we require Banner line/Copyright line.
  • do we require First and Last files.
2. CONNECTION TO THE RELEVANT NETWORK
  • setup modem and dial the number
  • wake up pad and connect
3. LOGON TO THE REMOTE SYSTEM
  • logon and password routine
4. START TO TRANSMIT FILES
  • for systems that need to enter a 'file receive' mode.
  • (Send first file)
5. SEND EACH FILE
  • send header
  • (send banner line)
  • send text
  • (send copyright)
  • send trailer
6. END FILE TRANSMISSION
  • to exit 'file receive' mode
  • (Send last file)
7. LOGOFF REMOTE SYSTEM

8. DISCONNECT FROM THE NETWORK

9. FINISH

The Transmission continued ...

Generally the ROUTE file describes sections Connect and Disconnect while the REMSYS file describes sections Logon, Start, File Header and Trailer, Stop and Logoff.

Both files can have a Preparation section which covers both the format of the text and is where certain system options are specified. This section is used for :

  • line lengths; some systems need a CR LF after 80 characters for example.
  • the end of line and end of paragraph symbols; CR LF or CR SPC SPC or an ascii 2.
  • Stating the maximum take size if the remote system has such a restriction plus any 'continued to'/'continued from' text which may be necessary.
  • whether to send the BANNER and COPYRIGHT lines before and after each file. These are files containing standard text which can be added to the tranmission.
  • whether to send the FIRST and LAST files before and after any text files are sent. These two text files are generally used to 'announce' the start of the transmission with appropiate phone numbers and othe information while the LAST file 'announces' the end of the transmission and the number of files sent.

5.2 What does a Parameter file look like

The ROUTE and REMSYS files use a very simple language to describe each section. The language is similar to the various PC communication packages.

Essentially at each stage you imitate a 'human' typing on a dumb terminal; waiting for a prompt and sending a response.

The comand set is small but powerful and includes : wait for incoming text, send tex, send nulls, pause for a second, loop and try again, display text on screen and make log entry.

Let us take an example :

If we expect to be asked Syn Parameter file

Please Login : 
	  w	10/Login/
ALBERT (return) 
	  s	ALBERT\r
Password : 
	  w	10/Password/
ANOSENSE (return)
	  s	ANOSENSE\r

A full list of all commands and system variables is the subject of a later chapter in this guide.
</table border=1>

6. COPY FLOW

7. LIBRARY SYSTEM

The SYN system can also be used to dump each day's paper to one or more of the full-text Library databases such as NEXIS and PROFILE.

The procedure is slightly different from normal Syndication clients because of the amount of data being collected, processed and sent. Although this can be and usually should be controlled manually, there are a number of areas where the system can ease the world of the Library staff.

It is easier to control the dump if the text is arranged in one file per page. An easy to remember filename is made of date-section-pagenumber or for those papers which clip editions, that too can be included.

Each one of these files is processed by the library and when the day's paper is complete, then the files are converted to the particular format of the remote database and sent in the same way as the normal Syndication traffic.

The decision to make is where to process the page files - completely on the editorial system or in FIP SYN system or a mixture of both. This decision depends on how much control and extra editing the Library staff need to do for this particular publication and which system is best suited for this work.

Often the Library prefers to work on the main editorial system. Consequently most of the processing is done here but facilities exist for working on a word processing sub-system of FIP.

For the Atex two programs exist to create these page files.

The first takes an Atex News Layout info.PageIndex and notes all the elements of all the articles - each with a style, width and depth - in an ordinary text file called the Page List file. This list is then edited by removing the names of elements for which the text is not required such as folios, stock market prices and adverts, leaving a list of articles, headlines, bylines, etc.

For those systems without News Layout, directory control files scanning typeset queues can be used to create similar lists at a slower pace.

The second program takes the Page List file, collects all the elements of each of the articles and puts them in one large Page Text file. Each article starts with a header with information that will be used to index the article in the remote databases and each text element is unjustified and hyphenated, all typesetting commands are stripped and non-standard characters are replaced by text strings: eg pounds for &pound.

The Library can then edit this file; checking the text against the printed paper for completeness; adding keywords; checking copyright; adding text from other editions; etc.

When finished the Page Text file is sent to the FIP system in the normal fashion. Library then proceeds with the next page.

When all the Page files have been sent, a filter program is run on the SYN system which processes the file into the exact format required by each database. In particular each database demands a completely different header for each article and this is created from the Page Text header that starts each article. This filter currently can format text to that required by NEXIS, PROFILE, REUTERS-FDS and QL.

The resulting files can now be sent by the SYN system either manually or automatically at a certain time.

As with all other files FIP SYN archives the Page files and they can be resent to one, all or a combination of databases. Corrections and one-off transmissions are sent in the same way.

Library and Syndication transmissions normally do NOT conflict in their demand for resources - in particular output ports. For a morning paper, Library files are often finished by early afternoon when Syndication is just starting. IN the event where they do conflict, the system manager can allocate specific ports for one or the other so that prime traffic can still move.

On Atex the format of the Page List file is :

This file lists the contents of page : 001ST1306-PAGDON-NLA
Name Element Width(cols) Format Depth(mm)
*NATIONAL
M1 1 BOLD 0
H1 5 42BOLD 10
*PLO
M1 1 DEFULT 0
H1 2 36LITE 20
H2 1 BYLINE 20
R1 5 OXFORD 10
R9 0 NVERT 130
*ROVER
M1 1 DEFULT 0
P1 2 PIC 30
H1 2 36BOLD 20
H2 1 BYLINE 20

This page has three articles : NATIONAL which has a headline and text; PLO which has a headlines, a byline, text and 2 rules and ROVER which has a headline, a byline, a picture and text.

If any text is NOT required, the '*' is deleted.

On Atex the format of the Page Text file is, for each article:

QCOMMENT:       
QPAGE:001       
QSECTION:front page       
QEDITION:3
QDATE:1306      
QKEY:star wars
QHEAD:Gorbachev attacks US link on Trident
QSUBHEAD:       
QBY:John Pienaar; Political Correspondent            
QCATCH:NATIONAL   
QSUB:          M1        1          BOLD          0 
QSUB:          H1        5          42BOLD        10
IN A move which could threaten Britain's nuclear deterrence partnership with the US, President Mikhail Gorbachev yesterday warned that further transfers of US nuclear technology to Britain beyond the existing Trident programme could jeopardise a second strategic arms treaty (Start II) with Washington, writes Rupert Cornwell. Reporting to the Soviet parliament on his summit this month

8. THE SYSTEM IN MORE DETAIL

8.1 The Parameter Files

Text, characters, strings and variables

Before describing the parameter files, what text can be specified.

1. any visual ascii character (for space see below).
2. unix system characters which are lower-case chars preceding a backslash '\' :
\r CR or Carriage Return
\n NL or Line Feed or Newline
\f FF or Form Feed
\s SPC or space (same as ' ')
\\ BACKSLASH gives a single '\'
\t TAB
\b BACKSPACE

  1. Character as defined as a three octal numbers following a '\' eg: \040 is a space, \101 is an 'A'.
4. SYN system variables with preceding '\$' :
\$F filename of this message.
\$G 1st 6 chrs of the filename.
\$S Sequence number of this message (999).
\$T no of files sent in this transmission.
\$K no of takes sent in this transmission.
\$B no of blocks sent in this file.
\$C no of characters sent in this file.
\$X time taken to send the no of chars.
\$D Day of the month in '12' format.
\$M Month of the year in 'May' format.
\$Y Year in '90' format.
\$H Hour of the day in '12' format.
\$N Minute of the day in '12' format.

  1. SYN parameter file variables with uppercase letters following a '\'. These refer to text strings in the CLIENT file ie \L1 in the LOGON section should have a corresponding 'L1:text' in each CLIENT file that uses that LOGON :
    \C1 1st parameter of the CONNECTION section.
    \L2 2nd parameter of the LOGON section

Comments are preceded by '#' and all text is ignored until the next line. If you want to specify a '#' in text, use \043. Trailing spaces are stripped, so when needed, use \s to be sure.

Sections

Each one of the sections (see chapter 5) is flagged by a '*' and a letter at the begining of the line. If the section is not required then it can be ignored completely.

Generally the sections are split in the two files - ROUTE and REMSYS :

ROUTE
*p preparation-usually speed and error only
*c connection
*d disconnection
REMSYS
*p preparation
*l logon
*s start of transmission
*h file header
*t file trailer
*e end of transmission
*f logoff

Preparation Section

The format for each line of the preparation file is :

	keyword ':' your_text
If a keyword is not needed, it can be ignored.

Text can be an ascii character, a unix system character such as \r, \n or a character specified as an octal number such as \016. No system variables nor SYN variables should be specified.

  • speed:1200
    probable speed of the link to enable SYN to buffer outgoing text correctly.
  • error:NO CARRIER\r
    the network abort string. If something irregular happens to the transmission, often it is network-related. If SYN receives this string it assumes that the link has been cut and acts accordingly.

  • banner:
    If present, a banner is NOT needed on the top of each outbound message (eg for library files).
  • copyright:
    If present, a copyright is NOT needed on the bottom of each outbound message (eg for library files).
  • first:
    If present, the FIRST file is NOT needed on the beginning of each transmission (eg for library files).
  • last:
    If present, the LAST file is NOT needed on the end of each transmission (eg for library files).
  • ww:80
    wordwrap at the 80th character since an end-of-line irrespective of what the 80th chr is. This number can be any positive number up to 32767. If zero, no wordwrap is necessary.
  • eol:\r\n
    End-of-line sequence for wordwrap.
  • eop:\r\n\s\s\s\s
    End of paragraph sequence when a quad is encountered in the text.
  • eox:\030
    End of fixed buffer sequence when a syncronisation string is required between records.
  • size:19000
    Take size. After 19000 chars the current file will be terminated and a new one started. This number can be any positive number up to 32767. If zero, the remote system can take files of any length.
  • contto:MORE\r
    Where a message has been split into takes, this string is added on the end of each take except the last.
  • contfrom:FILE CONTINUES\r
    Where a message has been split into takes, this string is added on the top of each new take except the first.
  • filerror:SYSTEM ERROR
    For large files, or for buggy remote systems, filerror allows you to specify a error-has-been-found message to abort the transmission.
  • xmodem:

  • ymodem:
    Individual files are to be sent using x or ymodem. In this case HEADER and TRAILER are ignored.

Commands for the Other Sections

Each section has its own small program consisting of a series of commands. These are started at the first command and when the last is executed, FIP SYN continues with the next section. Each command is on one and only one line which ends with a NL and can be up to 250 chars long. Trailing spaces and tabs are ignored, so use the \s or \t unix chars to specify these.

Examples of parameter files are illustrated in chapter 11.

Commands
* beginning of a section with a trailing letter.
IPSYN will ignore the section if you forget the letter, put a space in between or used a unknown letter.
# start of a comment; all text to the end of the line is ignored.
: start of a loop
- end of a loop ie go back to the start of loop
s send characters and strings
eg: s \001IND\$S Starting newfile:\$F
n send null chrs
eg: n 9 # send 9 nulls
z sleep x seconds
eg: z 6 # sleep 6 seconds
d display string on the screen
eg:d \nSending file:\$F now !
l log string in the transmission log
eg:l \nthis is a test transmission\n
r receive text
w wait for text
x wait for text and exit if not received.

Commands r, w and x are similar except for the result. They all have the same format :

		x	/10/GOODSTRING/BADSTRING/
where 10 is the timeout in seconds, and the two strings can be made from and ascii, unix or octal character. The Bad string is optional and can be used for checking for an error message.

The difference is whether or not the result will allow us to exit a loop (or section), or in the case of 'X' to abort the transmission :

Timeout Good Bad
R no no yes
W no yes yes
X abort yes abort

'R' is generally used when no response from the remote system is expected. However between sending files it is often sensible to check that we have not had a network problem which 'R' will pick up. It is rarely used in loops as it does not exit from them.

'W' is the most often used. It is the standard method of exiting loops.

'X' is usually used at the most critical points in the connection and logon sections to ensure that if the connection is NOT clean then transmissions do not start, the program backs out and the whole process restarted afresh. The 'abort' result means exactly that !

8.2 Programs

8.2.1 SYN

SYN is the main management and control program. It is the 'User Interface' and is used by the system operators and managers to check on the status both current and historical, start transmissions etc.

A full list of commands are :

t Transmit to a client, group or combination.
eg: t all
o Transmit to a single client from a different queue - for special, one-off transmissions.
s Review the status of transmissions in progress and those waiting to go.
g Display the list of all clients and groups.
c Display which clients would be a particular combination of groups and clients.
eg: c 330-africa
l,m & f Check the log
- for the last files sent.
- for the last few transmission failures.
- for any occurence of a particular item.
- check what happened for a client's transmissiom
m nexis
m & y Scroll through the whole log or a previous day(s) log
w Check what files are waiting for which clients.
eg: w 330
check files waiting for all the clients in the 330 group
r Resend items for a client from the archive.
eg: r lib
To which client : times
Search string or all : 0707
Here lib refers to the type of traffic - lib, syn, mail etc
h or ? Read on-line help messages and prompts.
eg: h syn.com
p Review a transmission in progress
eg: p profile
x Use the unix command TELNET to check a port.
eg: y 1103
z Lock a port that is attached to a non-working line or modem, so it is not used temporarily.
eg: z 1103
u Unlock a locked port to start using it again.
eg: u 1103
k Kill a transmission in progress.
eg: k holland

8.2.2 IPSYN

IPSYN does all the hard work ! It is designed to do one complete transmission of all the files for one client.

It is started by IPSYND who passes to IPSYN the name of the CLIENT, the PORT to use and the QUEUE to take the files from (usually the same as the name of the client). IPSYN picks up the CLIENT parameter file from /tables/syn/client and from that picks up the parameter files for the ROUTE to take and REMOTE-SYSTEM.

It makes a note in the running queue that it is working and starts the transmission. IPSYND uses this to check it is still running and restarts it if it has bombed out.

All activity is logged in a transaction file called /log/syn/CLIENT.DATE.TIME. While each file sent plus any mishaps are logged in the normal syn log.

As files are sent, they are deleted from the queue.

At the end of the transmission (ie no more files to send), the control marker and the note in the running queue are both removed.

For debugging processes when you may want to run IPSYN manually rather than via SYN/IPSYND, inputs are :

-c clientname : name of the file in /tables/syn/client.
-q queue : (optional) queuename in /spool/syn (defaults to the same name as client).
-p port : port to use. IPSYND has already determined this port to be free; if you run it manually you MUST lockout the port in SYN so that other tranmission do not attempt to use it.
-a : use the ALTERNATE routing specified in the CLIENT file. When running manually, 2 extra (optional) flags are :
-z : do NOT delete the files
-l logname : will log to the filename given rather than the normal log file. This can be 'stdout' in which case the log is the screen. If -l is the last parameter specified then to log both onscreen and infile do a :
-l stdout | tee LOGGY

8.2.3 IPSYND

IPSYND is the process which runs continually in the background (in unix parlance : the daemon) and controls the SYN system on a minute by minute basis.

When the user requests a new transmission via the SYN program, the latter writes a record in /spool/syn/control which IPSYND scans regularly.

When a new request is found, IPSYND checks which type of ROUTE this client needs and looks to see if there are any spare ports for that route. If there are IPSYND starts a copy of IPSYN as described above.

During transmission IPSYND checks to make sure that all the IPSYNs have not aborted. At the end it checks to see if another client can use the now-free port.

8.2.4 IPSYNF

Certain syndication clients need special treatment ! IPSYNF processes texts that are then sent to clients via telex or fax. Plus for those clients that need unusual formats; problem clients in fact. These include those that insist on using proprietary packages which need careful handling.

The resulting files are left either for the rest of the syndication suite to distribute or fax or telex or for some external package.

8.2.5 IPLIBFILTER

IPLIBFILTER is the filter program for the Library databases. It takes the Page Text file from the Library and reformats it for each of the databases. Current databases include NEXIS, PROFILE, REUTERS-FDS and QL.

8.2.6 Other FIP Programs

Various programs from the standard FIP package are used to process Syndication copy. Please refer to the FIP system manager's guide for full information on these :

IPPOST
FAX
TELEX
IPBOX
IP

8.2.7 Scripts

Scripts can be used to customise the SYN package and to add go-faster routeines.

ZAPFIPSYN is used to clean up old transmission files on a daily basis and also to reduce the size of the main Item log file. Additionally it can be used to check if all queues are empty and send if not. It uses program IPMAINT to cleanup the item log.

8.3 System Files

8.3.1 GROUPS

The GROUPS file is used by program IPPOST to decide who is to receive a copy of an article that has just been sent from the editorial system.

The Groups file is also documented in the relevant section of the FIP Manager's Guide as it is also used by telex, fax and mailbox users. Please refer to that for a description of how files are passed from the editorial system to the FIP and SYN system.

GROUPS defines :
1. the name of each group and the clients it refers to
2. in the second part, each client is described with the type of service required.

A single group can be combination of any number of clients. Nesting groups within groups is NOT allowed.

In the file, a line starting with a ';' is a comment.

Groups are flagged with the keyword 'groups:' and a list of clients follow. The group ends at the end of a line. The clients are all lowercase and are separated by spaces tabs and newlines. There should be no space between the ':' and the name of the group.

syntax:

	group: (groupname)	(tab)	(client1) (tab) (client2) ... (clientn) (NL)
eg	group:all		zzp	rgb	southland	bigboys
Every client needs to be defined by a single line which starts with 'client:' and the name of the client. The syntax of the client line is :
	client: (clientname)	(tab)	(type) (tab) (opt number)	(tab) (opt comment)
where the name is all lowercase. All fields are separated by spaces and/or tabs BUT NOT newlines. There should be no space between the 'client:' and the name of the client. The optional comment must be preceded by a ';'.

The Client Type is usually 'syn' for syndication clients. Other options are :

fax for a fax client
fax needs the destination fax number as option.
telex for telex clients - again add the number after.
telex needs a telex number as option.
box for mailbox clients
lib for library databases
xfilter for syndication clients that need special processing and all files are sent outside the SYN system by another system. (eg where a proprietary comms system is used).
zfilter for syndication clients that need special processing but use the SYN system to send all the files.
In both the latter cases, incoming files are directed to IPSYNF for specific filtering before they are available. 

;	Example of Groups for IPPOST
group:all	hedge	arti	irish	blues	bt	telaviv	hk	lucy	boston	greens	sfx	gulf (NL)

group:sports	artspt	irispt (NL)

group:1130	sfx	blues	irish	bt	gulf (NL)

group:530	lucy	greens	irish	bt	telaviv  brazil	sfx	arti	hedge	gulf (NL)

group:lib	profile	fds	nexis (NL)

;	valid clients 
client:hedge		type:syn		; Hedge and Borders News
client:arti		type:syn		; Daily Artisan
client:artspt		type:syn		; sports for the Artisan
client:blues		type:syn		; Blues Today
client:boston		type:syn		; Boston Bugle
client:brazil		type:syn		; brazil
client:bt		type:syn		; bt, isle of wight
client:greens		type:syn		; Greens Recycled and Rehashed
client:hk		type:syn		; hong kong
client:irish		type:syn		; Ireland Tomorrow
client:irispt		type:syn		; sport for irish
client:lucy		type:syn		; Lucy Trumpet, Idaho
client:sfx		type:syn		; san fransisco
client:telaviv		type:syn		; tel aviv
client:tokyo		type:xfilter		; tokyo
client:gulf		type:box		; gulf news, UAE
client:profile		type:lib		; profile
client:fds		type:lib		; fds
client:nexis		type:lib		; nexis
client:justin		type:fax		no:9561964		;tester
client:zib		type:telex		no:0463-12222 	;oink

8.3.2 PORTS

The PORTS file describes which ports are available to the SYN system and which networks they are attached to. The name of each network should have a corresponding parameter file in the /tables/syn/route directory.

As per normal, ';' signifies a comment. 

;
;	Ports file
;
;	describes ports available and which routes can use them
;	syntax is :
;	    (nl) (port no) (spc) (name1) (nl)
;	or  (nl) (port no) (spc) (name1) (spc) (name2) ... (nl)
;	where	 port no is only number only,
;		 names are same as in /table/syn/route
;	note that files in route are u/c
;		 but we are case insensitive here
;
1200	bt48pss	bt24pss	btpss	bt11pss
1406	btpss	bt24pss	bt11pss
1300	btpss	bt24pss	bt11pss
1506	triov21	triov22	triov23	trio212
1501	mnp24	mnp12
1100	mercpkt
1207	mercpkt
1307	mercpkt
1407	mercpkt	mercslow
1305	adcomm

8.3.3 FIRST and LAST

Both these files reside in /tables/syn. They are used to top and tail the text of every transmission with standard text.

They may be ignored if the keywords 'first:' and 'last:' are specified in the *Preparation section of the REMOTE-SYSTEM file. Otherwise they are the same files for all clients.

Text can be any ascii, unix or octal characters plus any system generated string or any SYN string.

There is no size limitation on either file except consideration should be made for any restrictions that any remote system imposes.

An example of the FIRST file is :

	Starting today's transmission of
	The Tuebrook Bugle Syndication Service

	The following articles are copyrighted and are available only to Bugle Subscribers.

	The Bugle editorial can be reached on +93-1-7391-444
	For technical queries ring +93-1-7391-666
An example of the LAST file is :
	End of Transmission of the Bugle News Service.
		No of files sent : \$T

8.3.4 BANNER and COPYRIGHT

Both these files reside in /tables/syn. They are used to top and tail the text of every article with standard text.

They may be ignored if the keywords 'banner:' and 'copyr:' are specified in the *Preparation section of the REMOTE-SYSTEM file. Otherwise they are the same files for all clients.

Text can be any ascii, unix or octal characters plus any system generated string or any SYN string.

There is no size limitation on either file except consideration should be made for any restrictions that any remote system imposes.

An example of the BANNER file is :

	The Tuebrook Bugle Syndication Service for \$D-\$M-\$Y
	This file is \$F (sequence no : \$S)
An example of the COPYRIGHT file is
	//copyright 19\$Y The Tuebrook Bugle, Aigburth

8.3.5 Log Files

SYN uses three separate log files for different purposes.

1. The main FIP log file is used for any major system error as that should be looked at regularly by the main system managers.
2. The SYN Item log logs all happenings to the Syn side - tranmissions starting and stopping, files being sent
3. Each tranmission is logged in its entirety.

Fuller examples of the last two logs are in chapter 11.

A Sample Item log

Thu Jun 14 10:57:06 ippost !i : Incoming file : early15j :1130
Thu Jun 14 11:12:13 syn !t : Starting IRISH
Thu Jun 14 11:13:42 ipsyn (1506) !s : Syn Starting IRISH
Thu Jun 14 11:14:45 ipsyn (1506) !l : File sent to IRISH :	early15j (109)
Thu Jun 14 11:15:28 ipsyn (1506) !t : Finished sending, no of files sent IRISH : 3
A Sample Transmission log
Fri Dec  8 13:27:54 Send (14 chrs):C 2350000750..
Fri Dec  8 13:27:54 Wait 60 secs for 'com' or 'clr':com 2350000750/235000079900..
Fri Dec  8 13:27:55 Ok
Fri Dec  8 13:27:55 Start section l
Fri Dec  8 13:27:55 Start Loop
Fri Dec  8 13:27:55 Send (2 chrs):..
Fri Dec  8 13:27:55 Wait 4 secs for 'ID?' or '':..WELCOME TO MERCURY LINK7500..ID?
Fri Dec  8 13:27:56 Ok
Fri Dec  8 13:27:56 End Loop (0)

8.4 Queues

The following queues are used by the SYN system. Others are in use for the main FIP system which are documented in the main system manager's guide.

All FIP and SYN files are found under their home directory. This is usually /fip but may be any other path as defined at installation time.

All queues in FIP and SYN are lower-case with no special symbols.

  • /spool/syn :
    This is the main path to all the data files for all the clients.
  • /spool/syn/client1
  • /spool/syn/client2
  • /spool/syn/client3
    These are the queues where the data files for each client before transmission. Each queue has the same name as the CLIENT parameter file in -/tables/client and the same name as in the GROUPS file. Extra queues which are not assigned to a particular client can be used for special one-off transmissions (if noted in GROUPS) or testing.
  • /spool/syn/control
    This queue is used by programs SYN and IPSYND to flag which CLIENTS should be transmitted next. When IPSYN has finished and there are no more files, it removes the relevant pointer.

  • /tables/syn :
    This queue contains all the setup and running parameter files for the SYN system. The files held are PORTS, BANNER, COPYRIGHT, FIRST And LAST. Additionally there are three queues:
  • /tables/syn/route :
    hold the ROUTE or NETWORK parameter files.
  • /tables/syn/client :
    hold the CLIENT parameter files
  • /tables/syn/remsys :
    hold the REMOTE-SYSTEM parameter files.

  • /bin :
    Queue holding all binary programs.

  • /local :
    Queue for all the scripts.

  • /fix :
    Internal queue for system files; pls do not touch.

  • /help :
    Text help files reside in this diectory.

  • /log :
    The main SYN Item log (called SYN) resides in this directory as well as the main FIP log (ALL) and other queues which hold the transmission logs.
  • /log/syn :
    Holds the Transmission Log files which are called CLIENT.DATE.TIME

  • /x :
    An internal queue which for FIP programs. Pls ignore. It is cleared each time the system is re-booted. (part of /etc/rc.local).

8.5 Unix

The FIP system manager's guide covers most of the points to make about the unix side and is recommended viewing before changes are made. Additions to that are as follows :

Crontab

Crontab, the scheduler, can be used to start a script at any time of the day or week. For example to make sure that there are no files waiting at the end of the day, write a script that 'touch'es the control records for each client.

So the script (in /local) would be

	/usr/bin/touch /fip/spool/syn/control/CLIENT1
	/usr/bin/touch /fip/spool/syn/control/CLIENT2
	/usr/bin/touch /fip/spool/syn/control/CLIENTn
	/usr/bin/touch /fip/spool/syn/control/CLIENTz
If the script was called IPSENDALL, the line in crontab would be (to start it at 4am everymorning) :
	0   4   *   *   * /fip/local/ipsendall

9. CHANGING THE SYSTEM

9.1 Installation

The FIP system manager's guide covers most of the points to make about the unix side and is recommended viewing before changes are made.

Attention should be made to make sure there is enough buffer and text space in VMUNIX for all the extra processes SYN will generate.

IPSYND and IPSYNF should be added to the SYSTEMS file of IP in order that they are controlled. The host should be 'local' so that they are brought up on system reboot. The syntax for both is :

	name	host	program

eg	synd	local	ipsynd
	synf	local	ipsynf

9.2 Adding Clients

For each new client, first choose a name that is both unique in itself and is neither a root of another client nor is any other client a root of it (ie IND is a root of INDEP and INDEPENDENT). Then take the following steps :

1. Make a queue in the spool/syn directory for the text files and messages:
		cd  /spool/syn
		umask 0
		mkdir client
note that the name of this queue must be lowercase.

2. Create the CLIENT parameter file :
		cd /tables/syn/client
		umask 0
		vi CLIENTNAME
note the name of any FIP file is UPPERCASE.

An example is :

;
;	syn file for the Daily Planet
;
ROUTE:triov22
C1:0800973111
ALT:triov22
A1:0109723459991
SYSTEM:anpa

To explain :

  • Comments are preceded by a ';'.
  • Specify a network to use (case insensitive):
    		ROUTE:btpss
    where btpss is a parameter file in tables/syn/route.

  • Specify any network variables such as the telephone no:
    		C1:731091919
  • Specify the alternate way to the client if necessary :
    		ALT:mercury_pkt_switching
		A1:730797911
    where mercury_pkt_switching is also a parameter file in tables/syn/route.
  • Specify a remote-system to use (case insensitive):
    		SYSTEM:anpa
    where anpa is a parameter file in tables/syn/remsys.
  • Specify any network variables such as the logon and password:
    		L1:ALBERT
		L2:ANOSENSE

3. If the network file specified in the ROUTE or ALT line does not exist, create it (filename should consist of UPPERCASE letters, numbers and the '_' only) in /tables/syn/route.

4. If the remote-system file specified in the SYSTEM line does not exist, create it (filename should consist of UPPERCASE letters, numbers and the '_' only) in /tables/syn/remsys.

5. Lastly add the client to the GROUPS file, firstly as a syndication client and then in any groups.

You can now test the client by sending files from the editorial side and using SYN to transmit. Look in the LOG file of that transmission to check what happened.

See section 8.1 for a full description of the parameter file ROUTE and REMSYS plus section 11 for examples.

9.3 Adding Groups

Add or change groups by altering the GROUPS file as described in chapter 8.

The changes you make will be applicable from the moment you store the file.

9.4 Adding Ports

See the relevant section in the FIP system manager's guide plus the manufacturers documentation for installing a new SpiderPort, Xylogics card etc plus the requiste modem or pad booklet.

0. Physical connection
There is nothing extra to add for the physical connection except to point out the obvious where it comes to cables and power supplies: Check Both before connecting !

1. Programming the modem or pad

Normally the x25 pad is set up on installation and the actual configuration is defined at that point.

Most modems however are software driven and multi-standard. The idea approach to these modems is to use the ROUTE file to reset the modem to factory settings and to setup the parameters required for that specific link BEFORE a transmission starts.

2. the PORTS file

The PORTS file (see chapter 8.3.2) will need to be altered with the Spider Port number and applicable ROUTEing files.

3. Check or write a ROUTE file in /tables/syn/route.

Generally, if the modem is standard there will be existing ROUTE file(s) for this type. As most of the modems are Hayes-based, see if that file can be used.

For non-standard modems, pads and other communication devices: start writing and testing !

9.5 Adding Non-standard SYN Clients - using IPSYNF

Please contact the info.FingerPost Support line if you want to add a non-standard client for advice as how to go about it.

9.6 Adding Library Databases

Adding Library databases is similar to adding a SYN client except the IPLIBFILTER program will be amendment and, where you have scripts to isolate Library transmissions, amending these too.

The steps are :
1. Add the queue in spool/syn with the database name.
2. modify IPLIBFILTER for the extra database.
3. Write and test a suitable REMSYS parameter file if none is suitable.
4. In the file GROUPS, add the name to the 'lib' group, and add a client line with type 'lib'.
5. Amend any general scripts such as IPLIB.
6. Add database-specific scripts, IPname, by copying another (say IPNEXIS) and changing the relevant lines.

10. RUNNING THE SYSTEM

10.1 Well-known errors

The FIP system manager's guide is, yes you have guessed it, the repository of all known dodges about killing spiders etc.

In particular, keep your eyes open for SOCKET ERRORS which usually mean that either the port has a phantom attached :

use unix command to find if there is :
ps -ax | grep 1999 Where 1999 is the port.
kill -9 ppid To kill the phantom, where ppid is the processID.
telnet spiderx 1999 To access it the port and check it is clear (chk the modem is on-hook or pad is 'clr').
If you still have no joy, use the administration port of the spider to KILL the channel :
telnet spiderx 2048 Where x is the no of the spider and the port is always 2048.
ts To show what is attached.
kill z To kill the errant channel

10.2 Eclectic errors

These are eclectic - so please document and/or get hold of the info.FingerPost Support Organisation quickly. They like to know.

11. EXAMPLES OF SUNDRY FILES

11.1 CLIENT files

Example 1.

The normal network used is Mercury packet switching, NUA is 2350000750 while the alternate route is via BT PSS. The remote system is EASYLINK (see the example of EASYLINK in the REMSYS part of this chapter. The Parameter file uses 4 parameters : At logon (ie in the *Logon section), terminal type (L1), logon (L2) and password (L3). While at the Start-to-transmit section (*s), it needs the address of the client as S1.

;
; Syndication file for Edward via Easylink 7500
;
ROUTE:mercpkt
C1:2350000750
ALT:btpss
A1:234218400120
SYSTEM:easylink
L1:22
L2:new777625
L3:zibble.marmite
S1:18760555

Example 2.

The Daily Planet receives copy as though it was a dialup news service using Hayes-type modems. The text is formatted to IPTC message header specifications.

;
;	syn file for the Daily Planet
;
ROUTE:hayesv22
C1:0800973111
ALT:hayesv22
A1:0109723459991
SYSTEM:iptc

11.2 ROUTE files

Example 1.

Using a Dynapad to access a Paket Switching Network. The sections covered in the ROUTE or NETWORK files are Prep (*P), Connection (*C) and Disconnection (*D). The speed of the link should be at 1200 bps and the network has aborted if we get a string of BELLS (octal \007). To connect we first wake up the pad by sending 5 Carriage Returns and wait up to 10 seconds for a '*' (which is the Pads prompt). This loops if not found. We then dial the destination using the C1 parameter which SHOULD have been specified in the CLIENT file. If after 60 seconds we have NOT received the 'com' message (or worse, we have received a 'clr') the whole transmission is aborted.

For the disconnection routine, we sleep for 2 seconds to let everything calm down, send the close-call command to the pad (info.ControlP clr Return) and wait up to 60 seconds for the prompt.

;
;	Route info for BT PSS via Dynapad
;
*prep
speed:1200
error:\007\007\007\007\007\007\007\007\007\007
*Connection
: loop to wake up pad
	s	\r\r\r\r\r
	w	10/*/
-
; dial
	s	C \C1\r\n
	x	60/com/clr/
; and at the end ...
*Disconnect
: loop for *
	z	2
	s	\020clr\r\n
	w	30/*/
-

Example 2.

Using a Hayes-type modem. Preparation is speed of 2400 bps and the network abort message is NO CARRIER Return.

Connection is :
1. escape to command entry by sending 3 plus signs
2. make sure the modem is on-hook (ath0)
3. reset the modem to factory settings (at&f)
4. setup the modem parameters for this transmission.
5. dial the number using parameter C1 which is hopefully in the CLIENT section.
6. If after 90 seconds there is no connection, abort the transmission.

The Disconnect procedure escapes to command entry, and sends the GO ON-HOOK command (ath0).

;
;	description of hayes-type v22bis modem
;
*prep
speed:2400
error:NO CARRIER\r
*Connection
: loop to wake up and setup modem
	z	1
	s	+++
	z	5
	s	ath0\r\n
	r	10/OK/
	s	at&f\r\n
	r	10/OK/
	s	atb0f4s7=80&k1\r\n
	w	10/OK/
-
: dial
	s	atdp\C1\r\n
	x	90/CONNECT/BUSY/
-
;
; and at the end ...
*Disconnect
: loop for OK
	z	1
	s	+++
	z	5
	s	ath0\r\n
	w	20/OK/
-

11.3 REMSYS files

Example 1.

A simple example to begin with. This ignores most of the sections except Preparation (*P), File Header (*H) and File Trailer (*T).

The Preparation is simple too: there are no restrictions on line length and take size (size and both word wraps are set to 0). The End-of-line and Paragraph markers are (Less-than) Return.

The Header is the standard IPTC header of

	[SOH] service sequence-no (space) priority (space) category space) keyword (return) (newline) our-filename (return) (newline) [STX]
where sequence no is system-generated.

The Trailer is

 (newline) (return) [ETX] day-month-year hour:minute (4x newline) [EOT] (return) (newline).
We then wait two seconds for things to calm down and to check if there are any network abort messages.
;
;	description file for the IPTC system
;
*Preparation
ww:	0
eol:	<\r
eop:	<\r
size:	0
*Header
	s	\001PLA\$S 3 IND 999 Independent\n\r
	s	\$F\n\r\002
*Trailer
	s	\n\r\003\$D-\$M-\$Y \$H:\$N\n\n\n\r\004\r\n
	r	2

Example 2.

This example sends copy to the Easylink (or Mercury 7500) public mailbox system. It puts all the copy into one large message and then sends it. However if you have a client who prefers to have each file as a separate item the parameter file can be quickly and easily modified.

;
;	easylink description file
;
*preparation
ww:	80
eol:	\n\r
eop:	\n\r
size:	0
*logon
: wait for the logon prompt
	s	\r\n
	w	4/ID?/
-
; send logon
:
	s	\L1 \L2 \L3\r\n
	w	10/PTS/
-
*start file tx
:
	z	1
	s	\S1+\r\n
	x	20/GA/
-
*header
	s	New File : \$S-\$F\n\r
*trailer
	s	\n\r
	r	2
*end of tx
:
	z	1
	s	\r\nMMMM\r\n
	w	20/ACCEPTED/
-

Example 3.

Lastly an example of a Library database client : NEXIS. It needs files of not more than 15500 characters in length; the split take has (MORE) inseted before the split. No BANNER, COPYRIGHT, FIRST or LAST files should be sent as they are not syndication clients.

Although Logon (*L), Start tx (*S), and End tx (*E), logoff (*F) is used to alert the system operator that the transmission is over.

;
;	descripton file for nexis
;
*Preparation
ww:	0
eol:	\n\r
eop:	\n\r
size:	15000
contto:	(MORE)
first:
last:
copyr:
banner:
*Header
	r	1
	d	Sending \$F
*Trailer
	s	\n\r\004
	r	4
*f-logoff
	d	Finished sending to NEXIS, no of files : \$T \n
	s	\n\r\004\004\004\004\004\004
	z	2
	w	40/bongo/

11.4 Transmission Log 

Fri Dec  8 13:27:51 Syn Starting MERCY via route : MERCPKT using port : 1100
Fri Dec  8 13:27:54 Wait 10 secs for '}' or '(null)':..The Independent {Spider1 v3.6}
Fri Dec  8 13:27:54 Ok
Fri Dec  8 13:27:54 Start section c
Fri Dec  8 13:27:54 Start Loop
Fri Dec  8 13:27:54 Send (5 chrs):.....
Fri Dec  8 13:27:54 Wait 10 secs for '*' or '':..\177{\001\177{\003\177}\003..ready..*..ready..
Fri Dec  8 13:27:54 Ok
Fri Dec  8 13:27:54 End Loop (0)
Fri Dec  8 13:27:54 Send (14 chrs):C 2350000750..
Fri Dec  8 13:27:54 Wait 60 secs for 'com' or 'clr':com 2350000750/235000079900..
Fri Dec  8 13:27:55 Ok
Fri Dec  8 13:27:55 Start section l
Fri Dec  8 13:27:55 Start Loop
Fri Dec  8 13:27:55 Send (2 chrs):..
Fri Dec  8 13:27:55 Wait 4 secs for 'ID?' or '':..WELCOME TO MERCURY LINK7500..ID?
Fri Dec  8 13:27:56 Ok
Fri Dec  8 13:27:56 End Loop (0)
Fri Dec  8 13:27:56 Start Loop
Fri Dec  8 13:27:56 Send (26 chrs):22 new77315 grib.marmite..
Fri Dec  8 13:27:56 Wait 10 secs for 'PTS' or '':...8448853U 8DEC89 13:27 GMT..PTS..
Fri Dec  8 13:27:59 Ok
Fri Dec  8 13:27:59 End Loop (0)
Fri Dec  8 13:27:59 Start section s
Fri Dec  8 13:27:59 Start Loop
Fri Dec  8 13:27:59 Sleep 1 secs
Fri Dec  8 13:28:00 Send (11 chrs):19444999+..
Fri Dec  8 13:28:00 Wait 20 secs for 'GA' or '':..GA..
Fri Dec  8 13:28:00 Ok
Fri Dec  8 13:28:00 End Loop (0)
Fri Dec  8 13:28:00 Sending File merc2
Fri Dec  8 13:28:00 Start section h
Fri Dec  8 13:28:00 Send (22 chrs):New File : 003-first..~
Fri Dec  8 13:28:01 Start section t
Fri Dec  8 13:28:01 Send (2 chrs):..
Fri Dec  8 13:28:01 Wait 2 secs for '' or '':............
Fri Dec  8 13:28:05 ** Timeout **
Fri Dec  8 13:28:05 Start section h
Fri Dec  8 13:28:05 Send (22 chrs):New File : 004-merc2..~
Fri Dec  8 13:28:05 Sending the text ~~
Fri Dec  8 13:28:06 Start section t
Fri Dec  8 13:28:06 Send (2 chrs):..
Fri Dec  8 13:28:06 Wait 2 secs for '' or '':..............
Fri Dec  8 13:28:09 ** Timeout **
Fri Dec  8 13:28:09 File Sent to MERCY :	merc2 (4)
Fri Dec  8 13:28:09 Start section h
Fri Dec  8 13:28:09 Send (21 chrs):New File : 005-last..~
Fri Dec  8 13:28:09 Start section t
Fri Dec  8 13:28:09 Send (2 chrs):..
Fri Dec  8 13:28:09 Wait 2 secs for '' or '':.....
Fri Dec  8 13:28:12 ** Timeout **
Fri Dec  8 13:28:12 Start section e
Fri Dec  8 13:28:12 Start Loop
Fri Dec  8 13:28:12 Sleep 1 secs
Fri Dec  8 13:28:13 Send (8 chrs):..MMMM..
Fri Dec  8 13:28:13 Wait 20 secs for 'ACCEPTED' or '':....ACCEPTED 8448853..
Fri Dec  8 13:28:14 Ok
Fri Dec  8 13:28:14 End Loop (0)
Fri Dec  8 13:28:14 Start section f
Fri Dec  8 13:28:14 Start section d
Fri Dec  8 13:28:14 Start Loop
Fri Dec  8 13:28:14 Sleep 2 secs
Fri Dec  8 13:28:16 Send (6 chrs):\020clr..
Fri Dec  8 13:28:16 Wait 30 secs for '*' or '':LINK7500...Session Time : 0 Mins 20 Secs......\020\004..error..*
Fri Dec  8 13:28:16 Ok
Fri Dec  8 13:28:16 End Loop (0)
Fri Dec  8 13:28:16 Finished sending, no of files sent	MERCY:3

11.5 Item Log 

Thu Jun 14 10:57:06 ippost !i : Incoming file : early15j:1130
Thu Jun 14 11:12:13 syn !t : Starting UUSI
Thu Jun 14 11:12:13 syn !t : Starting IRISH
Thu Jun 14 11:12:13 syn !t : Starting BT
Thu Jun 14 11:13:39 ipsyn (1200) !s : Syn Starting UUSI
Thu Jun 14 11:13:42 ipsyn (1506) !s : Syn Starting IRISH
Thu Jun 14 11:14:11 ipsyn (1200) !l : File sent to UUSI :	early15j (144)
Thu Jun 14 11:14:25 ipsyn (1200) !t : Finished sending, no of files sent UUSI : 3
Thu Jun 14 11:14:45 ipsyn (1506) !l : File sent to IRISH :	early15j (109)
Thu Jun 14 11:15:28 ipsyn (1506) !t : Finished sending, no of files sent IRISH : 3
Thu Jun 14 11:15:29 ipsyn (1506) !s : Syn Starting BT
Thu Jun 14 11:16:36 ipsyn (1506) !x : ** Tx aborted, will restart later : BT
Thu Jun 14 11:16:36 ipsyn (1506) !t : Finished sending, no of files sent BT : 0
Thu Jun 14 11:16:37 ipsyn (1506) !s : Syn Starting BT
Thu Jun 14 11:17:51 ipsyn (1506) !l : File sent to BT :	early15j (111)
Thu Jun 14 11:18:28 ipsyn (1506) !l : File sent to BT :	fsri413 (112)
Thu Jun 14 11:18:50 ipsyn (1506) !l : File sent to BT :	fmiss413 (113)
Thu Jun 14 11:19:43 ipsyn (1506) !l : File sent to BT :	sken1413 (114)
Thu Jun 14 11:20:11 ipsyn (1506) !l : File sent to BT :	sphil113 (115)
Thu Jun 14 11:20:50 ipsyn (1506) !l : File sent to BT :	fefta413 (116)
Thu Jun 14 11:21:32 ipsyn (1506) !l : File sent to BT :	fberl413 (117)
Thu Jun 14 11:22:06 ipsyn (1506) !l : File sent to BT :	fplo413 (118)
Thu Jun 14 11:22:50 ipsyn (1506) !l : File sent to BT :	falg413 (119)
Thu Jun 14 11:23:11 ipsyn (1506) !l : File sent to BT :
feye13 (120)
Thu Jun 14 11:23:45 ipsyn (1506) !l : File sent to BT :	fbuc413 (121)
Thu Jun 14 11:24:30 ipsyn (1506) !l : File sent to BT :	fsov413 (122)
Thu Jun 14 11:25:08 ipsyn (1506) !l : File sent to BT :	bmar1413 (123)
Thu Jun 14 11:26:03 ipsyn (1506) !l : File sent to BT :	bmexic13 (124)
Thu Jun 14 11:26:38 ipsyn (1506) !l : File sent to BT :	fserb413 (125)
Thu Jun 14 11:27:25 ipsyn (1506) !l : File sent to BT :	xrom413 (126)
Thu Jun 14 11:28:04 ipsyn (1506) !l : File sent to BT :	seng1413 (127)
Thu Jun 14 11:28:36 ipsyn (1506) !l : File sent to BT :	xbomb413 (128)
Thu Jun 14 11:29:23 ipsyn (1506) !l : File sent to BT :
xmoss4 (129)
Thu Jun 14 11:29:50 ipsyn (1506) !l : File sent to BT :	xyoung13 (130)
Thu Jun 14 11:30:09 ipsyn (1506) !t : Finished sending, no of files sent BT	:	22

ÿ

Notes and Comments

Edit | Attach | Print version | History: r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r1 - 15 Feb 2005 - 18:38:17 - DotFingerPost?
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback