ICM 7.5 User Variable size 40? 255?

[adancso]

All,

in order to optimise some scripts we would need longer than 40 character long global variables. The documentation states the max is 40, but testing it I could store up to 255 char long strings in a persistent global var and could retrieve them running another script.

Does anybody know why Cisco puts an "artificial" limit on those variables?

Thanks,

Attila

[geoff]

When I see the word "persistent" it raises questions in my mind and I just want to be sure you understand global variables.

Global variables are not call variables and are not "thread safe" in a reentrant application like the CallRouter. When many calls are being routed by Scripts in the CallRouter, you must be careful about setting a global variable in one Script with an intent to use it in another Script.

The only place I set global variables is in Admin Scripts (controlling the holiday flag, open / closed flag, emergency flag etc.). They are read by Routing Scripts.

Marking a global variable as "persistent" in the Config Tool means it's written to the Logger. It doesn't make it thread safe or have call context. I have never found a use for this and never configure global variables as persistent in order to save Logger writes. (If anyone has a good use for persistent globals I'd like to hear of it).

To overcome the limit you could use a number of global variables.

But before we go there, please explain what you are doing with the global variables.

Regards,

Geoff

[adancso]

Geoff,

I'm using the globals as you described. Admin scripts extracting configuration data (business hours, etc.) from an external database and saving them into globals. Routing scripts make decisions using those variables.

Attila

[geoff]

OK, very good. No need to make them persistent.

So back to your question. Where does the 40 come in? When I create a User Variable of Object Type "User Variable" and Data Type "Character" it does not ask me for the length.

I have implemented a lookup into a DB to control open/closed and the processing in the Admin Script produces open/closed flags. Why are you needing to carry a big string value  to the Routing Script? Can't you massage it in the Admin Script? This is how I did it.

Regards,

Geoff

[adancso]

Geoff,

page 134 of the Scripting and Media Routing Guide 7.5(1) says:

"What are User Variables?....A user variable can store a value up to 40 characters long."

As as I read this, the only way working with 41-255 byte strings is using call (ECC or Peripheral) variables.

My challenge is that I'd like to pass an "array" of 5 byte strings having 30-40 elements from an Admin script to Routing Scripts in the form of a long string having fixed length elements. This would allow me to cut down the size of my scripts massively as I could execute things with loops.

I know I could save it broken down to multiple 40 byte strings and reassemble it with one set+concatenate() node, but having just one variable would be ideal.

Thanks for the heads up on persistent vars.

Attila

[geoff]

My challenge is that I'd like to pass an "array" of 5 byte strings having 30-40 elements from an Admin script to Routing Scripts in the form of a long string having fixed length elements. This would allow me to cut down the size of my scripts massively as I could execute things with loops.

I'm still interested in exactly what you are doing. This is opening hours control, correct?

Regards,

Geoff

[braclarke]

"I have never found a use for this and never configure global variables  as persistent in order to save Logger writes. (If anyone has a good use  for persistent globals I'd like to hear of it)."

What happens if the router process dies on both sides (say during an upgrade or un planned outage).

Aren't all those value for Time of Day / Open Close ,etc set back to "null" then?

I know that the admin scripts would reset those values in time, but we have some that only runs 1 time a week or 1 time per month.

[jessepbeatty]

In that case, you'd probably want them persistent. Although my guess is that the admin script would run when the router comes back up and then again a week/month afterwards. Not sure on that, though. I would say the most common practice out there is to run an admin script every minute to check TOD/DOW in which case the persistent flag doesn't make much sense.

On the other hand, checking the persistent box on ECC variables can be useful (but also consumes disk space) since it causes those values to be written to the Termination_Call_Variable table.

[spaulin]

I can't speak to the user variable length question...

But as far as persistent, here's why you'd want it. (braclarke is right)

Say your admin script was only scheduled to run hourly, or daily, and set some global user variable which is referenced in your routing script(s).

And for some reason, the Central Controllers go down (power hit, hardware failure, exit_router, etc.).  If you didn't have the variable data set to persistent, then the router would come up, and not have any of those variables populated until the Admin script is scheduled to run .  That might be 59 minutes, or a day, or week from now (depending on timing, obviously).  All calls routed in the meantime could potentially be mis-routed because the variables are NULL.

By periodically saving the user variable data to the logger, if the router restarts, then while loading the configuration it will load these "seed" values and not have to wait for the Admin script to run to populate them.  There is no real need to be concerned with database space utilization or "load" on the loggers.  It's truly negligible.

jessepbeatty - The persistent box has nothing to do with Expanded Call Context (ECC) variable data.  RCV and TCV will be written to the logger (and HDS) regardless of whether you have 'persistent' enabled for user variables.  Persistent only controls whether user variable data is stored as described above.

[jessepbeatty]

spaulin,

I don't believe that statement is completely correct. In my understanding:

User Variables - Persistent checkbox functions as you and others have described.

ECC Variables - Persistent checkbox checked = ECC data is written to the historical database.

ECC Variables - Persistent checkbox is unchecked = ECC data can be used for call routing purposes, but is not written to the historical database.

[spaulin]

You may be correct - I'll doublecheck as soon as I can access a lab.

[david.macias]

My understanding is the same as Jesse's.  Would love to hear if it's different.

david

[spaulin]

I checked the 7.5 Schema & sure enough under the definition of the Expanded Call Variable table, there is a field for persistent, described as follows:

==============================

Persistent

Y or N. Default is N.

Speci

fies whether or not each individual ECC variable is persistent(is written to the historical database with the TCD or RCD record).

The 'Persistent' value is con

figurable using the Expanded CallContext Variable list tool. For newly-added ECC variables, the checkbox for the Peristent value is unchecked; that is, the default value is 'N'. To change the value to'Y', check this box in the configuration tool.

In an upgrade, pre-existing ECC variables, which were previouslypersistent by default, are not changed; they remain 'Y'. You may recon

figure them to 'N'

Note:

Only persistent ECC variables (those set to 'Y' ) are writtento the database. Non-persistent ECC variables (those set to 'N' ) arenot written to the database, but they can be used in routing scripts.

==============================

So I apologize to jessepbeatty and anyone else who I may have confused.  But in my defense, you can see that ECC data always used to be persistent.  I don't know in which version they added the Persistent field.