(of course errno=22 is EINVAL.)
Now, I've verified that with the environment the remote jlogdup process
has, it can jstat the file, LIST-DISTRIB the file and it can jshow the
subroutine for the partitioning algorithm, I've also eliminated index
corruption for the remote copy of the file by removing the remote index
entirely, but this still happens.
Does anyone have any ideas? Am I simply wrong to expect that a pair of
jlogdup processes should be able to replicate an update to a record in
a distributed file over onto a remote machine just like they can for
pretty much any other type of file?
Cheers,
Ken
PS. Great to have a functioning 'list' again!
ken,
I have seen this before (on windows).
oddly the data does get across even though you get the error 22, but as you probably know too many errors will kill jlogdup.
e.g.
jsh john ~ -->JLOGDUP
-lE:\jbasehome_3\log.txt -V input set=eldest terminate=eo
f output
set=database rename=c:,e:
13:52:48 17 MAY 2005 :
STATUS:
Begin JLOGDUP process: From set 'set=eldest
terminate=eof' to set 'set=data
base
rename=c:,e:'
Thanks for that, indeed, the key seems to be that the DISTRIB file stub
needs to be copied over to the remote machine and jbackup/jrestore
don't seem to do that very well at 3.4.4. After stopping the jlogdup
pair and rcp -p ing the stub file across, I was able to restart the
jlogdup processes and haven't had any more such messages.
Cheers,
Ken