Cross updating - Checking that the transfer worked.
One of the ways to do this is to 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 coloumn, 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:
| WRONG TIME TO CALL | this is where the machine is setup to receive
incoming calls only or the entry in the Systems file has been set
for a specific times and is normal.
|
| CALLER SCRIPT FAILED | tells you that your machine could
not successfully login to the other system.
|
| RETRY TIME NOT REACHED | the previous conversation failed and it is to soon to attempt another. |
You will soon get to know what this screen should look like and be able to tell very easily if cross updating worked.
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/Xenix manuals.
If after repeated attempts you are still not sure of the problem if you:
- Exit xmenu
- Type lp /tmp/'sitename'
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 Premvet can access the file.
Duplicated work
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. This is done by:
- General applications
- Modules
- Cross-Updating
- Parameters
- 1. Log transactions - Change this from yes to no.
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.
Clearing a lock file
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 that has not. If you remove the lock and re-integrate the first half this the file will be processed a second time leading to duplication.
As the file is being processed a note of the progress is made. What you
need to do is look at how far the integration has got. You do this by
exiting the vet system at at the $ prompt type tail v6uucp.log. You can of
course load this file into vi and scroll through it.
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.
You next need to deleted all work PRIOR to that line, TIP: in vi use <ESC>:1,.d to delete all work from line 1 (the beginning) to the current line.
You can now remove the lock file:
rm UUCP.LCK