can I have two different active perl modules for the same thing?

[Steve Post]

Pardon this question if it is inane or insane.

I have perl 5.6 and sybperl version 13 and hpux11.0 on an hp9000.
The versions don't really matter.

The perl interface to sybase was built a while ago. Perl cleaning hooks into the database with sybperl.

But I want a to put in a newer sybase client on this unix box. If I do, the location of $SYBASE will move. This will screw up perl's sybase interface. I've already tried it. I change $SYBASE to a new spot, stuff dies.

If I rebuild everything, I'll bet it will work. But that seems wrong. I would rather have TWO interfaces: sybperl oldway and sybperl newway.

So my question is, can I have TWO perl sybperl interface modules?
Let me be more generic.....

Can there be two different versions of the SAME perl module in one perl? I would like to use a new perl module for the new sybase OCS, without hurting the existing setup. Is this too much to ask?

Now I figure someone on Earth has needed to change a location of a database from directory X to directory Y. When they do this, I would not expect you have to rebuild perl and all modules completely from scratch.

Steve

[Steve Post]

A guess on my part would be to start to reinstall sybperl, but modify the name of the module to something different before the make and make install. The files to change? The lines to modify? Oh I guess I root around like a blind guy with a Rubiks Cube. Or instead of taking 23,341 guesses, I could ask.

[harry d brown jr]

You have multiple version of perl (and multiple copies) but you can't have the same module installed twice within perl.

You could have two perl 5.6's installed, each with different sybase perl modules (the old in one, and the new in another). Each perl would have a separate execution path.

live free or die
harry d brown jr

[Steve Post]

Ok. That makes sense.

But it seems a little more than lame that I have to knock myself out to have SYBASE=/spot/sybase and SYBASE_OCS=/spot/sybase/OCS_12_0. Why have the variables at all if changing their values causes the perl module to fail? If it's hardwired in the box, why does it need SYBASE and SYBASE_OCS set? I see this scenario applies to Oracle as well (oracle and opensource nutshell book on my shelf).

I guess it's a HARDwired Variable that can never change. Yet must be set. Perhaps it is not that big of a deal because it's easy to reinstall a module?

If I just reinstall the module with new environment "variables" hardwired to a new fixed value, do I also need to reinstall other modules?

Ah there's the question: Are perl modules independent of each other?

[Steve Post]

I can see a reason why variables would have to be set ahead of time, even it the values are hard wired into the perl module. Perl doesn't need them, but the database it is talking to expects them. It's just a guess. But it a valid enough possiblity to prompt me to NOT call it lame anymore.

If I copy a working copy of sybase ocs to another spot and update the variables, the sybperl.pl test script DOES work.

I also found the errors I have seen are from SYBASE isql, perl is just reporting them.

Thanks for your suggestion about a second copy of perl. That's what I'll try next. I'm going to close this thread soon.

Steve

[H.Merijn Brand (procura · Accepted solution]

The answer from a perl point of view is to use a location *outside* the perl module tree and set $PERL5LIB to point to where it can find the modules

I have about 6 different DBD-Unify environments for 4 different perl builds and they all work nicely together

If you have the perl tree in /opt/perl/lib, perl already splits up for different versions of perl, so for 5.8.6 you will see /opt/perl/lib/5.8.6 and /opt/perl/lib/site_perl/5.8.6 and so on for each version

Now if you have a different location for your database modules DBI should still reside in the default tree, because it's shared with all DBD's and is not DB version dependant), use something like /appl/sybase/v20/lib/perl/5.8.6 for perl-5.8.6 modules for sybase version 2.0, and then set $PERL5LIB to point to it:

