PEPPLER.ORG
Michael Peppler
Sybase Consulting
Menu
Home
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
Freeware
Sybperl
Sybase::Simple
DBD::Sybase
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
FAQs
Sybase on Linux FAQ
Sybperl FAQ
Personal
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: "Ashish Gupta" <ashish dot gupta at mizuho-sc dot com>
Subject: RE: sybperl ct_config CS_RETRY_COUNT
Date: Sep 2 2005 7:03AM

Hi Michael,

Thanks again.

Your running the script shows that the indefinite looping on my machine
is not a problem in sybperl.

I still do not know where the problem is.

I checked the version of the open client installation (using isql -v)
and it is as follows :

12.5.1/P-EBF11758 ESD #2/DRV.12.5.1.0/SPARC/Solaris 2.8/

I do not even know from where to start looking to get a clue for this
problem .... :-)

Anyway, thanks for all your support.

Best regards,
Ashish


-----Original Message-----
From: michael.peppler@bnpparibas.com
[mailto:michael.peppler@bnpparibas.com] 
Sent: Thursday, September 01, 2005 3:05 PM
To: ashish.gupta@mizuho-sc.com
Cc: sybperl-l@peppler.org
Subject: RE: sybperl ct_config CS_RETRY_COUNT


I tried your a.pl script here, and it ran as I would expect it to:

[pepm01a@sgvlin01 perl]$ perl a.pl

Open Client Message:
Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (4)
Message String: ct_connect(): network packet layer: internal net library
error: Net-Lib protocol driver call to connect two endpoints failed

connection failed... at a.pl line 15.
Can't call method "ct_sql" on an undefined value at a.pl line 18.

I'm running OpenClient 12.5.1 EBF 11776 on linux in this instance.

I still don't understand why isql exits immediately after a failed
connection, and sqsh and perl scripts don't. They all three use the same
underlying OpenClient calls, AFAIK.

Michael





Internet
ashish.gupta@mizuho-sc.com - 01/09/2005 05:18


Please respond to ashish.gupta@mizuho-sc.com
To:    Michael PEPPLER

cc:    sybperl-l


Subject:    RE: sybperl ct_config CS_RETRY_COUNT


Hi Michael,

I did not change anything in the OCS-12_5/config/ directory.
The files are :

/home/sybase/OCS-12_5/config> ls -l
total 18
-rw-r--r--   1 sybase   sybase       463 Apr 30  2003 libtcl.cfg
-rw-r--r--   1 sybase   sybase      1529 Sep 27  1996 sample.cfg
-rw-r--r--   1 sybase   sybase      2021 Nov 22  2002 sybase-schema.conf
-rw-r--r--   1 sybase   sybase      3488 Nov 22  2002 sybase.schema
/home/sybase/OCS-12_5/config>

I had installed the servers about 3-4 months ago.
The timestamps show that they have not been altered.


I checked again, that if I add retry_count etc. info in the interfaces
file, both sybperl and sqsh do not pick it up and try indefinitely
to connect to a server which is down. On the contrary, isql
too does not pick it up, but returns after the first attempt.


I am attaching a simple script - a.pl. If you have some time,
please try it on your machine.
On my machine, it carries on indefinitely.



I could simulate the functionality expected of
CS_RETRY_COUNT by putting in some
code in the callback routine. After some number of tries,
instead of CS_SUCCEED, I return CS_FAIL.
Since the manual says:
"In the case of timeout errors, CS_SUCCEED causes
Client-Library to wait for one additional timeout period."

And this seems to work fine.
Please see script b.pl
So, for the time, I have a workaround.

Thanks a lot for your kind support.

Best regards,
Ashish





-----Original Message-----
From: michael.peppler@bnpparibas.com
[mailto:michael.peppler@bnpparibas.com]
Sent: Wednesday, August 31, 2005 6:41 PM
To: ashish.gupta@mizuho-sc.com
Cc: sybperl-l@peppler.org
Subject: RE: sybperl ct_config CS_RETRY_COUNT


There's got to be something fishy about your setup, or about your
script.

In general when a connection fails it shouldn't retry forever - it
should
abort and return control to the script, where you can connect to the
next
db, or whatever.

Do you have anything special in the OCS-12_5/config/ directory that
might
enable a non-default behavior?

Michael





Internet
ashish.gupta@mizuho-sc.com@peppler.org - 30/08/2005 09:53

