As every practice will have varying requirements we shall list a few examples which you can alter to meet your needs.

Note: When you had the system installed, we will have setup a basic set of times for you. You will not need to worry about this section unless you want to customise the system.

By default, the UUCP sub-system will check for work waiting to be processed twice and hour, 9 and 39 mins past the hour. This is due to the FLAGS line in the control file call_info.

The FLAGS line may contain the r flag, this tells the system when any work is submitted e.g. x_send is run, then just queue it up. One of the UUCP sub-system programs uudemon.hour will run later and any queued work will be send.

One of the first things you should check is if you are setup to queue only (check for r being in FLAGS) and then check the times that uudemon.hour runs (use View/Edit Cron Settings" on the xmenu utilities menu.

To fine tune the system the easiest option is to remove the r flag - use the xmenu utility option Edit /etc/call_info. The rest of this guide assumes the r flag is not present.

The first thing to consider is what time is the modem available? There is no point in setting up a transfer to take place during the day if your modem is only available overnight!

To avoid possible confusion the following examples will refer to the sites as MAIN being the master and BRANCH being a remote site. They also assume that x_check will be running every 30 minutes.

Adding the entries to cron will be covered in the xmenu section of this manual.

1. An overnight transfer:

   Site	Time	Activity
   MAIN	2.15am	Run x_send - Send day's work to branch
   BRANCH	3.15am	Run x_send - Send the day's work to main

   At 2.15am the main site will send the data entered during the previous 24 hours to the branch and this will be integrated at the remote at 2.30am. The Branch will at 3.15am send its information to the main site which will be integrated at 3.30am.

   The cron setting for this situation will be

   Main Site

   15 2 * * * /usr/utilities/x_send
   30 * * * * /usr/utilities/x_check
   

   Branch Site

   15 3 * * * /usr/utilities/x_send
   30 * * * * /usr/utilities/x_check
   

2. A daily example:

   Main surgery's times 9.00-11.00am, 4.00-6.00pm
   Branch 12.00-3.00pm

   After morning surgery x_send should be run (to transfer the mornings work to branch). After the Branch surgery x_send is run (transfer data back to main).

   Site	Time	Activity
   MAIN	11.15	Run x_send - Send work to branch
   BRANCH	15.15	Run x_send - Send afternoon work to main.

   That's it. We don't need to worry about sending the evening surgery data to the branch as it will be added to the mornings work and transferred the next day at 11.15.

   The cron setting for this situation will be

   Main Site

   15 11 * * * /usr/utilities/x_send
   30 * * * * /usr/utilities/x_check
   

   Branch Site

   15 15 * * * /usr/utilities/x_send
   30 * * * * /usr/utilities/x_check
   

   You should bear in mind the amount of work added on a machine directly relates to the length of time the machines will spend talking to each other. Giving an idea of time is difficult, but should be in the region of seconds and minutes rather than 10's of minutes. When scheduling times remember that the modem can only handle one call at a time - so don't schedule both sites to send data at the same time, leave at least 10 minutes to make sure the previous call is finished.

   Also bear in mind the times x_check is run. We have used in the examples 30 minutes past the hour, if you schedule an x_send to run at 35 minutes past then the system will have to wait nearly an hour before the work is visible

   You are not restricted to sending once a day, you can specify multiple times on the one line. Looking at an example where there are three sites:

   Main Site

   30 12,16,20,01 * * 1-6 /usr/utilities/x_send
   5 13,17,21,06 * * 1-6 /usr/utilities/x_check
   

   In this case the main site will run x_send at 1:30am, 12:30, 4:30pm and 8:30pm. Rather than specify that x_check should run every 30 minutes, in this case it is being run at 6:05am, 1:05pm, 5:05pm and 8:05pm. In both case this takes place every day EXCEPT Sunday morning.

   Branch-1

   30 11,15,19,04 * * 1-6 /usr/utilities/x_send
   30 13,17,21,06 * * 1-6 /usr/utilities/x_check
   

   In this case work is sent at 4:30am, 11:30am, 3:30pm and 7:30pm. With x_check running at 6:30am, 1:30pm, 5:30pm and 7:30pm. In a similar manner to the main site no work is transferred on a Sunday morning.

   Branch-2

   20 12,16,20,03 * * 0-6 /usr/utilities/x_send
   45 13,17,21,06 * * 0-6 /usr/utilities/x_check
   

   In this case x_send runs at 3:20am, 12:20am, 4:20pm and 8:20 pm. With x_check running at 6:45am, 1:45pm, 5:45pm and 7:45pm again ignoring Sundays.

   If multiple sites are being cross-updated then ALL the work flows through the main site. That is the two branch machines DO NOT talk to each other. This allows the administrator to make changes on the main machine and not have to worry about physically going to the branch. The work is 'bounced' between sites by x_check.

   We will break down the above example to show the timing of the calls.

   • 11:30 Branch 1 sends in the mornings work to main
   • 12:20 Branch 2 sends in the mornings work to main
   • 12:30 Work from the main site is sent to both remotes
   • 13:05 Main site runs x_check which will send branch 1's work to branch 2 and vice versa.
   • 13:30 Branch 1 runs x_check which will add Main and branch 2's work to it's records.
   • 13:45 Branch 2 runs x_check which will add Main and branch 1's work to it's records.
   • 15:30 Branch 1 sends to main
   • 16:20 Branch 2 sends to main
   • 16:30 Main send its work to both branches
   • 17:05 Main runs x_check which will send branch 1's data to branch 2 and branch 2's data is sent to branch 1.
   • 17:30 Branch 1 runs x_check which will add Main and branch 2's work to it's records.
   • 17:45 Branch 2 runs x_check which will add Main and branch 1's work to it's records.

   This procedure is repeated at 19:30 and 4:30.

   With multiple sites you should plan out carefully step by step the procedures the system goes through to make sure the programs are run in the correct order. There is no point in having the remotes dial in just after the main site has run x_check as there will be a long delay before it is processed.

   The examples given so far assume that both sites can accept incoming calls. Although extra telephone lines are relatively cheap today a number of sites will be attempting cross updating with only dial-out lines. The next example assumes that the main machine has dial-in capabilities and the branches do not.

   It may be that the modem shares the phone line with a fax, or it may be the only phone line, so clients are phoning in on it. If this is the case the modem will have been set-up so it never answers the phone. In this case, it is the branch computer that always phones the main site.

   What happens is you have to take care in setting up the transfer times, because, when the two computers talk, and it doesn't matter who phones whom, work is transferring in both directions automatically.

   Let's have another look at our times, working on the assumption that the main machine does NOT phone the branch, the branch initiates the call.

   The overnight transfer:

   Site	Time	Activity
   MAIN	2.15	x_send - queue the work but don't phone. (This is controlled by adding 'Never' to the Systems file)
   BRANCH	2.45	Run x_send - Send the work AND collect it.

   When the branch phones in at 2.45 to send its work, x_send has already be run on the main machine - so once it has downloaded its information it will collect the main machine's work automatically. The cron setting for this situation will be:

   Main Site

   15 2 * * * /usr/utilities/x_send
   30 * * * * /usr/utilities/x_check
   

   Branch Site

   45 2 * * * /usr/utilities/x_send
   30 * * * * /usr/utilities/x_check
   

   There is very little difference, the problems arise at a quiet branch where no work is entered. This is especially relevant over a weekend where the branch may be closed. This can be handled by setting up 'polling'.

   This will be especially true if multiple sites are in use, with the main site bouncing work to the remotes. The main machine will queue the work, waiting for the remote to call in. If no activity takes place to cause the remote to call then there can be a long delay before the data is transferred.

   This can cause delays of up to 24 hours. You should make sure your end of month procedures are run AFTER all the work has been processed. Rather than run the reports on the 1st wait till the 2nd and run them then.

Polling

When x_send is run, if there is no work to send nothing happens. Only when work is present will x_send initiate the transfer. What we need to do is tell the branch computer that it should always phone the main machine irrespective of whether there is work to send or not. This is called 'polling'. The machines talk very briefly. If work is present a transfer starts, otherwise the call is terminated, and the 'chat' time is about 2 seconds.

Whether or not it is useful to implement polling depends on the activity at the branch. If there are surgeries where you may NEVER see a client you should consider using polling even on the overnight transfer.

There is a section on polling later in the manual.

Summary

1. Cron can schedule transfers to take place automatically, these can be once a night or every few mins.

2. x_send and x_check can be run manually. If the branch needs the information urgently - run x_send on the main machine and they have it.

   Note: You may need to force the connection from the remote site depending on modem access. Additionally, once the branch has received the information an x_check should be run.

3. Leave at least 10 mins between x_send's to allow for machine to finish talking.

4. Consider using polling for sites where no activity takes place.

5. Plan carefully on paper the schedule prior to setting it up. Make sure you think through carefully the times.

6. Each time x_send is run the data queued for transfer is treated completely separately from any other requests. It will accumulate until sent. There is no possibility of data being overwritten if the branch does not phone in, or x_check is not run.

7. Patience! UUCP uses various methods for re-trying busy phones and failed transfers. It may take a while before the work appears on the machine. Do not assume that things are broken just wait and see.