| Cross Updating | Release Notes | Doc Center | FAQ's | Manual |
As we explained earlier, not all practices have phone systems that will allow the support department access all the time. It may be un-manned, night service etc. In addition, if we use our modem to contact your machine, we cannot 'see' what is happening when your machine phones the branch.
You should note that both x_check and x-send will send electronic mail to the user specified in MAILTO line of call_info (default 'root') if either program encounters difficulties. One of the first thing to do is to check the mail to see if any messages relate to cross updating.
The following section will give you the procedures to follow in tracking down and troubleshooting cross updating.
The Troubleshooting can be broken down into two area:Comments on phone systems
Normally, there will be no problem with the transfer. However, with some of the telephone systems being used, you will need to consider the following:
- Modem not switched on or not plugged in.
- Night service not switched over.
- Someone picks up the phone while a transfer is taking place.
- Computer switched off.
- Noise on the phone line.
- Someone (a human) answers the phone.
All these problems will cause the transfer to fail. What happens? If a transfer fails, the computer will immediately retry the connection, and try again. If it succeeds all is OK, otherwise it will wait a period of time and try again. When the computer retries, the time between retries gets longer and longer. If, in the case of night service phone lines, the machine may be made to retry during the day, the call will again fail.
Care must be taken if you do not have a direct phone lines to ensure that any 'manual intervention' is carefully followed and the procedures are followed to minimise failed transfers. Situations like this just waste time all round and cause needless concern.
Noise on the phone line can cause a transfer to fail. If a large file is being transferred the whole file must be re-sent. You may like to consider running x_send more frequently at the main surgery. If the branch is set to phone in at night it will collect 10 'little' files rather than one large one. If noise causes a retry, only one of the 'little' files will have to be re-sent.
Checking that the transfer worked.
Run xshow from xmenu, option (b), this will show:
Cross Updating Status
===== ======== ======
No work waiting to be processed.
Queued files : 0
Last integration : Sep 7 11:25
Last Communications Attempt:
ayrdev 07/09 11:40 SUCCESSFUL
dummy 07/09 11:33 EXECDIAL
Log files needing manual editing: 0
In addition, you can use the xmenu option called 'uustatus'. When selected this will show you the current state of the remote sites. The screen will show something similar to:
Time now is 13:17 on 30 Mar 95 SYSTEM RETRY FILES LAST TRY NEXT RETRY STATUS ================================================================ bdsedin 27 Mar 22:45 27 Mar 22:45 SUCCESSFUL branch 11 30 Mar 12:17 30 Mar 12:17 WRONG TIME TO CALL
NOTE: To exit this option use the <DELETE> key.
You can ignore the SYSTEM bdsedin as this is our computer in Edinburgh. You should look first of all at the FILES column, this is the number of files waiting to be sent to that site. If this is zero then there is no work waiting to go.
The STATUS column will give you an indication of why there are queued files. Some of the messages you may see are:
You will soon get to know what these screens should look like and be able to
tell very easily if cross updating worked.
If you think there is still work on the remote machine then you should
force a call through - it does not matter if there is no work waiting.
Forcing a transfer
If uustatus shows there are files waiting to be sent you can try to
force a transfer. Normally cron will handle the retrying of the calls
but as this takes place in the background you cannot see why calls are not being
made. You should use the 'uutry' option on xmenu, this will give
you a step by step commentary of what is happening e.g:
./uucico -r1 -Sbdsl -x5 >/tmp/bdsl 2>&1&
tail -f /tmp/bdsl: press <DEL> to quit when done
fillFlds: returning
conn(bdsl)
Device Type Dirunx wanted
mlock tty001 succeeded
getto ret 5
expect: ("")
got it
sendthem (^M)
expect: (gin:)
M^J^M^Jlogin:got it
sendthem (nuucp^M)
Login Successful: System=bdsl
msg-ROK
Rmtname bdsl, Role MASTER, Ifn - 5, Loginuser - root
rmesg - 'P' got Pgetxf
wmesg 'U'g
Proto started g
TOP *** - role=1, setline - X
wmesg 'H'
rmesg - 'H' got HY
PROCESS: msg - HY
HUP:
wmesg 'H'Y
cntrl - 0
send OO 0,exit code 0
Conversation Complete: Status SUCCEEDED
If the screen finishes with 'Status SUCCEEDED' then the transfer worked correctly and any work waiting to be transferred has been. If the message'Status FAILED' appears you should look at the last few lines to determine the reason e.g.
got NO CARRIER Forked 3381 Wait got 3381 Status 107000 could not connect (no carrier) getto ret -1 Call Failed: EXECDIAL REMOTE FAILURE exit code 101 Conversation Complete: Status FAILED
In this case the call failed due to 'Execdial Remote failure'. This means for some unknown reason the REMOTE's modem answered but did not connect properly. Most of the errors are obvious and are listed in full in the Unix manuals.
If after repeated attempts you are still not sure of the problem if you:
lp /tmp/'sitename'
where sitename is the site you are trying to reach this will printout a copy of the uutry trace, you should then fax this to Edinburgh (0131 556 3525).
REMEMBER: If you force a transfer you will have to run x_check (option 2 on xmenu) to make sure the Premvet 5 software can access the file.
In the normal course of events all work entered and editing will be recorded in the log file and passed to the remote sites. If you want to make a change that does not get transferred you need to switch logging off while the changes are being made. This is done by:
Note: This is a global setting, that is this setting applies to every screen that logs in. If you switch off logging and another terminal logs in NO WORK ENTERED on that screen will be logged.When making corrections in this manner please ensure that NO SCREENS are logged in while logging is switched off. Remember to switch logging back on!
When the vet software is integrating work it creates a 'lock file'. This lock file is used to stop multiple attempts at integrating the same work. If for any reason the integration fails e.g. error message, reboot, power failure, user intervention etc. the lock file will remain. This will stop any other attempts at integration.
Before you consider removing the lock file and re-trying you should wait at least 20 minutes. It may be that there is a lot of work to be integrated which will take a while.
Before the lock is removed you will have to manually edit the integration file to avoid duplication. The integration file is processed line by line, if the integration fails you may have the situation where half the file has been processed correctly and the other half has not. If you remove the lock and re-integrate the first half then the file will be processed a second time leading to duplication.
As the file is being processed a note of the progress is made. You will need to look at how far the integration has completed. You do this by exiting the vet system and at the $ prompt type tail v6uucp.log. You can of course load this file into vi and scroll through it.
v6uucp.log is located in the Premvet 5 data directory e.g. /u/vet, /u/vetdata etc.
You should make a note of the LAST line. Next you need to look at the file UUCP.log, this file contains the work due to be integrated. You should look through here for the last line that was processed. TIP: Use the/ option in vi to search for an obvious bit of text.
See the FAQ How to Edit Log files for more details.
uulog
The command uulog lists every-time a transfer was attempted. It shows
the site name, date and time the transfer was requested and the outcome. You
have the option to display the last 20 lines on the screen or the last 50 on the
printer. Some of the outcome messages are as follows:
| 
| 
|