ITM Situation Limits

Answer

ITM Situation Limits

Explain the limits on the Situation formula size and complexity

ITM situation formula are limited in size and complexity at four separate processing stages.

Stage 1: Portal Client (TEP) Situation editor

The TEP has a graphical interface which is used to author situations. One aspect of a situation is the formula, which defines when the situation will be true. Here is a part of the formula tab

Near the bottom, there is a Situation Formula Capacity usage bar. This relates to the formula definition storage area, which is exactly 1020 bytes in size.

If you click on the fx button, you see

In the underlying situation description table, you would see this

*IF *VALUE Process.Command_U *EQ 'ma? *'

which happens to be 40 characters exactly. 40/1020 is 3% rounded downward. You could see this in an exported situation in the PDT tag using

tacmd viewsit -s sitname -e sitname.xml

The 1020 character limit is absolute. Follow best practice and avoid coming close to the limit. There was a recent example where a situation that was very close to the limit was exported as above and that situation could not be imported back using tacmd createsit -i sitname.xml. The exported situation PDT had expanded somewhat because spaces had been added before and after some parentheses which made the result 1024 characters long. This is not something to discover when you are using the exported situation for backup or moving to a new TEMS.

Stage 2: TEMS rule processing

When a situation is started, the formula is converted to SQL that the TEMS dataserver [SQL processor] will use to define the situation. For our case, here is what the SQL looks like

SELECT BCMD, CPUID, CPUPERCENT, CPUTIME, CPU, CHILDSTIME, CHILDUTIME, CMD, UCMD, CONTSWITCH, CONTSWIT64, EGID, EGRPN, EUID, EUSERN, ELAPTIME, ADDR, EVENT, EXECSTATE, FLAG, GRPN, HEAP, INVCONTSWT, INVCONTS64, MAJORFAULT, MAJORFAU64, MEMPERCENT, MINORFAULT, MINORFAU64, NICE, PPID, PRIORITY, COMMAND, UCOMMAND, PROCCOUNT, PGID, PID, READWRITE, READWRI64, GID, SCHEDCLASS, SESSIONID, SIZE, STACK, STARTTIME, SYSTEMTIM, ORIGINNODE, TTY, THREADCNT, TIME, TIMESTAMP, TOTCPUPERC, TOTALTIME, CHILDTIME, SYSTEMTYPE, USERTIME, UID, USERNAME, UUSERNAME, VSIZE, WAITCPUTIM, WAITLKTIME, ZONEID, ZONENAME FROM OMUNX.UNIXPS WHERE SYSTEM.PARMA("SITNAME", "IBM_man_wildcard", 16) AND SYSTEM.PARMA("NUM_VERSION", "2", 1) AND SYSTEM.PARMA("LSTDATE", "1100210164631000", 16) AND SYSTEM.PARMA("SITINFO", "TFWD=Y;OV=N;TDST=0;", 19) AND UNIXPS.UCMD LIKE N'ma? *' ;

When a situation fires the agent captures all attributes, not just the ones used in the formula. So this SELECT starts off with the list of all attributes. [See note 1 below]. Following are some SYSPARMA to convey information about the situation. Finally, the formula limitations are present. This result SQL text is 841 characters long. The SQL is stored in a 2998 character column and so this uses about 28%.

I have never seen this to be a limiting factor, but it could be an issue if an application had a very high number of attribute names.

Prior to ITM 621 IF4 and ITM 622 base, the TEMS would split up a situation with many functions [more than 15 if I remember], That was to protect against a dataserver sql processing issue. When that issue was resolved, the split up logic was removed.

Stage 3: Dataserver SQL Compile Process

When a situation is started and a TEMS is aware that an agent will require the situation, the situation rule or SQL is processed through the dataserver. The dataserver itself has limits. For example, there is a limit on the number of functions like *SCAN [find string within string] and *STR [compare string in fixed position]. If there are too many functions, the compile can fail. That will result in an error condition being returned to Portal client. The exact limit is not known because the dataserver has optimization heuristics which can merge similar tests and thus require fewer actual functions.

Stage 4: Situation Transmission to Agent

A soft limit exists when the situation constraints are transmitted to the agent. It is called soft because correct results are returned. Here is the error message from the TEMS diagnostic log

