Script size limitations, and calling a script from another script.

Started by SteveK, March 08, 2010, 02:23:34 AM

Previous topic - Next topic

SteveK

Hi All,

I am trying to display a message in response to a SNMP trap that has 200+ Emums (using a case statement in a script), and there seems to be a limitation to the numbers of lines that a script allows. It allows me to add all the lines in the script editor, but when I save the script, it seems to get cut short.

In an attempt to get around this I thought that I may be able to split it up into 2 separate scripts, and call them from another script. I have done some basic testing, I cannot seem to be able to call a script from another script.

Can someone please advise if it is possible to call a script from another script, and if so, the syntax.

Also is there some way the database can be modified to allow longer scripts?

Many thanks.

Victor Kirhenshtein

Hello!

It's very strange - there are no size limitation on scripts. What database you are using?

To call one script from another, called script must be in script library, and contain function(s) other than main(). Then in calling script you should add use statement, for example:

script in library, called my_script:


sub my_function()
{
   return "some value";
}


script in event processing policy:


use my_script;

sub main()
{
   value = my_function();
   // some further processing
}


Best regards,
Victor

SteveK

Hi Victor,

Thank you for your swift response. I am using SQL 2005, and the field "script_code" is data type "text".

The script had 5547 characters, and when saved, it chopped off after 3591 characters.

In your example, you mention the calling script in event processing policy. Can this be another script in library?

Kind Regards,
Steve...

Victor Kirhenshtein

Hi!

Yes, you can call library script from another library script in a same way.

I'll check script saving in MS SQL a bit later.

Best regards,
Victor

SteveK

Thanks Victor,

That worked. Your help is much appreciated.

Kind Regards,
Steve...