lep a5:/pro/tu/lep/4gl 101 > echo $PERL5LIB
/pro/asql/v82BC/lib/perl
lep a5:/pro/tu/lep/4gl 102 > l !$
l $PERL5LIB
./ ../ 5.6.1/ 5.8.0/ 5.8.3/ 5.8.5/ 5.9.2/
lep a5:/pro/tu/lep/4gl 103 > l $PERL5LIB/*
/pro/asql/v82BC/lib/perl/5.6.1:
./ ../ DBD/ PA-RISC2.0/ auto/

/pro/asql/v82BC/lib/perl/5.8.0:
./ ../ DBD/ PA-RISC2.0/ auto/

/pro/asql/v82BC/lib/perl/5.8.3:
./ ../ DBD/ PA-RISC2.0/ auto/

/pro/asql/v82BC/lib/perl/5.8.5:
./ ../ DBD/ PA-RISC2.0/ auto/

/pro/asql/v82BC/lib/perl/5.9.2:
./ ../ DBD/ PA-RISC2.0/ auto/
lep a5:/pro/tu/lep/4gl 104 >

Now you can run several versions of perl combined with several versions of (the) database(s). I do the same for Oracle and Progres

Enjoy, Have FUN! H.Merijn

[Steve Post]

I reopened this thread H.Merijn so I can get a clearer understanding of what you said. I'm wondering exactly HOW you installed the modified modules.

You have a database at /disk1/mydb.
You have perl at /opt/perl.
You created an empty /disk1/ALT/lib/perl/5.8.6 directory?

Then you set
PERL5LIB=/disk1/ALT/lib/perl/5.8.6?

Then you install the sybperl module?

And after it installs, it puts the files into /disk1/ALT/lib/perl/5.8.6 instead of /opt/perl/lib/5.8.1?

Now to USE the different modules....
To use normal perl, PERL5LIB remains unset.
To use perl with the new sybperl and new sybase, PERL5LIB needs to be preset to /disk1/ALT/lib/perl/5.8.6?

The module I am talking about?
use Sybase::CTlib;

[H.Merijn Brand (procura]

I understand your problem. I've written my own install script for DBD modules.

I have attached the DBD-Unify and the DBD-Oracle version
Shouldn't be too hard to modify

Enjoy, Have FUN! H.Merijn

[Steve Post]

I'm lost. Your scripts just look like they doing this.....

cd /spotONE
find SOMEDIRECTORY -print | cpio -pdumvc /spotTWO.

I don't see words like: make or make install.
I don't see the current working directory, or the value of $UNIFY.
I expect this is just because you're used to your code, and I'm not.

I also don't see anything like a path where /spotTWO would take precendent of /spotONE.

steve

[H.Merijn Brand (procura]

this is what I do *instead of* make install

what it does is copy all the stuff that 'make install' would have installed to the alternate route instead of in the default perl tree. indeed it's about the cpio you gave, but it tries to be a bit smarter, in that it knows about the perl version

easier *might* be to start a bit different:

# perl Makefile.PL PREFIX=/your/alternate/location

But knowing how MakeMaker works, I somehow never trust that :/

Enjoy, Have FUN! H.Merijn

[Steve Post]

Ah ok. Your script makes more sense for installation.
But onto using it....
How would I use have alternate location take precedent over the existing standard?

Using: /my/alt/location

The libraries are at.. /my/alt/location/perl/lib?
I set PERL5LIB=/my/alt/location, or /my/alt/location/perl/lib?
Then run myscript.pl?

[H.Merijn Brand (procura]

in that script (take DBD-Unify as example) a lot of $ENV{UNIFY}, which is where I have the lib files of Unify

/pro/asql/v82AC/lib/perl/5.8.6

$ENV{UNIFY} = "/pro/asql/v82AC/lib";

there the scripts creates (if not already there) the subdirectory perl and continues

So for /my/alt/location, there is no "lib" in the path, but you should be pretty safe with starting to set

# env UNIFY=/my/alt/location perl installu.pl

which should create /my/alt/location/perl and all which belongs there

# export PERL5LIB=/my/alt/location/perl

would complete your quest

Enjoy, Have FUN! H.Merijn

[Steve Post]

so to run "use_unify82ac.pl"
first I: export PERL5LIB=/my/alt/location/perl
then I: ./use_unify82.ac.pl
Right?

[H.Merijn Brand (procura]

Yes.

(might be the shortest possible answer I ever gave :) )

Enjoy, Have FUN! H.Merijn

[Steve Post]

ah it figures. when all is said and done, I just found official documentation on this. (ok. it's a nutshell book).

Perl Cookbook, section 12.7 Keeping You Own Module Directory. Page 413.

It repeats what you told me.

steve.