(48E65E30.0000-18:kpxreqds.cpp,1585,"buildThresholdsFilterObject")
Filter object too big (96800 + 21904),Table UNIXCPU Situation .

The first number is the filter plan - which has a limit of 32767 characters.
The second number is the filter pool or constants, which also have a limit of 32767 characters.

The number of characters doesn't directly compare to the size of the SQL. This is a C++ object which has been "flattened" so it can be sent via a remote procedure call.

This error is most often seen when there is a large number of where clauses. If there are mixed *OR and *AND in the formula, that can drastically increase the size of the SQL and thus the filter object.

In this case, the agent does the work without a filter object. All rows for the attribute group are returned to the TEMS each evaluation period and the TEMS does the filtering. For a pure situation, every potential event is sent to the TEMS. While this produces correct results, the increase in communications traffic and TEMS processing is dramatic and should always be avoided.

If you are developing a new situation and are worried about the issue, best practice is to review the TEMS diagnostic log for the message above and then reduce complexity of the situation if required.

Here is an example of a situation that fits easily in the Situation Editor but just barely squeezes into the filter object limits. There are 20 elements in the *IN clause,

*IF *VALUE NT_Event_Log.Log_Name *EQ System *AND
*VALUE NT_Event_Log.Source *EQ Wins *AND
*VALUE NT_Event_Log.Event_ID_String *IN ('4177','4241','4273','4305','4178','4242','4274','4306','4179','4211','4243','4275','4307','4180','4212')

The PDT usage is about 29%. The Filter object is about 31K, almost up to the 32767 byte limit. This is easy to explain. The *IN clause is actually a shortcut way of specifying a series of *VALUE *EQ clauses *OR’d together. Thus the PDT representation is smaller, but the other stages are just as long.

Situation Formula Overrides

From ITM 621, a situation developer can define Formula Overrides. There is a limit to how many overrides can be supplied. You will see this in two ways: the overrides do not work and there is an error message in the TEMS log like this:

(4C59FF0A.0000-6:ko4ovrd.cpp,168,"Override::Override") Error: Override <IBM_check_ovr__3A44FD0A864C4350> sit <IBM_check_ovr> si
+4C59FF0A.0000 ze <5062> exceeds limit 4000
(4C59FF0A.0001-6:ko4ovrmg.cpp,172,"OverrideManager::getTaskFromName") Fatal err in override <IBM_check_ovr__3A44FD0A864C4350> c
+4C59FF0A.0001 onstruction.  Giving up.

The XML file that defines the overrides for a situation is created at the TEMS and the text must fit into a table column of 4000 characters. The actual size requirement for a single override varies tremendously depending on the names and values of the key columns and the names and values of the override formula. In one case the limit was 26 overrides. In another simpler case, it was 38 overrides.

If you must use many overrides, then create them, start the situation and review the TEMS diagnostic log for such error messages. Then reduce the number until they fit.

Summary: Simplify and don't push against the limits

Remember to avoid creating long complicated situations that push against ITM product limits. If you do run into the limits, then create two situations to do the work.

If you have truly complex logic, then use two situations. The helper situation does some filtering and then invokes an action command. That helper situation would be made invisible to the Portal Client and any event processing. [Note 2:]

The action command [for example in Perl] would perform the needed additional logic - perhaps even looking up items in a database. Then when an event is warranted, it does something to activate another situation. One possibility: put data into a log which another situation would act on. Another possibility would be a kumpsend command. The kumpsend command is a separable portion of ITM Universal Agent which can send a result to any reachable UA Post Data application. A situation would act on the post data arrival.

Notes

Note 1: Each attribute has an internal value called cost. TEMS calculates the highest cost of the attributes in the formula and excludes the attributes of higher cost. This is rarely noticeable in practice. However you can spot it in the Local Time attribute group, where Time is higher cost than Hours. If you have a formula that uses Hours, then the Time attribute is not retrieved.

Note 2: After debugging the helper situation, make sure it is not associated with any navigation tree node. Also make sure it is not defined to be sent to any event processor using the Situation Editor EIF tab controls.

For additional Technotes search on "IBM ITM ITM6 Technote"
Search: ITM ITM6 Technote Situation capacity size limits sbs