$ strace -o strace.log isql -v prod1 user password
usage: [ mid sid level] ...
So, that didn't get us what we wanted. The man page:
NAME
strace - write STREAMS event trace messages to standard output
SYNOPSIS
strace [ mod sub pri ] ...
DESCRIPTION
strace gets STREAMS event trace messages from STREAMS drivers and
modules via the STREAMS log driver (strlog(7)), and writes these
messages to standard output. By default, strace without arguments
writes all STREAMS trace messages from all drivers and modules.
strace with command-line arguments limits the trace messages received.
The arguments, which must be specified in groups of three, are:
mod Specifies the STREAMS module identification number from the
streamtab entry.
sub Specifies a subidentification number (often corresponding to
a minor device).
pri Specifies a tracing priority level. strace gets messages of
a level equal to or less than the value specified by pri.
Only positive integer values are allowed.
The value all can be used for any argument in the strace command line
to indicate that there are no restrictions for that argument.
Multiple sets of the three arguments can be specified to obtain the
messages from more than one driver or module.
Only one strace process can open the STREAMS log driver at a time.
When strace is invoked, the log driver compares the sets of command
line arguments with actual trace messages, returning only messages
that satisfy the specified criteria.
STREAMS event trace messages have the following format:
seq time tick pri ind mod sub text
Components are interpreted as follows:
seq Trace event sequence number.
time Time the message was sent expressed in hh:mm:ss.
tick Time the message was sent expressed in machine ticks since
the last boot.
Hewlett-Packard Company - 1 - HP-UX Release 11i: November 2000
strace(1M) strace(1M)
pri Tracing priority level as defined by the STREAMS driver or
module that originates the messages.
ind Can be any combination of the following three message
indicators:
E The message has also been saved in the error log.
F The message signaled a fatal error.
N The message has also been mailed to the system
administrator.
mod Module identification number of the trace message source.
sub Subidentification number of the trace message source.
text Trace message text.
strace runs until terminated by the user.
EXAMPLES
Display all trace messages received from the driver or module
identified by mod 28:
strace 28 all all
Display trace messages of any tracing priority level from the driver
or module identified by mod 28 and its minor devices identified by the
sub 2, 3, or 4:
strace 28 2 all 28 3 all 28 4 all
Display the trace messages from the same driver or module and subs but
limit the priority levels to 0 for subs 2 and 3; 1 for sub 4, driver
or module 28:
strace 28 2 0 28 3 0 28 4 1
WARNINGS
Running strace with several sets of arguments can impair STREAMS
performance, particularly for those modules and drivers that are
sending the messages.
Also be aware that strace may not be able to handle a large number of
messages. If drivers and modules return messages to strace too
quickly, some may be lost.
FILES
/usr/lib/nls/msg/C/strace.cat NLS catalog for
strace.
suggests we need a module identification number, which might be obtained
from streamtab, but I haven't been able to find streamtab.
On Wed, Jun 26, 2013 at 2:42 PM, Martin J. Evans <boh...@ntlworld.com>wrote:
> On 26/06/2013 20:25, Dan Bent wrote:
>
>> Everything is on one box.
>> Liant was a small development company out of Austin, TX that created a
>> product called "Relativity", which allows C-ISAM files to be manipulated
>> as if they were a relational database. The developer of our primary
>> business application (developed in COBOL) used Relativity as a
>> reporting/data extract solution. Over the years Liant got acquired by
>> MicroFocus, and for a number of reasons support is difficult to obtain.
>>
>
> Interesting. My company do an ODBC driver for ISAM files too.
>
> $ odbcinst -j
>> unixODBC 2.2.7
>> DRIVERS............: /usr/local/liant/etc/odbcinst.**ini
>> SYSTEM DATA SOURCES: /usr/local/liant/etc/odbc.ini
>> USER DATA SOURCES..: /home/dbent/.odbc.ini
>>
>
> ok, so this is quite old but we now know definitely it is unixODBC.
> We also know your ODBC drivers are defined in
> /usr/local/liant/etc/odbcinst.**ini and your DSNs are in the other 2
> files - I'm presuming dbent is the logged in user.
>
>
> # cat /usr/local/liant/etc/odbc.ini
>> [ODBC Data Sources]
>> prod1 = Relativity Client
>> verify = Relativity Client
>>
>> [prod1]
>> Driver = /usr/local/liant/lib/relclient**.sl<http://relclient.sl><
>> http://relclient.sl>
>> ServerName = chicago.1583
>> ServerDSN = prod1
>> QryPlan = 0
>> ArrayFetchOn = 1
>> ArrayBufferSize = 8
>>
>
> This is a bit unusual. It looks more like an iODBC odbc.ini file but it
> doesn't really matter, unixODBC will just ignore [ODBC Data Sources]
> section. I'm also surprised by that http string but I'm guessing again this
> is ignored by unixODBC. Also Driver is usually set to the key from the
> odbcinst.ini file instead of the .sl file again but what you have also
> works.
>
>
> [test1]
>> Driver = /usr/local/liant/lib/relclient**.sl<http://relclient.sl><
>> http://relclient.sl>
>> ServerName = chicago.1583
>> ServerDSN = test1
>> QryPlan = 0
>> ArrayFetchOn = 1
>> ArrayBufferSize = 8
>>
>> [verify]
>> Driver = /usr/local/liant/lib/relclient**.sl<http://relclient.sl><
>> http://relclient.sl>
>> ServerName = chicago.1583
>> ServerDSN = verify
>> QryPlan = 0
>> ArrayFetchOn = 1
>> ArrayBufferSize = 8
>> # cat /usr/local/liant/etc/odbcinst.**ini
>> [ODBC Drivers]
>> Relativity Client = Installed
>>
>> [Relativity Client]
>> Driver = /usr/local/liant/lib/relclient**.sl<http://relclient.sl><
>> http://relclient.sl>
>> Setup = /usr/local/liant/lib/relclnsu.**sl <http://relclnsu.sl><
>> http://relclnsu.sl>
>> APILevel = 2
>> ConnectFunction = YYY
>> DriverODBCVer = 02.50
>> FileUsage = 4
>> SQLLevel = 0
>> DefaultServer = chicago
>> SvcEnableBroadcasting = 0
>> SvcPort = 1599
>> SvcServer = 127.0.0.1
>> SvcClntTimeOut = 1
>> SvcSystemDSN = 0
>> UpdateEveryXHourSec = 3600
>> SvcDirect = 1
>> UpdateAlways = 0
>> SvcSvrPort = 1583
>> EnableAutoUpdate = 0
>>
>
> don't really get that last entry.
>
> $ ll /usr/local/liant/lib/*
>> lrwxrwxrwx 1 root sys 10 Nov 8 2007
>> /usr/local/liant/lib/libiodbc.**sl <http://libiodbc.sl> <
>> http://libiodbc.sl> -> libodbc.sl
>> <http://libodbc.sl>
>> lrwxrwxrwx 1 root sys 14 Nov 8 2007
>> /usr/local/liant/lib/libiodbci**nst.sl <http://libiodbcinst.sl> <
>> http://libiodbcinst.sl> ->
>> libodbcinst.sl <http://libodbcinst.sl>
>> lrwxrwxrwx 1 root sys 14 Nov 8 2007
>> /usr/local/liant/lib/libodbc.**sl <http://libodbc.sl> <http://libodbc.sl>
>> -> libodbc.sl.1.0
>> lrwxrwxrwx 1 root sys 14 Nov 8 2007
>> /usr/local/liant/lib/libodbc.**sl.1 -> libodbc.sl.1.0
>> -r-xr-xr-x 1 root sys 2322328 Jan 18 2005
>> /usr/local/liant/lib/libodbc.**sl.1.0
>> lrwxrwxrwx 1 root sys 18 Nov 8 2007
>> /usr/local/liant/lib/libodbcin**st.sl <http://libodbcinst.sl> <
>> http://libodbcinst.sl> ->
>> libodbcinst.sl.1.0
>> lrwxrwxrwx 1 root sys 18 Nov 8 2007
>> /usr/local/liant/lib/**libodbcinst.sl.1 -> libodbcinst.sl.1.0
>> -r-xr-xr-x 1 root sys 582304 Jan 18 2005
>> /usr/local/liant/lib/**libodbcinst.sl.1.0
>> -rwxrwxrwx 1 root root 638976 May 30 2006
>> /usr/local/liant/lib/relclient**.sl <http://relclient.sl> <
>> http://relclient.sl>
>> -rwxrwxrwx 1 root root 49152 May 30 2006
>> /usr/local/liant/lib/relclnsu.**sl <http://relclnsu.sl> <
>> http://relclnsu.sl>
>>
>
> That explains some things. All the iodbc files are links to odbc and your
> driver really is named with a space in it.
>
> strace it is then - since this pretty much looks ok.
>
> Martin
>
>
>>
>> On Wed, Jun 26, 2013 at 2:01 PM, Martin J. Evans <boh...@ntlworld.com
>> <mailto:boh...@ntlworld.com>> wrote:
>>
>> On 26/06/2013 19:35, Dan Bent wrote:
>>
>> Big thanks!
>>
>> I did this:
>> ldd
>> /opt/perl_32/lib/site_perl/5._**_8.8/PA-RISC1.1-thread-multi/_**
>> _auto/DBD/ODBC/ODBC.sl
>>
>> and got:
>>
>> /usr/local/liant/lib/libodbc._**_sl.1 =>
>> /usr/local/liant/lib/libodbc._**_sl.1
>> /usr/lib/libc.2 => /usr/lib/libc.2
>> /usr/lib/libdld.2 => /usr/lib/libdld.2
>> /usr/lib/libc.2 => /usr/lib/libc.2
>> /usr/lib/libpthread.1 => /usr/lib/libpthread.1
>>
>>
>> hmm - never heard of "liant". It looks like the unixODBC driver
>> manager but I've never seen it installed in that location. Also, I
>> see you've got isql and that comes with unixODBC. Have you also got
>> a binary called odbcinst and if you have output from odbcinst -j
>> would be useful.
>>
>>
>> I tried isql -v prod1 username password
>>
>> and it just hung like other attempts to access the database. No
>> error
>> messages.
>>
>>
>> OK, so we've ruled out a change in Perl and DBI and DBD::ODBC as it
>> is still going wrong without them. If this really is unixODBC you
>> should have an odbc.ini and odbcinst.ini file probably in
>> /usr/local/liant/etc or /usr/local/etc of /etc. What is in those
>> files? There may also be a .odbc.ini in the users home dir.
>>
>> When we see the contents of those files we'll have a better idea of
>> what driver you are using and the shared library used so you can
>> check that too to see if it has been updated.
>>
>> You could enable unixODBC tracing but it rarely outputs much before
>> connection is complete. I think you need to find the equivalent of
>> strace on HPUX and run it on the isql command to see what system
>> calls are being made.
>>
>> Did you say everything is on one box, so networking off that box
>> cannot be the issue?
>>
>> Martin
>>
>>
>>
>>
>> On Wed, Jun 26, 2013 at 12:11 PM, Martin J. Evans
>> <boh...@ntlworld.com <mailto:boh...@ntlworld.com>
>> <mailto:boh...@ntlworld.com <mailto:boh...@ntlworld.com>>> wrote:
>>
>> On 26/06/2013 17:28, Dan Bent wrote:
>>
>> I suddenly lost the ability to connect to my ODBC
>> database
>> yesterday,
>> after years of using the same function to establish a
>> connection:
>>
>> sub dbaseconnect {
>> if (defined($testing)) {
>> if ($testing eq "YES") {
>> $dsn = 'dbi:ODBC:test1' ;
>> print "Using test database\n" ;
>> } elsif ($testing eq "TRAIN") {
>> $dsn = 'dbi:ODBC:train1' ;
>> print "Using train1 database\n" ;
>> } else {
>> $dsn = 'dbi:ODBC:prod1' ;
>> }
>> } else {
>> $dsn = 'dbi:ODBC:prod1' ;
>> }
>> $user = 'USER' ;
>> $passwd = 'PASSWORD' ;
>> my %adrivers = DBI->available_drivers();
>> print join(", ", %adrivers), "\n" ;
>>
>> print "connecting to DATABASE $dsn $user
>> $passwd\n" ;
>> $dbh = DBI->connect($dsn, $user, $passwd,
>> {RaiseError => 1, AutoCommit => 0})
>> or die "Could not connect to database: " .
>> DBI->errstr ;
>> print "connected to DATABASE $dsn \n" ;
>> }
>>
>> So, to gather information about where the failure is, I
>> ran the
>> following program:
>>
>> #! /usr/bin/perl
>>
>> use DBI ;
>> use DBD::ODBC ;
>> use strict ;
>> use warnings ;
>>
>> print "Available Drivers: " ;
>> my @adrivers = DBI->available_drivers();
>> print join(", ", @adrivers), "\n" ;
>>
>> print "Data Sources: " ;
>> foreach my $driver ( @adrivers ) {
>> print "Driver: $driver\n";
>> my @dataSources = DBI->data_sources( $driver );
>> foreach my $dataSource ( @dataSources ) {
>> print "\tData Source is $dataSource\n";
>> }
>> print "\n";
>> }
>>
>> and the output I got was:
>>
>> Available Drivers: DBM, ExampleP, File, ODBC, Proxy,
>> Sponge
>> Installed Drivers:
>> Data Sources: Driver: DBM
>> Data Source is DBI:DBM:f_dir=.
>> Data Source is DBI:DBM:f_dir=CIGNA
>> Data Source is DBI:DBM:f_dir=Logs
>> Data Source is DBI:DBM:f_dir=ONCOURSE
>> Data Source is DBI:DBM:f_dir=autemp
>> Data Source is DBI:DBM:f_dir=config
>> Data Source is DBI:DBM:f_dir=fh.cob
>> Data Source is DBI:DBM:f_dir=perlscripts
>> Data Source is DBI:DBM:f_dir=pndspndwk
>> Data Source is DBI:DBM:f_dir=prgrun_dir
>> Data Source is DBI:DBM:f_dir=scripts
>>
>> Driver: ExampleP
>> Data Source is dbi:ExampleP:dir=.
>>
>> Driver: File
>> Data Source is DBI:File:f_dir=.
>> Data Source is DBI:File:f_dir=CIGNA
>> Data Source is DBI:File:f_dir=Logs
>> Data Source is DBI:File:f_dir=ONCOURSE
>> Data Source is DBI:File:f_dir=autemp
>> Data Source is DBI:File:f_dir=config
>> Data Source is DBI:File:f_dir=fh.cob
>> Data Source is DBI:File:f_dir=perlscripts
>> Data Source is DBI:File:f_dir=pndspndwk
>> Data Source is DBI:File:f_dir=prgrun_dir
>> Data Source is DBI:File:f_dir=scripts
>>
>> Driver: ODBC
>>
>> and the program just hangs when it looks for data
>> sources using
>> the ODBC
>> driver. So, I suspect that there are issues with the ODBC
>> driver. Here
>> are the versions of the various DBI module components:
>>
>> perl -MDBI -e 'DBI->installed_versions'
>> Perl : 5.008008
>> (PA-RISC1.1-thread-multi)
>> OS : hpux (11.00)
>> DBI : 1.50
>> DBD::Sponge : 11.10
>> DBD::Proxy : install_driver(Proxy) failed:
>> Can't locate
>> RPC/PlClient.pm in @INC
>> DBD::ODBC : 1.14
>> DBD::File : 0.33
>> DBD::ExampleP : 11.12
>> DBD::DBM : 0.03
>>
>> I imagine that I may not have the latest versions of
>> everything, and
>> updates are probably in order, but, while updates are
>> desirable, I'd
>> like to be sure that I'm addressing the root cause of the
>> problem, so I
>> get it resolved. This issue affects a lot of programs,
>> and is
>> critical
>> to our business.
>> Any help or suggestions will be greatly appreciated.
>>
>>
>> You are in deed running VERY old versions - especially of
>> DBD::ODBC.
>>
>> You first need to think about what Jonathan said - he's
>> probably
>> right that working out what changed yesterday is probably
>> going to
>> give the quickest result.
>>
>> Assuming you cannot find anything here are some suggestions.
>>
>> DBD::ODBC is usually linked to an ODBC driver manager but
>> back in
>> the days of 1.14 people still linked directly to an ODBC
>> driver
>> sometimes - ODBC drivers did not support enumerating DSNs -
>> only the
>> driver manager does that. So first thing is hwo was
>> DBD::ODBC built?
>> If you don't know that look for ODBC.so in your perl tree
>> and run
>> the HPUX equivalent of Linux's ldd command on it to find what
>> libraries it depends on (right now I cannot remember what the
>> command is).
>>
>> Once you've done that if the answer is libodbc.so.something
>> then you
>> are probably using the unixODBC driver manager. In that
>> case you
>> should hopefully have an isql binary and you should have an
>> odbc.ini
>> and odbcinst.ini defining your drivers and DSNs. What is in
>> those
>> files. Can you run:
>>
>> isql -v TEST1 username password
>> isql -v TRAIN1 username password
>> isql -v PROD1 username password
>>
>> as you didn't say which one you are using?
>>
>> If you get back with this info I'll help more.
>>
>> Martin
>> --
>> Martin J. Evans
>> Wetherby, UK
>>
>
