Tcl Source Code

View Ticket
Login
Ticket UUID: 33b31074db3689cc4bf70735f558faf3ecf1b07
Title: Having problems with a OraTcl set up
Type: Support Version: various
Submitter: gvoll Created on: 2018-01-18 19:03:53
Subsystem: 85. tclconfig Assigned To: nobody
Priority: 5 Medium Severity: Important
Status: Closed Last Modified: 2018-01-25 19:59:55
Resolution: None Closed By: sebres
    Closed on: 2018-01-25 19:59:55
Description:
I need to recreate some ORATCL commands so my scripts can interact with Oracle.  This had been working but is no longer.  
We have been trying to configure various different versions of TCL and ORATCL.  
We are having problem because the directions do not seem to match some of what we have.  
We have been able to run a configure, make, and make install but the end product seems to be missing files and when executed, it core dumps.  
We need help setting things right.  
We really need to have this working by 1/23/18.

Can you please help us with this.

Greg Voll
708-822-6600
[email protected]
User Comments: sebres added on 2018-01-25 19:59:55:
So your test-Tcl-instance seems to be correct now. 
To be sure please give still out of `info library`.

I don't know currently why oralogon still failed, but because it is rather an
error by create ORA environment (I think it is OCI_INVALID_HANDLE from OCI_EnvCreate)...
I belive in order to work using native client with Oracle on Solaris/SunOS 
you should set also correct value for ORACLE_LIBRARY env-variable.
Also please note this similar issue - https://sourceforge.net/p/oratcl/support-requests/23/

I tend to close the issue here, because it is a Tcl-repository and it has nothing to do with OraTcl.
Either you should open a ticket in https://sourceforge.net/p/oratcl.
Or try to reach me over mail or send me a direct message to my twitter.

But we are wrong here. Thus closed.

gvoll added on 2018-01-25 18:51:10:
It has gotten better but not there yet.

Setting the variables as you suggested change the patchlevel info.

The oralogon is still displaying a blank.  I included the 2 things you asked me to do before.  I display the variable settings.

What would you like me to do or try now?

gv3149@psdz0002 % pwd
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin
gv3149@psdz0002 % echo $ORACLE_LIBRARY
/usr/local/opt/oracle/product/mynah01d/lib32/libclntsh.so
gv3149@psdz0002 % echo $LD_LIBRARY_PATH
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/lib:/tcl2018/tcl8.5.19/lib:/appl/SUNWmyn/mynah/lib:/appl/SUNWmyn/mynah/locallib:/usr/openwin/lib:/appl/SUNWtel/telexel/lib:/usr/local/opt/oracle/product/mynah01d/lib32:/usr/dt/lib:/usr/ccs/lib:/usr/lib:/usr/ucblib:/opt/hpnpl/lib:/usr/dt/lib
gv3149@psdz0002 % echo $TCL_LIBRARY
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/library
gv3149@psdz0002 % ./tclsh8.5
% info patchlevel
8.5.19
% package require Oratcl
4.5
% catch {oralogon autotn/pant04sl@mynah01d}
1
% puts "$::errorCode : $::errorInfo"
NONE :
    while executing
"oralogon autotn/pant04sl@mynah01d"
% proc test_fcb {args} {::puts "test_fcb: $args"}
% oralogon autotn/pants04sl@mynah01d -failovercallback test_fcb

% exit

