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:[email protected]] 
Sent: Friday, August 26, 2005 8:23 PM
To: [email protected]
Cc: [email protected]
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  -  [email protected]  -  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.