[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::sns

Title:POLYCENTER System Watchdog for VMS OSF/1 ULTRIX HP-UX AIX SunOS
Notice:Wishes:406,FAQ:845,Kits-VMS:1000,UNIX:694 VMS ECO01 FT kit: 521
Moderator:AZUR::HUREZZ
Created:Fri May 15 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1033
Total number of notes:4584

996.0. "%CLI-W-VALREQ, in action routine" by PRSSOS::MENICACCI () Fri Feb 07 1997 14:43

	Hi, 

I'm not very familiar with PSW so if my explanations are incomplete let me know.

Here is my customer problem.

He's currently running : OpenVMS ALPHA (AlphaServer 1000)
                         PSW T2.2-09 / OSCint V2.1


On this system a consolidator is running. An action routine is in charge of
deleting external messages send to PCM via OSCint.


After a few time, not just after the startup of SNS$AR_xxx, some parameters are
lost. Customer has the feeling that the problem occurs when the number of events
is incresing.

Here are the logs when it works and when it doesn't (with same procedure :

$ START:
$ !
$ ! Gestion des erreurs et du control_Y
$ ! ===================================
$ !
$       if f$trnlnm("SNS$DEL_EXT_MESSAGE") .nes. ""
$          then SH SYMBOL P1
  P1 = "7-FEB 16:24 LYA001 %alarm-F-essai, pour AES"
$               SH SYMBOL P2
  P2 = "7-FEB-1997 16:24:39.81"
$               SH SYMBOL P3
  P3 = "SNS_C_EXT"
$               SH SYMBOL P4
  P4 = "LYA001"
$               SH SYMBOL P5
  P5 = "LYC001"
               SH SYMBOL P6
  P6 = "DEL_EXTERNAL"
$               SH SYMBOL P7
  P7 = "SNS_C_NEW"
$               sh SYMBOL P8
  P8 = "%alarm-F-essai, pour AES"
$       endif
$       SET NOON
$ !
$ !Do not generate DELETE MESSAGE when the event message is removed.
$ !
$       if ( p7 .eqs. "SNS_C_REM" ) then exit
$ !
$       SNS_POS = F$LOCATE(P4,P1)
$       SNS_LG1  = F$LENGTH(P4)
$       SNS_LG2  = F$LENGTH(P1)
$       SNS_POS = SNS_POS + SNS_LG1 + 1
$       SNS_TXT = F$EXTRACT(SNS_POS,SNS_LG2-SNS_POS,P1)
$!Obu
$       SNS_MESSAGE = F$EXTRACT(0,f$locate("|",P8),P8)
$       if f$trnlnm("SNS$DEL_EXT_MESSAGE") .nes. ""
$          then  sho symb sns_*
  SNS_LG1 = 6   Hex = 00000006  Octal = 00000000006
  SNS_LG2 = 43   Hex = 0000002B  Octal = 00000000053
  SNS_MESSAGE = "%alarm-F-essai, pour AES"
  SNS_POS = 19   Hex = 00000013  Octal = 00000000023
  SNS_TXT = "%alarm-F-essai, pour AES"
        endif
$!Obu   SENSE WATCH DELETE MESSAGE "'P8'"/NODE='P4'
$       SENSE WATCH DELETE MESSAGE "%alarm-F-essai, pour AES"/NODE=LYA001
%SNS-S-REMOVED, Message(s) successfully deleted
$ ! FIN :  <============================================== OK

$ START:
$ !
$ ! Gestion des erreurs et du control_Y
$ ! ===================================
$ !
$       if f$trnlnm("SNS$DEL_EXT_MESSAGE") .nes. ""
$          then SH SYMBOL P1
  P1 = "7-FEB 14:05 RAA001 %ALARM-F-DSKQEX, ALARM SYSTEMBA SCHED#_287
SENSOR_DI*
$               SH SYMBOL P2
  P2 = " -"
$               SH SYMBOL P3
  P3 = ""
$               SH SYMBOL P4
  P4 = ""
$               SH SYMBOL P5
  P5 = ""
$               SH SYMBOL P6
  P6 = ""
$               SH SYMBOL P7
  P7 = ""
$               sh SYMBOL P8
  P8 = ""
$       endif
$       SET NOON
$ !
$ !Do not generate DELETE MESSAGE when the event message is removed.
$ !
$       if ( p7 .eqs. "SNS_C_REM" ) then exit
$ !
$       SNS_POS = F$LOCATE(P4,P1)
$       SNS_LG1  = F$LENGTH(P4)
$       SNS_LG2  = F$LENGTH(P1)
$       SNS_POS = SNS_POS + SNS_LG1 + 1
$       SNS_TXT = F$EXTRACT(SNS_POS,SNS_LG2-SNS_POS,P1)
$!Obu
$       SNS_MESSAGE = F$EXTRACT(0,f$locate("|",P8),P8)
$       if f$trnlnm("SNS$DEL_EXT_MESSAGE") .nes. ""
$          then  sho symb sns_*
  SNS_LG1 = 0   Hex = 00000000  Octal = 00000000000
  SNS_LG2 = 126   Hex = 0000007E  Octal = 00000000176
  SNS_MESSAGE = ""
  SNS_POS = 1   Hex = 00000001  Octal = 00000000001
  SNS_TXT = "-FEB 14:05 RAA001 %ALARM-F-DSKQEX, ALARM SYSTEMBA SCHED#_287
SENSO*
        endif
$!Obu   SENSE WATCH DELETE MESSAGE "'P8'"/NODE='P4'
$       SENSE WATCH DELETE MESSAGE ""/NODE=
%CLI-W-VALREQ, missing qualifier or keyword value - supply all required values
$ ! FIN :    


If you need any other informations, let me know.

Maria.
T.RTitleUserPersonal
Name
DateLines
996.1Seen it...AZUR::HUREZConnectivity &amp; Computing Services @VBE. DTN 828-5159Mon Feb 10 1997 08:0711
    Hello Maria,
    
    Yes, I've seen that unusual behaviour lately on my test system,
    for a couple of events every 20 or 30 events...  I'll have a deeper
    look into it right after the cluster-wide events duplication bug fix
    I'm currently dealing with.  Those fixes will be included in the ECO04.
    
    Regards,
    
    	-- Olivier.
    
996.2Can you confirmPRSSOS::MENICACCIWed Feb 19 1997 08:1320
	Olivier,

can you confirm that this problem is corrected in ECO04 ?

I read the release notes, 

	      5. Problem with quotation marks included within object
                 identifiers into the profile and badly interpreted when
                 passed as parameters to action routines: this made the
                 one P1 parameter appear as many separate parameters
                 and possibly resulted in the command procedure eight
                 parameter number limit overflow.

Is it the problem ?

And, may we give this ECO04 FT to customer ?

Thanks,

Maira.
996.3Code is fixed but tests are not yet completed.AZUR::HUREZConnectivity &amp; Computing Services @VBE. DTN 828-5159Wed Feb 19 1997 11:5931
    
    Hello Maria,
    
    Although the topic #5 you listed is not the problem mentionned in this
    note, I worked indeed on the parameter passing to the action routines.
    
    In ECO03, a problem was introduced because of the generalization
    of the usage of a routine intended to optimize strings by removing
    leading and tailing spaces.  I unadequately applied this routine on
    event timestamps as well, which led to a 1 character left-shift
    when event dates were 1 digit only, e.g.  "1-FEB 12:12:12" instead
    of " 1-FEB 12:12:12".  For some reason, this left shift had a bad
    impact on the action routine parameter passing mechanism.  I didn't
    notice it: regression tests must have been performed after the first
    9 days of the month... :-(
    
    I fixed the code, built and installed the ECO04 and did not experience
    the problem anymore since then, but since I haven't yet perform integration
    tests specifically aimed to this topic, and the current dates are not
    among the bad ones, the RN is not yet updated...
    
    Although the ECO04 isn't fully tested as yet, I think it is stable enough
    to be pushed to customers who are awaiting fixes specifically listed into
    the release notes.  In the particular case of the customer concerned
    with the action parameter passing, you may want to proceed with the
    tests now or to wait a day or two until I'll have done it myself.
    
    Best Regards,
    
    	-- Olivier.