Please respond to ashish.gupta@mizuho-sc.com
Sent by:        owner-sybperl-l@peppler.org
To:     oladar
cc:     Michael PEPPLER, mpeppler, sybperl-l
Subject:        RE: sybperl ct_config CS_RETRY_COUNT


Thanks Sean.

I tried this too.
But it did not work for sybperl and sqsh.
It worked for isql.

Regards,
Ashish

-----Original Message-----
From: owner-sybperl-l@peppler.org [mailto:owner-sybperl-l@peppler.org]
On Behalf Of Sean Dwyer
Sent: Tuesday, August 30, 2005 4:23 PM
To: ashish.gupta@mizuho-sc.com
Cc: michael.peppler@bnpparibas.com; mpeppler@peppler.org;
sybperl-l@peppler.org
Subject: Re: sybperl ct_config CS_RETRY_COUNT


it has been a long time since I used this but in the interfaces file
it used to be possible ((11.5)) to set the retry count and retry
interval. CTlib would read this and give you a finite loop. For example:

     sybserver 2 3
             master tcp ether server.domain 11002
             query tcp ether server.domain 11002

The client library would read this and try 2 times on 3 second
intervals. Where if the entry was:

     sybserver
             master tcp ether server.domain 11002
             query tcp ether server.domain 11002

  you could be caught in a near infinite loop.

I haven't tried this since 11.5 and may have it reversed. Worth a try
though.

Sean

On Aug 29, 2005, at 6:27 PM, Ashish Gupta wrote:

