[daip] SU FILE problem

[Roderick Johnstone]

Lorant Sjouwerman wrote:
> Robert,
> 
> OK, looks like you're using the older version.
> Things have changed considerably in AIPS and in VLARUN,
> and it seems you have not run the Midnight Job recently;
> probably the computer upgrade also may have affected this.
> 
> There must be a 'do_daily.<cpuname>' in the home directory
> of the account that installed the aips version. I strongly
> recommend it is run by that account, though it may mess up
> your personal scripts. After running the 'do_daily.<cpuname>'
> you should have the latest AIPS if you use 31DEC06 - if not
> (eg you're running 31DEC05), then I recommend upgrading to
> the newer version and once a week or month run the Midnight
> Job - it has a much more powerful version of VLARUN. After
> the Midnight Job, do 'restore 0' and 'run vlarun' (also for
> the 31DEC05 version, which gives you the VLARUN you're using).
> I used the inputs in the new VLARUN version (31DEC06) as below (only key 
> ones listed - please read the explain file)
> Good luck
> 
> 
> Regards,
> 
> Loránt Sjouwerman - Scientific Services - lsjouwerman at nrao.edu
> --------------------------------------------------------------
> c/o NRAO Array Operations Center       Phone:  +1-505-835-7332
>    P.O. Box 0 (1003 Lopezville Rd)    Switch: +1-505-835-7000
>    Socorro NM 87801                   Fax:    +1-505-835-7027

Lorant

Thanks for this hint. I ran the midnight job on our binary installation 
of 31DEC06 and we now have an aips installation that is able to reduce 
Robert's recent data fine.

However there was an error during the midnight job run which is related 
to some changes we have made to our computing systems. Can you advise on 
the following please...

In the past I have done all the aips installation on my desktop which 
used to be xpc4, so our midnight job script was called do_daily.xpc4. In 
the meantime I have a new system and the xpc4 address was reused for 
another system which is now running the x86_64 variant of the Scientific 
Linux 4.2 operating system that we are using on all our systems. Our 
64-bit systems have (most of) the 32-bit compatibility libraries 
installed so generally run 32-bit apps ok.

So I logged into xpc4 and did a ./do_daily.xpc4. It threw an error:

UPDUPDATE - running make for changed XAS.SHR
/usr/bin/ld: cannot find -lXext
collect2: ld returned 1 exit status
make: *** [xas] Error 1

so I broke out of it.

However, in the course to trying to understand what was going on I tried 
to run the midnight job on another 32-bit system (xpc21) which failed 
because the hostname was wrong.

Then I ran MAKE.MNJ on xpc21 (telling the date that I installed the 
31DEC06 version, as near as I could dtermine) to see if I could make a 
midnight job for that host (xpc21). The do_daily.xpc21 run on xpc21 
fails because something like ClientName (which was still xpc4) doesnt 
match the hostname - sorry, I can't remember the precise error message.

I then ran do_daily.xpc4 again on xpc4 and let it proceed to the end (it 
gave the same error with not being able to find -lXext, but aips seems 
to run and vlarun seems to reduce Robert's data fine.

If I do a locate libXext on xpc4, I get:
/usr/X11R6/lib64/libXext.so.6.4
/usr/X11R6/lib64/libXext.so.6
/usr/X11R6/lib64/libXext.so
/usr/X11R6/lib64/libXext.a
/usr/X11R6/lib/libXext.so.6.4
/usr/X11R6/lib/libXext.so.6

so the lib directory which contains the 32-bit versions of the libraries 
doesnt have the plain .so file without the version number. In the lib64 
directory this is a sym link to the .so with the version number. I guess 
that I could fix this by hand making the link and running do_daily.xpc4 
again.

Do I have a badly broken distribution with the -lXext error?

If I re-run do_daily.xpc4 on xpc4 after making the symlink libXext.so in 
the 32-bit directory is that a good way to fix it? I can imaging other 
problems later though.

I think that xpc4 was set as our 'master' node ages ago so I'm wondering 
whether its best to continue using xpc4 as our installation node and 
fixing up the missing sym link or whether there will be other problems 
later. Alternatively, is it better to try and make a 32-bit node the 
master or at least the node on which I can run the midnight job. If so, 
how do I accomplish this?

What role does the 'master' node play in all this.

Sorry to send such a long email but its quite a complex situation to 
discuss.

Thanks

Roderick
-- 
Roderick Johnstone                          Email: rmj at ast.cam.ac.uk
X-ray Astronomy Group                       Phone: +44 1223 766656
Institute of Astronomy                      Mobile:   07989 809095
Madingley Road, Cambridge CB3 0HA, UK       Fax:   +44 1223 337523