sebres added on 2018-01-25 08:04:08:
As I can see, the new "installed" tcl-path (to tcl85.so, somewhere in your prefix
tcl2018/...) is NOT in your LD_LIBRARY_PATH (resp. after another path pointing to old tcl85.so).
As already said, in this case new ./tclsh8.5 loads just old library (finding via LD_LIBRARY_PATH).
Additionally please note, that in your case (you've another, system-wide installed tcl8.5), 
you should put your new path BEFORE path pointing to another library tcl85.so, like:

LD_LIBRARY_PATH="$a/tcl2018/tcl8.5.19/lib:$LD_LIBRARY_PATH" ./tclsh

As regards the "TCL_LIBRARY looks wrong" this will be probably an after-effect of this.
But if after update of LD_LIBRARY_PATH, your `info patchlevel` will put correct version (8.5.19),
but `info library` still returns wrong path, you can override it in your env before you start tclsh. 
It should point to new path with init.tcl (I assume .../tcl2018/tcl8.5.19/library):

LD_LIBRARY_PATH="$a/tcl2018/tcl8.5.19/lib:$LD_LIBRARY_PATH";
TCL_LIBRARY="$a/tcl2018/tcl8.5.19/library";
./tclsh

gvoll added on 2018-01-24 22:31:53:
Could you give me what these key environmental variables are and something to check for in the directory that each should be set to?

gvoll added on 2018-01-24 00:00:17:
Let me pass along some info

Here is where I have the files related to this.  We obviously had some old files from when this was working before and we have files from our previous attempts at get it going again.

 /appl/SUNWmyn/mynah/locallib/tcl2018
gv3149@psdz0002 % ls -l
total 6
drwxrwxr-x   9 madmin   mynah       1024 Jan 23 13:17 oratcl
drwxrwxr-x  13 madmin   mynah       1024 Jan 23 12:33 sfw
drwxrwxr-x  16 madmin   mynah       1024 Jan 23 12:51 tcl8.5.19

When I did the 2 configures (tcl and oratcl) what should have the commands looked like give the directories above?

This is what I did:
TCL
  a=/appl/SUNWmyn/mynah/locallib
  cd $a/tcl2018
cd tcl8.5.19/unix
./configure –prefix=$a/tcl2018/tcl8.5.19

ORATCL
   b=$a/tcl2018/tcl8.5.19
   cd $a/tcl2018/oratcl
   ./configure --prefix=$b  --exec-prefix=$b


You mentioned some env variables.  Here they are:  

/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin> echo $LD_LIBRARY_PATH
/appl/SUNWmyn/mynah/lib:/appl/SUNWmyn/mynah/locallib:/usr/openwin/lib:/appl/SUNWtel/telexel/lib:/usr/local/opt/oracle/product/mynah01d/lib32:/usr/dt/lib:/usr/ccs/lib:/usr/lib:/usr/ucblib:/opt/hpnpl/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ccs/lib:/usr/lib:/usr/ucblib:/opt/hpnpl/lib:/usr/dt/lib
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin> echo $TCL_LIBRARY
/appl/SUNWmyn/mynah/lib/tcl
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin>
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin>
/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin> ./tclsh8.5
% info library
/appl/SUNWmyn/mynah/lib/tcl8.5
%

That TCL_LIBRARY looks wrong.  Those are some older attempts.

I did a find for pkgIndex.tcl 

/appl/SUNWmyn/mynah/locallib/tcl2018
gv3149@psdz0002 % find . -name "pkgIndex.tcl" -print
./oratcl/pkgIndex.tcl
./tcl8.5.19/library/tcltest/pkgIndex.tcl
./tcl8.5.19/library/http1.0/pkgIndex.tcl
./tcl8.5.19/library/http/pkgIndex.tcl
./tcl8.5.19/library/msgcat/pkgIndex.tcl
./tcl8.5.19/library/opt/pkgIndex.tcl
./tcl8.5.19/library/platform/pkgIndex.tcl
./tcl8.5.19/library/dde/pkgIndex.tcl
./tcl8.5.19/library/reg/pkgIndex.tcl
./tcl8.5.19/lib/tcl8.5/opt0.4/pkgIndex.tcl
./tcl8.5.19/lib/tcl8.5/http1.0/pkgIndex.tcl
./tcl8.5.19/lib/Oratcl4.5/pkgIndex.tcl
./sfw/lib/tcl8.3/tcltest1.0/pkgIndex.tcl
./sfw/lib/tcl8.3/opt0.4/pkgIndex.tcl
./sfw/lib/tcl8.3/msgcat1.1/pkgIndex.tcl
./sfw/lib/tcl8.3/http2.3/pkgIndex.tcl
./sfw/lib/tcl8.3/http1.0/pkgIndex.tcl
./sfw/lib/Oratcl4.4/pkgIndex.tcl

Those ones in the sfw directory are old.

sebres added on 2018-01-23 23:17:21:
I cannot write you a direct message on your twitter (and not so good via public twits), so here again...

So I assume it's still something wrong with you "installation".

Perhaps, it can run the correct executable, but I assume that, it just loads 
wrong tcl85.so-library (e. g. in my case this controls LD_LIBRARY_PATH env-variable) 
and/or the wrong tcl-library, where files "init.tcl", package-index "pkgIndex.tcl", etc are placed 
(for example this controls TCL_LIBRARY env-variable, resp. if not set it will 
be found corresponding used tcl85.so).

The path of current tcl-library used in your tclsh, you can find with `info library`.

Note, that your oratcl-package should be installed also in this directory (or some 
other from the list, that you can output with `join $::auto_path \n`).

gvoll added on 2018-01-23 22:43:00:
From your 20:49 note - the failovercallback

/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin> ./tclsh8.5
% package require Oratcl
4.5
% proc test_fcb {args} {::puts "test_fcb: $args"}
% oralogon autotn/pants04sl@mynah01d -failovercallback test_fcb

%

gvoll added on 2018-01-23 22:40:02:
From your 20:49 note

/appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin> ./tclsh8.5
% package require Oratcl
4.5
% catch {oralogon autotn/pant04sl@mynah01d}
1
% puts "$::errorCode : $::errorInfo"
NONE :
    while executing
"oralogon autotn/pant04sl@mynah01d"
%

gvoll added on 2018-01-23 22:34:38:
I have not used twitter much but I it - it is Vollgreg.

From your 20:57 note
I was wondering about the 8.5.6 vs 8.5.19

After the Configure for both TCL and OraTcl, I did the make and make install
 
Before I did this
/data/files/ORACLE> tclsh8.5
I had added the directory where the tclsh8.5 was residing.

From your 20:49 note
1) yes