> Hi Michael,
>
> Thanks for the patch information.
> I changed CTlib.xs as suggested by you.
> I re-installed sybperl.
> I checked that the CTlib.c has the line and also that CTlib.o also has
> the string CS_RETRY_COUNT.
>
> Still, the property is not settable.
> In my script, I set the value to 2, but the connection retries
> carry on
> until I stop the program with a control-c.
>
> I am pasting my program below for your reference.
> In this, I have brought the second server - SYB_DBA62_TKD - down for
> testing.
>
> use Sybase::CTlib;
>
> $user    = "uuuuu"; $pass    = "ppppp";
> $charset = "iso_1"; $Host    = "tktecwsd20";
>
> ct_config(CS_SET, CS_LOGIN_TIMEOUT, 2, CS_INT_TYPE);
> foreach $server (qw(SYB_DBA61_TKD  SYB_DBA62_TKD SYB_DBA63_TKD)){
>     $dbh = Sybase::CTlib->ct_connect($user, $pass, $server, $Me,
>                 { CON_PROPS =>  { CS_SYB_CHARSET   =>
> "$charset",
>                                CS_HOSTNAME
> => "$Host",
>                                CS_RETRY_COUNT
> => 2
>                              }
>                 } );
>     @rrows = $dbh->ct_sql("select count(*) from sysdatabases");
>     $dbcount = ${$rrows[0]}[0];
>     print "Server: $server, Number of Databases: $dbcount \n";
> }
>
>
> Thanks again for your kind help.
>
> Best regards,
> Ashish
>
>
> -----Original Message-----
> From: michael.peppler@bnpparibas.com
> [mailto:michael.peppler@bnpparibas.com]
> Sent: Monday, August 29, 2005 5:54 PM
> To: ashish.gupta@mizuho-sc.com
> Cc: mpeppler@peppler.org; sybperl-l@peppler.org
> Subject: RE: sybperl ct_config CS_RETRY_COUNT
>
>
> Actually the patch is very simple:
>
> Around line 6089 (in the ct_connect() function), just add this:
>
>         SV **svp = hv_fetch((HV*)SvRV(attr), "CON_PROPS", 9, 0);
>         SV *sv;
>         HV *hv;
>         if(svp && SvROK(*svp)) {
>             int i;
>             CS_RETCODE ret;
>             static struct props {
>                 char *name; int attr; int type;
>             } props[] = {
>                 { "CS_HOSTNAME", CS_HOSTNAME, CS_CHAR_TYPE},
>                 { "CS_ANSI_BINDS", CS_ANSI_BINDS, CS_INT_TYPE},
>                 { "CS_PACKETSIZE", CS_PACKETSIZE, CS_INT_TYPE},
>                 { "CS_SEC_APPDEFINED", CS_SEC_APPDEFINED,
> CS_INT_TYPE},
>                 { "CS_SEC_CHALLENGE", CS_SEC_CHALLENGE, CS_INT_TYPE},
>                 { "CS_SEC_ENCRYPTION", CS_SEC_ENCRYPTION,
> CS_INT_TYPE},
>                 { "CS_SEC_NEGOTIATE", CS_SEC_NEGOTIATE, CS_INT_TYPE},
>                 { "CS_TDS_VERSION", CS_TDS_VERSION, CS_INT_TYPE},
> #if defined(CS_HAFAILOVER)
>                 { "CS_HAFAILOVER", CS_HAFAILOVER, CS_INT_TYPE},
> #endif
>                 { "CS_BULK_LOGIN", CS_BULK_LOGIN, CS_INT_TYPE},
> #if defined(CS_SEC_NETWORKAUTH)
>                 { "CS_SEC_NETWORKAUTH", CS_SEC_NETWORKAUTH,
> CS_INT_TYPE},
> #endif
> #if defined(CS_SEC_SERVERPRINCIPAL)
>                 { "CS_SEC_SERVERPRINCIPAL", CS_SEC_SERVERPRINCIPAL,
> CS_CHAR_TYPE},
> #endif
> #if defined(CS_SERVERADDR)
>                 { "CS_SERVERADDR", CS_SERVERADDR, CS_CHAR_TYPE},
> #endif
>                 { "CS_RETRY_COUNT", CS_RETRY_COUNT, CS_INT_TYPE }, /*
> <----------------- add this!! */
>                 { "CS_SYB_LANG", CS_SYB_LANG, -1 },
>                 { "CS_SYB_CHARSET", CS_SYB_CHARSET, -1 },
>                 { "CS_DATA_LCHAR", CS_DATA_LCHAR, -2 },
>                 { "", 0, 0}
>             };
>             hv = (HV*)SvRV(*svp);
>
>
> and rebuild, and all should be well.
>
> Michael
>
>
>
>
> Internet
> ashish.gupta@mizuho-sc.com@peppler.org - 29/08/2005 03:01
>
> Please respond to ashish.gupta@mizuho-sc.com
> Sent by:        owner-sybperl-l@peppler.org
> To:     mpeppler
> cc:     sybperl-l
> Subject:        RE: sybperl ct_config CS_RETRY_COUNT
>
>
> Hi Michael,
>
> Thanks for your prompt and helpful response.
>
> I tried to look at the code in CTlib.xs and I think it will be next to
> impossible for me to attempt a patch. You of course will be busy with
> other responsibilities, and so will need some time for this.
>
> Please can you suggest some workaround?
>
> Please allow me to explain my requirement and current problem.
>
> I am trying to write a small library of functions based on perl and
> sybperl. These will be used by the other DBA scripts. These will
> provide
> functions for connecting, writing to errorlog, sending emails etc.
>
> Usually, for a script such as dump_database, if the server is not
> available, the callback routine is invoked, and from there we can exit
> with appropriate messages and emails.
>
> But what I am trying to do is to store information about each
> execution
> of each script in a central database. This is useful to check at a
> glance which scripts failed and which scripts are pending completion.
> This is useful for us as we have about 150 servers. So, my
> procedure is
> as follows: initially at the start of each script, I will record the
> "start" in the database. Then, after the completion or abort of the
> script, I will record a "finish" or an "abort" in the database.
> Now, the
> problem is, if a server is down and the dump database script fails
> on a
> ct_connect (and as a result keeps on trying since I cannot set
> CS_RETRY_COUNT), then I cannot even try another ct_connect (to the
> central database). The message I get is :
>
>         ct_con_alloc failed at dba_syb_lib.pm line 1073.
>         ct_con_props(CS_HOSTNAME, 'tktecwsd20') failed. at
> dba_syb_lib.pm line 1073.
>         ct_con_props(CS_LOC_PROP) failed at dba_syb_lib.pm line 1073.
>         connection failed... at dba_syb_lib.pm line 1073.
>
> Maybe this message on the next ct_connect will not come if I can set
> CS_RETRY_COUNT to 1.
>
> Another reason (apart from recording in a database) I would like to
> connect to multiple servers within the same script (and not be worried
> about the ct_connect looping infinitely on a server which is down)
> is to
> write a script for pinging all the servers. I want to periodically
> connect to all servers and check for a successful connection. If I
> could
> set CS_RETRY_COUNT = 1, then maybe the next ct_connect will be ok.
>
> This is a long winded explanation. Maybe I can put it simply as
> follows.
> If my first ct_connect is looping, trying to connect to a server which
> is down, how is it possible for me to stop or ignore this and carry on
> with the next ct_connect to another server.
>
>
> Thanks again for your kind help.
>
> Best regards,
> Ashish
>
>
> -----Original Message-----
> From: Michael Peppler [mailto:mpeppler@peppler.org]
> Sent: Friday, August 26, 2005 8:23 PM
> To: ashish.gupta@mizuho-sc.com
> Cc: sybperl-l@peppler.org
> Subject: RE: sybperl ct_config CS_RETRY_COUNT
>
>
> On Fri, 2005-08-26 at 15:33 +0900, Ashish Gupta wrote:
>
>> Hi Michael,
>>
>> I still get an error.
>>
>> I tried the command :
>>
>>       ct_config(CS_SET, 9173,   2, CS_INT_TYPE);
>>
>>
>> And the following error was reported :
>>
>> Open Client Message:
>> Message number: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (5)
>> Message String: ct_config(): user api layer: external error: An
>>
> illegal
>
>> value of 9173 given for parameter property.
>>
>
> Indeed - the problem is that CS_RETRY_COUNT is a connection
> property, to
> be set with ct_con_props() before the connection is attempted. This is
> handled differently in this module, and will require a patch to the
> code
> to get working. You can see how the other connection properties are
> handled in CTlib.xs around line 6065 in my copy.
>
> Michael
> --
> Michael Peppler  -  mpeppler@peppler.org  -  http://www.peppler.org/
> Sybase DBA/Developer
> Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
>
>
> Note: This e-mail contains privileged and confidential information and
> is
> for the sole use of the intended recipient(s).  If you are not an
> intended
> recipient, you are hereby kindly requested to refrain from printing,
> copying, or distributing the information contained herein.
> Furthermore,
>
> any other use of the information contained herein is strictly
> prohibited.
> If you have received this transmission in error, please kindly notify
> the
> sender immediately and destroy all copies of the original message.
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
>                 ---------------------------------------------
>
> Ce message et toutes les pieces jointes (ci-apres le
> "message") sont etablis a l'intention exclusive de ses
> destinataires et sont confidentiels. Si vous recevez ce
> message par erreur, merci de le detruire et d'en avertir
> immediatement l'expediteur. Toute utilisation de ce
> message non conforme a sa destination, toute diffusion
> ou toute publication, totale ou partielle, est interdite, sauf
> autorisation expresse. L'internet ne permettant pas
> d'assurer l'integrite de ce message, BNP PARIBAS (et ses
> filiales) decline(nt) toute responsabilite au titre de ce
> message, dans l'hypothese ou il aurait ete modifie.
>
> Note: This e-mail contains privileged and confidential information
> and is for the sole use of the intended recipient(s).  If you are
> not an intended recipient, you are hereby kindly requested to
> refrain from printing, copying, or distributing the information
> contained herein.  Furthermore, any other use of the information
> contained herein is strictly prohibited.  If you have received this
> transmission in error, please kindly notify the sender immediately
> and destroy all copies of the original message.
>
>

Note: This e-mail contains privileged and confidential information and
is
for the sole use of the intended recipient(s).  If you are not an
intended
recipient, you are hereby kindly requested to refrain from printing,
copying, or distributing the information contained herein.  Furthermore,

any other use of the information contained herein is strictly
prohibited.
If you have received this transmission in error, please kindly notify
the
sender immediately and destroy all copies of the original message.

Note: This e-mail contains privileged and confidential information and
is
for the sole use of the intended recipient(s).  If you are not an
intended
recipient, you are hereby kindly requested to refrain from printing,
copying, or distributing the information contained herein.  Furthermore,
any other use of the information contained herein is strictly
prohibited.
If you have received this transmission in error, please kindly notify
the
sender immediately and destroy all copies of the original message.
(See attached file: a.pl)
(See attached file: b.pl)




Note: This e-mail contains privileged and confidential information and is for the sole use of the intended recipient(s).  If you are not an intended recipient, you are hereby kindly requested to refrain from printing, copying, or distributing the information contained herein.  Furthermore, any other use of the information contained herein is strictly prohibited.  If you have received this transmission in error, please kindly notify the sender immediately and destroy all copies of the original message.