Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: michael dot peppler at bnpparibas dot com
Subject: RE: sybperl ct_config CS_RETRY_COUNT
Date: Aug 29 2005 8:54AM

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},
#if defined(CS_HAFAILOVER)
                { "CS_BULK_LOGIN", CS_BULK_LOGIN, CS_INT_TYPE},
#if defined(CS_SERVERADDR)
                { "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.


Internet - 29/08/2005 03:01
Please respond to
Sent by:
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 line 1073.
        ct_con_props(CS_HOSTNAME, 'tktecwsd20') failed. at line 1073.
        ct_con_props(CS_LOC_PROP) failed at line 1073.
        connection failed... at line 1073.

Maybe this message on the next ct_connect will not come if I can set

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,

-----Original Message-----
From: Michael Peppler []
Sent: Friday, August 26, 2005 8:23 PM
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
> 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 Peppler  -  -
Sybase DBA/Developer
Sybase on Linux FAQ:

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.