2) I will try to do this and report back

3) I will try this also

This is where I was working with things:
/appl/SUNWmyn/mynah/locallib/tcl2018> ls -l
total 6
drwxrwxr-x   9 madmin   mynah       1024 Jan 23 13:17 oratcl
drwxrwxr-x  13 madmin   mynah       1024 Jan 23 12:33 sfw
drwxrwxr-x  16 madmin   mynah       1024 Jan 23 12:51 tcl8.5.19

/appl/SUNWmyn/mynah/locallib/tcl2018> find . -name "tclsh*" -print
./tcl8.5.19/doc/tclsh.1
./tcl8.5.19/unix/tclsh
./tcl8.5.19/win/tclsh.ico
./tcl8.5.19/win/tclsh.rc
./tcl8.5.19/win/tclsh.exe.manifest.in
./tcl8.5.19/bin/tclsh8.5
./tcl8.5.19/man/man1/tclsh.1
./sfw/bin/tclsh8.3
./sfw/man/man1/tclsh.1
./sfw/share/man/man1/tclsh.1


I have put the /appl/SUNWmyn/mynah/locallib/tcl2018/tcl8.5.19/bin in my PATCH, so I could get to the tclsh8.5

sebres added on 2018-01-23 21:01:19:
Can you give me your twitter (and allow direct messaging there) in order to communicate faster? (it is gregvoll?)

sebres added on 2018-01-23 20:57:55:
Stop.

You've downloaded/built tcl8.5.19, but you got `8.5.6` if you call `info patchlevel`.

Have you executed `make install` after `make`?

Or if you don't want to install it, are you sure you call correct tcl binary.
Note if you call it 
  /data/files/ORACLE> tclsh8.5
you'll start installed tcl (first from your path).

Instead of, you should then call something like:
  /test/my/uninstalled/tcl-test/unix> LD_LIBRARY_PATH=. ./tclsh8.5

sebres added on 2018-01-23 20:49:18:
1. So you've no segfault/core-dumps anymore?

2. Corresponding the source code I can imagine only few situations where it returns nothing, in any error case it calls internally `Oratcl_Checkerr`, that will set error-message retrieved from OCI to the calling interpreter.
Only in case of error codes OCI_INVALID_HANDLE, OCI_CONTINUE (and OCI_SUCCESS) it does nothing.

The case of OCI_INVALID_HANDLE may occur here if you'll not be able to create ora-enironment at all (OCI_EnvCreate failed).

So please do `puts "$::errorCode : $::errorInfo"` after failed oralogon, 
to be sure you've really an error case.
Resp. just constrol which integer will return
`catch {oralogon autotn/pant04sl@mynah01d}`.

3. But you could also try to call it with `-failovercallback` parameter:
```
proc test_fcb {args} {::puts "test_fcb: $args"}

oralogon autotn/pant04sl@mynah01d -failovercallback test_fcb
```

gvoll added on 2018-01-23 20:09:10:
So, I moved the tcl8.5.19 and the oratcl4.5 that I had on my PC via FTP to the unix box.  I unzip and untar the files.  In the tcl dir, I saw the unix directory.

I did the configure for the tcl8.5.19 and the oratcl4.5.
I only did the 32 bit version.

I was able to get the tclsh8.5 to give its patchlevel - 8.5.6

But when I try to have it do the oralogon, I get nothing back.

/data/files/ORACLE> tclsh8.5
% package require Oratcl
4.5
% oralogon autotn/pant04sl@mynah01d

