Hello

We have just upgraded from Unidata 4 to Unidata 6.1 and opted not to
recompile our unibasic programs. Everything is working fine.

However, we are now in the process of tidying up and have found a few BP
files in data accounts that we would prefer are held in a separate account
with the other source/object files. The programs are cataloged directly
with the object and source in the same file.

My question is Can we just create a new BP DIR in the other account and
just use Unidata COPY to copy the object and source files into it?

Are we better to just copy the source and recompile?

Cheers
Tim

Tim wrote:
I would imagine so.

I would recommend that... if you have a compile issue, it's
better to find out sooner than later. I'd save the old "_]"
(compiled) item, first.

--
frosty

Yuor pointers might get out of whack if you dont recompule and recatalog
under the new BP directory.


What I would do is Create the new BP file copy the source recompile and
recatalog then you are clean.

as a caveat keep the old BP file for at least 6 months.

good luck,

Theo

"Tim" <atla13 (AT) hotmail (DOT) co.uk> wrote

"vvg" <vvgstation11 (AT) violetvortex (DOT) com> wrote in
news:ZOehf.117304$Hs.9247 (AT) tornado (DOT) ohiordc.rr.com:

We have been running under unidata 6.1 for about 4 weeks now and the
fact that everthing is working OK we are a bit concerned about
recompiling at this stage.

If we do recompile will the fact that the majority of our other programs
havn't been recompiled cause any problems?

If we did copy both the source and object to the new BP DIR could we not
use unidata PATHSUB to amend the pointers in the data accounts?

Tim

Tim wrote:

Your problem with recompiling could be that although UniData make sure of
object code compatibility through upgrades, new keywords in BASIC could mean
that some programs wouldn't compile and then I think the old object would be
gone and calls to it would fail until you fixed the source problem and
successfully compiled.

If the programs are CATALOGed DIRECT then moving the object will mean that
VOC pointers will be wrong, and again calls will fall over. So, if you move
the code and object (which you can certainly do with ECL COPY, but I'd
probably do at the OS level since it'll be faster and you don't have to
worry your brain about the fact that the object is binary) you will need to
either reCATALOG the object once you've moved it or modify the VOC entries
with PATHSUB as you suggest.

At some point, I'd look hard at copying your source elsewhere and doing test
compiles to see if you have everything you need - includes etc, because sure
as eggs is eggs, there'll come a point where you need to be able to
recompile and it's always better to work this stuff out when it doesn't
matter...

As always, any queries regarding UniData are far better addressed to the U2
specific mailing list u2-users which you can get to from u2ug.org

Cheers,

Ken

Thanks Ken.

I think I will take your advice and copy the DIRs at UNIX level instead of
the ECL COPY.

Out of interest do you think the ECL copy could potentially cause problems
when copying object code?

Thanks also to Frosty and Theo for your replies.

Tim