IY98311: SCRIPT DP CONVERTS TO INTERVAL MODE ON LINUX; DOES NOT ON WIN

APAR status

• Closed as program error.

Error description

• Environment:
  
  Operating System: Linux
  .
  Other relevant information
  Product: ITM 6.1 FP04
  TEMS, TEPS, OS Agent and Universal Agent are all installed
  in the same GNU/Linux machine.
  .
  OS:
  cat /etc/redhat-release
  Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
  .
  uname -a
  Linux flower 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:28:02 EDT
  2006 i686 i686 i386 GNU/Linux
  
  
  Problem Description:
  
  The script specified in my metafile is called every 60 seconds
    even when I indicated in the situation an interval of 30
    minutes   (there is no INTERVAL in the metafile).
  
  Then when I stop and delete the situation the script is still
    being called every 60 seconds.
  
  I have one SNMP metafile and one script metafile in the system,
  "cinfo -r" gives:
  Host     Prod    PID     Owner   Start    ID  ..Status
  flower   ms      30166   root    Feb05 flower ..running
  flower   cq      30483   root    Feb05 None ..running
  flower   lz      30888   root    Feb05 None ..running
  flower   um      2980    root    Feb05 None ..running
  flower   um      3074    root    Feb05 kumsnetd_None ..running
  flower   um      3104    root    Feb05 kumstrap_None ..running
  .
  I have defined a situation with an interval of 30 minutes,
  but my script is being run every minute or 60 seconds.
  
  Detailed Recreation Procedure:
  
  To duplicate problem again I did the following:
  - Install TEMS, TEPS, OS Linux Agent and UA in same machine.
  - Create perl script that logs the time in a file.
    (I will append the one I used to duplicate this).
  - Define metafile, validate and import (I will append mine)
  - Create a situation, I made the interval for the situation
    5 minutes or 10 minutes or something like that.
  - tail the file the script is appending to, I used:
    tail -f /opt/IBM/ITM/li6243/um/scripts/itm_tst_interval.log
  - After you see that the script run once, wait a little bit
    and then click in the TEP to see the data the script
    is sending to the TEP, then you will see two calls to the
    script.
  .
  I did append the logs I got.  You can see the situation run the
  script at time 21:41:59, so I wait a little bit, then at the
  time
  21:42:25 I click in the sub node M01_TST_INTERVAL_N in the TEP
  to
  see the data in the TEP and I got two entries at 21:42:25, and
  from there on I got a call every minute:
  
  Script called at 2007/02/06 21:37:19
  Script called at 2007/02/06 21:41:59
  Script called at 2007/02/06 21:42:25
  Script called at 2007/02/06 21:42:25
  Script called at 2007/02/06 21:43:25
  Script called at 2007/02/06 21:44:25
  Script called at 2007/02/06 21:45:25
  Script called at 2007/02/06 21:46:25
  ....
  
  
  Here is the metafile:
  .
  *--------------------------------------
  //APPL M01_TST_INTERVAL_A
  //NAME M01_TST_INTERVAL_N S 900 AddTimeStamp
  //SOURCE SCRIPT /usr/bin/perl itm_tst_interval.pl
  *--------------------------------------
  //ATTRIBUTES '^'
  system_name         D   64
  itm_tst_interval    Z   512
  *--------------------------------------
  .
  Here is the script itm_tst_interval.pl
  .
  #!/usr/bin/perl
  #
    &my_main;
    exit 0;
  #
  sub itm_getLogTime
  {
      $iTime = time();
      my ($sec,$min,$hour,$mday,$mon,$year,$d1,$d2,$d3) =
  localtime(
  $iTime );
      $year = $year+1900; $mon++;
      $mon  = "0$mon"  if ($mon < 10);
      $mday = "0$mday" if ($mday < 10);
      $min  = "0$min"  if ($min < 10);
      $sec  = "0$sec"  if ($sec < 10);
      return "$year/$mon/$mday $hour:$min:$sec";
  }
  sub my_main
  {
      $lt = &itm_getLogTime;
      chomp( $SysName = `hostname` );
      print "$SysName^ script called at $lt \n";
      $logF =
  "/opt/IBM/ITM/li6243/um/scripts/itm_tst_interval.log";
      system( "echo \"Script called at $lt\" >> $logF" );
  }
  
  Reviewing the logs shows that it is switching to interval-driven
  data
  collection with 60 second sampling interval!!
  
  (45C93B0F.0000-2E:kumpscrp.c,398,"KUMP_ScriptServer") Script
  source
  </opt/IBM/ITM/li6243/um/work/../scripts/itm_tst_interval.pl>
  table
  <M01_TST_INTERVAL_N> is now online to the data provider
  (45C93B0F.0001-B:kumdchsv.cpp,4660,"DCHserver::dp_setDemandRepor
  tOption"
  ) Enabling DemandReporting for <M01/M01_TST_INTERVAL_N/flower>
  (45C93C91.0000-2E:kumpscrp.c,609,"KUMP_ScriptServer") Note:
  Converting
  table <M01_TST_INTERVAL_N> source
  </opt/IBM/ITM/li6243/um/work/../scripts/itm_tst_interval.pl> to
  interval-driven data collection with 60 second sampling interval
  (45C93C91.0001-B:kumdchsv.cpp,4672,"DCHserver::dp_setDemandRepor
  tOption"
  ) Disabling DemandReporting for <M01/M01_TST_INTERVAL_N/flower>
  (45C9425F.0000-4:kumpccmd.c,559,"KUMP_ConsoleService") >>>>> DP
  console
  REFRESH for itm_tst_interval.mdl
  (45C9425F.0001-D:kumamain.cpp,3001,"main::processOffline")
  Subnode
  <flower:M01_TST_INTERVAL_A00> deregistered.
  (45C9425F.0002-4:kumpcadm.c,1678,"KUMP_ConstructApplDataModel")
  *INFO:
  APPL names starting with letters A-M are designated for Best
  Practices
  and Business Partner UA solutions. Application
  <M01_TST_INTERVAL_A>
  Metafile </opt/IBM/ITM/li6243/um/metafiles/itm_tst_interval.mdl>
  
  Sample 2:
  I have other metafiles that do not have INTERVAL in the name
  I created the one with INTERVAL in the name just for testing
  and to open the PMR. For example I have the following metafile:
  *--------------------------------------
  //APPL NV9_ping
  //NAME PING S 300 AddTimeStamp
  //SOURCE SCRIPT /usr/bin/perl itm_ping.pl
  //ATTRIBUTES ':'
  Agent_Name      D   64
  Minimum         C   999999
  Average         C   999999
  Maximum         C   999999
  *--------------------------------------
  and it has the same problem, the log shows:
  .
  (45F177C3.0001-E:kumdchsv.cpp,4660,"DCHserver::
    dp_setDemandReportOption") Enabling DemandReporting
    for <NV9/PING/ateo_rh4>
  (45F178DB.0000-54:kumpscrp.c,609,"KUMP_ScriptServer")
    Note: Converting table <PING> source
    </opt/IBM/ITM/li6243/um/work/../scripts/itm_ping.pl>
    to interval-driven data collection with 60 second
    sampling interval
  .
  We do not want to run my script itm_ping.pl every 60 seconds.
  
  Aditional test results:
  
  Tracing set to,
  KUMP_SCRIPT_DEBUG=Y
  
  I have changed the um.ini file as requested and I run with
  a very small change in the metafile (I prefixed with T01):
  .
  //APPL T01_TST_INTERVAL_A
  //NAME T01_TST_INTERVAL_N S 900 AddTimeStamp
  //SOURCE SCRIPT /usr/bin/perl T01_tst_interval.pl
  .
  This does not affect the outcome of the test becuase
  I have the problem with any metafile that uses the
  Script DP.
  .
  I run it with two variations.
  .
  1) I created a situation and I set it to run every 5 minutes,
  I also was looking at the data (click in the node in the TEP)
  so I made my script run on demand and with the situation.
  After the 4th entry in my log (my perl script logs an entry)
  ITM changes and runs my script every minute.  See files
  in 34805_w_sit.zip
  .
  2) I stoped the um, deleted the situation and then start um
  again. This time I did not create a situation, I just look
  at the data (I clicked in TEP to run my script on demand)
  and after the 4th time ITM changed and started to run my
  script every minute.
  See files in 34805_no_sit.zip
  .
  I conclude that we can forget about the situations.
  Something makes ITM change after running the script
  several times on demand, just click on the TEP.
  
  Approver:BEH
  