% info patchlevel
8.5.6

The ORACLE_HOME and ORACLE_LIBRARY were set
/data/files/ORACLE> echo $ORACLE_HOME
/usr/local/opt/oracle/product/mynah01d
/data/files/ORACLE> echo $ORACLE_LIBRARY
/usr/local/opt/oracle/product/mynah01d/lib32/libclntsh.so

So, what might be my problem?

gvoll added on 2018-01-22 20:41:57:
I see the unix directory when you pointed me to it on your website.

Did I download tcl8.5 from the wrong places?  Or did I download the wrong thing?

Someone else on my team downloaded this version of tcl8.5.  Maybe it is bad?

I am not able to download directly to this unix machine.  
Last week, I downloaded two files but I have not FTP=d them to the unix machine yet.

I have tcl8.5.19-src.tar.gz (4,446 KB) and tk8.5.19-src.tar.gz (4,020 KB).

Should I FTP them to my unix machine or should I get a different version?

sebres added on 2018-01-22 17:36:42:

> I had a problem with the "cd tcl8.5/unix". Here is an "ls -l" of my tcl8.5 dir

"cd tcl8.5/unix" meants "cd root_of_downloaded_tcl8.5/unix"...

So if you take a look here, you'll see the [unix]-directory as expected:


gvoll added on 2018-01-22 16:50:18:
Thank you for your comments.  Already it has helped a great deal.  However, I would like to restore our ability to use the Oratcl.

Let me reply to a few things you said.

I mentioned I was away from this project for a while.  I had for got about having the Oratcl until after the Oracle patch had been applied.  My thoughts were that the patch was not the problem but since we had not tested this before the patch, I was not sure.  I was away for several years so it could have gone bad any time while I was away.

In your summary:
1. our "new-ish" version is causing segfaults.  This is the ORATCL we have tried to create since the patch.

2. I have no idea if there was some modification.  

3. This is the key - we want to restore or create a new Oratcl version but we are having troubles.  


So, based on what you have written, I think our best path forward is to create a new version based on tcl8.5 and Oratcl4.5.

My idea was to put these in a directory by themselves.  One subdir for 8.5 and one for oratcl 4.5

I had also made a copy of a directory called /usr/sfw in this new directory.
The orig version had the gcc compiler and had the tclsh8.3 and the tclConfig.sh in it.  The tcl files all are owned by root and I have to include another party if we need to manipulate "root" files.

This is what I was working on just before I opened this ticket.

I had a problem with the "cd tcl8.5/unix".  Here is an "ls -l" of my tcl8.5 dir

gv3149@psdz0002 % cd tcl8.5
gv3149@psdz0002 % ls -l
total 254
drwxr-xr-x   2 madmin   mynah       2048 Jan 18 12:02 encoding
-rw-r--r--   1 madmin   mynah       9032 Jan 18 12:02 history.tcl
drwxr-xr-x   2 madmin   mynah         96 Jan 18 12:02 http1.0
-rw-r--r--   1 madmin   mynah      25033 Jan 18 12:02 init.tcl
-rw-r--r--   1 madmin   mynah       2856 Jan 18 12:02 ldAix
drwxr-xr-x   2 madmin   mynah       3072 Jan 18 12:02 msgs
drwxr-xr-x   2 madmin   mynah         96 Jan 18 12:02 opt0.4
-rw-r--r--   1 madmin   mynah      23643 Jan 18 12:02 package.tcl
-rw-r--r--   1 madmin   mynah        869 Jan 18 12:02 parray.tcl
-rw-r--r--   1 madmin   mynah      30552 Jan 18 12:02 safe.tcl
drwxr-xr-x   6 madmin   mynah       1024 Jan 18 12:02 tcl8.5
-rw-r--r--   1 madmin   mynah       4721 Jan 18 12:02 tclAppInit.c
-rw-r--r--   1 madmin   mynah       6379 Jan 18 12:02 tclIndex
-rw-r--r--   1 madmin   mynah      11432 Jan 18 12:02 tm.tcl
-rw-r--r--   1 madmin   mynah       4724 Jan 18 12:02 word.tcl


I don't have a unix sub-dir.

So, I guess I will try to download this again.

sebres added on 2018-01-22 08:31:28:
As you said "I need to recreate some ORATCL commands ...", I assumed that you've changed somewhat in the code-base of oratcl, therefore I asked for diff.

But now I don't understand how just the applying of some patch on oracle (server? or client?) causes segfault on connect by tcl. But 8.3 is too old (and this can

