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: Sean Dwyer <oladar at drizzle dot com>
Subject: Re: sybperl ct_config CS_RETRY_COUNT
Date: Aug 30 2005 7:22AM

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.
>
>