Local fix

Problem summary

• This problem was reported against ITM 6.1 FP4 maintenance level
  for Universal Agent.  When using UA's SCRIPT or ODBC data
  provider in demand-driven mode, the UA's data provider would
  switch to interval-driven mode using a 60 second interval; this
  typically occurred after the third demand-drivem Report or
  Situation request.  The problem is agnostic to platform UA was
  running on.
  

Problem conclusion

• When using UA's SCRIPT or ODBC data provider in the
  demand-driven mode, the ReportRequestExpiration timer could be
  incorrectly set to value zero.  This zero value caused UA's data
  provider to exercise a 'fail safe' that UA has to switch to
  interval-driven mode if after 3 times the execution time for a
  script or SQL query exceeded or was equal to the
  ReportRequestExipration timer.
  
  So with zero value for ReportRequestExpiration, UA was
  exercising unwarranted switching from demand-driven to interval
  driven mode.
  
  This APAR fix eliminates these unwarranted mode switches.  The
  fail safe still exists and will be exercised, if need be, but
  only for cases that truly justify the mode switch.
  
  The fix for this APAR is included in the following maintenance
  vehicle:
  
      | fix pack | 6.1.0-TIV-ITM-FP0005
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  UNIVERSAL AGENT

• Fixed component ID

  5724K1000

Applicable component levels

• R610 PSY

     UP