So I'll try to summarize:
1. your old version causes segfault (after Oracle was patched);
2. you've no own modifications in code, neither on tcl, nor oratcl;
3. you want to test it with newer tcl-version, but you've troubles to configure new version on SunOS.


As regards the build of the tcl8.5 on SunOS...

> I do not see that executable in the directory that I have been asked to cd to

But the "configure" script belongs to "tcl8.5/unix" directory!

So, what you'll get, if you execute following in shell:
```
cd tcl8.5/unix
./configure

```
If executable flag does not set for the "configure" file, you can set it or just use `sh ./configure`.

gvoll added on 2018-01-19 23:13:21:
I will try adding my reply here.

> 	I need to get this corrected but can I please ask you a few questions about a situation that we are in.
> 
> 	I used to work with this project years ago and recently came back to work on it again.
> 	We do a lot of automation projects using a product that was created by Telcordia called MYNAH.
> 	It uses TCL as its scripting language.
> 
> 	We have one major automation process that is written in TCL which uses ORATCL to connect to our only set of Oracle tables.
> 
> 	Last year, our DBA team needed to do a patch (I am not sure what it was for) on Oracle, on our test system.
> 	They did the work.  We tested getting access and a few updates via SQL PLUS.
> 	
> 	I had forgotten we had this ORATCL situation.  We did not test it before the patch work.
> 	When we tested it after the patch work - it was not working.
> 	Since I was way from the project for years, I only know it worked years ago.
> 	Our test system does not get a lot of work and was not in best of shape when I came back.
> 
> 	Since our ORATCL tests failed on the test system, we were not rushing into having the Oracle patch work done on our production system.
> 	We have limped along trying to figure out the ORATCL problem but we have not gotten too far until the last month or so.
> 
> 	Ideally, we would like to have the ORATCL problem fixed so we can do test on our test system and then OK Oracle work on our production system.
> 	But there is a hot Oracle secure patch that needs to be installed VERY soon on our production system.  That is why I said we needed to have this resolved by 1/23.
> 	
> 	The ORATCL process is working on our production system right now.  From my recent work with this it appears to be TCL8.5 and ORATCL4.5 and we have Oracle 11.2 on both test and production.
> 
> 	Our concern is that the Oracle Patch work will cause our production routine to stop working because the ORATCL will no longer work.
> 	Is it likely that this will happen?
> 
> 
> 	Now let me try to answer your questions.
> 
> 	C-code modifications -- I do not know when the Oratcl on the test system stopped working.  When I was last working with the project, it had been working.  But like I said, it has been years.  
> 	We do not code in C.  The scripting we do is with TCL.
> 	The release level of the MYNAH product had not changed  while I was away from the project.
> 
> 	On the test system, it appeared that the tcl/oratcl combination was tcl8.3 and oratcl4.4.
> 	I see tcl8.3 info in old directories.  And it have an owner of "root".  
> 	I tried using the old tclConfig.sh with a new Oratcl4.4  but that has not worked.
> 	When I say it has not worked, I was able to do the Oratcl configure, make, and make install.  I had trouble testing it as per the instructions.  But when I run one of my routines, I get the process to load the libOratcl4.4.so file but when the routine tries to do the oralogon, it coredumps.
> 
> 	I tried putting tcl8.5 and oractl4.5 in a new directory and to work with these but when I try one of the first steps in the instructions (the configure of the tcl), I do not see that executable in the directory that I have been asked to cd to.
> 
> 	Platform -- is this what you are looking for?
> SunOS psdz0002 5.10 Generic_150400-55 sun4u sparc SUNW,Sun-Fire-15000
> 
> 	Since we have not made modifications - or I am not following your question - I don't have a diff.
> 
> 	Could the modifications you speak of, be in the Oracle 32 byte library?  And if so this would be our concern.
> 
> 	I am available to work on when you are available.  I do not know if you want to talk.  Or if you work over the weekend.
>

gvoll added on 2018-01-19 23:10:46:
I don't see how I am supposed to be able to reply to the questions asked.

sebres added on 2018-01-19 12:10:44:
> I need to recreate some ORATCL commands ...

I assume that was modifications in C-code?

I could help you if you can tell which version's both (tcl/tclora) are affected (and which platform). 
And if you'll show me the modifications you've made there (a diff would be enough).

Still better would be to see additionally a call-stack on the segfault.

> end product seems to be missing files and when executed, it core dumps

I doubt that missing files (libraries?) causes such kind of errors. 
Possibly your modifications do this (e. g. imcompatible changes, or similar).