[daip] MNJ on second architecture

[Patrick P. Murphy]

On Tue, 19 Dec 2000 12:18:13 +0000 (GMT), Martin Hardcastle
   <M.Hardcastle at bristol.ac.uk> said: 

MH> I have a slight problem which you may be able to help with. Here at
MH> Bristol we are running both SUL and LINUX installations of AIPS. We
MH> have a MNJ running on a SUL system (sol.star.bris.ac.uk) which is now
MH> working again after all the version changes, and so we have an
MH> up-to-date source tree. We would like to regularly compile it for the
MH> LINUX systems as well. (I guess we could just coerce INSTEP2 and
MH> INSTEP4 into doing a mass compile by hand occasionally, but that seems
MH> like overkill.) I tried setting up a MNJ on one of the LINUX systems,
MH> cetus.star.bris.ac.uk, but at the moment it fails like this:

MH> [aipsmgr at CETUS UPDATE]$ /export/home/aipsmgr/do_daily.cetus
MH> UPDCONFIG - using SYSLOCAL configuration
MH> AIPSUPD - RunTime is 20001219
MH> AIPSUPD - LogFile is UPD20001219.LOG
MH> AIPSUPD - ErrorFile is UPD20001219.ERR
MH> AIPSUPD - cd /mnt/disk6/soft2/aips/31DEC01/LINUX/UPDATE
MH> AIPSUPD - Using the SECURE SHELL for copying files.
MH> AIPSUPD - calling UPDCONTROL
MH> UPDCONTROL - Checking cross-version file
MH> UPDCONTROL - TST is indeed 31DEC01
MH> UPDCONTROL - Creating LASTGOOD.DAT.mnj.cv.nrao.edu
MH> UPDCONTROL - Getting the 5 update files
MH> UPDCONTROL - getting /home/aips1/master/TST/UPDATE/COMRPL.UPD -> COMRPL.UPD
MH> UPDCONTROL - COMRPL.UPD checksum mismatch
MH> UPDCONTROL - 00000, 58914

These two numbers clearly don't match.  Currently 58914 is indeed the
correct checksum on the file and in the COMRPL.UPD.SUM, but the output of
"sum COMRPL.UPD | awk '{print $1}'" on the file your system copied is a
big zero; this suggests to me it may be empty (yup, you say it is further
down).  Furthermore, our log file shows what seem like successful copies:

Tue Dec 19  7:02:21 US/Eastern 2000: cetus.star.bris.ac.uk <- /home/aips1/master/TST/UPDATE/COMRPL.UPD COPIED
Tue Dec 19  7:02:35 US/Eastern 2000: cetus.star.bris.ac.uk <- /home/aips1/master/TST/UPDATE/COMRPL.UPD.SUM COPIED

Is it at all possible there's a disk space problem on your disk?  That
would *possibly* explain a zero length file.  But I'd expect the .SUM
copy to fail then too.

MH> and COMRPL.UPD has zero length. I wonder if this means that cetus is
MH> not authorized to do the copying? 

No, it looks like it has a perfectly good secure shell "mnj" key.  The
messages in our log file would indicate an error immediately otherwise.

MH> Anyway, assuming that can be fixed, my next question is; what happens
MH> when we run this? Will it try to download all the files for the day's
MH> update (which the SUL job will already have done)?

Depending on the LAST*.DAT files, and specifically the LASTCOPY.DAT, yes
it would duplicate the copy step.  Unless you have it set in your
$SYSLOCAL/UPDCONFIG file so that "UpdDoCopy" and "UpdDoRemove" are both
set to NO; then it will skip the copying and remove stages, and just do
the COMRPL/COMLNK.  This is not as clean as Eric's suggestion of setting
up a client MNJ, but it's probably a good compromise.

If you would prefer to run the MNJ on cetus as a complete client of the
master, the settings I'd recommend are:

      ClientName=cetus
      ServerName=sol
      MasterName=sol
      MasterRoot=/see/below/for/details
      ServerRoot=$MasterRoot
      UpdDoRemove=NO
      UpdDoCopy=NO
      UpdClient=YES
      MasterArch=SOL
      UpdDoNFS=YES
      UpdSSH=NO

However, I noted a possible inconsistency:

> [aipsmgr at CETUS UPDATE]$ /export/home/aipsmgr/do_daily.cetus
> AIPSUPD - cd /mnt/disk6/soft2/aips/31DEC01/LINUX/UPDATE

so it's not clear to me that these two systems are in fact sharing (unless
you're doing my trick of symlinking the LINUX areas to another physical
disk that happens to be local to the linux system?).  In any event,
MasterRoot should be the sol system's AIPS_ROOT area *as seen from the
Linux client*, and ServerRoot should be identical to it.  This is so that
the Linux MNJ can snarf the transaction files via NFS from your master
system (sol).

Hope this helps.

				- Pat