$ZSNMP error.

We are getting the following error in the EMS on daily basis.:
"OSS error in method om_DecodePDU at location 1.  OSS Function:
om_DecodePDU  Error: -5"
Could anybody put some light on how do we get rid of this.
I explored in to the SNMP manuals. It says that the error is that the
process is receiving

-5 - The data being decoded is erroneous. This is a decoding error.
Effect. If the error is fatal, the agent stops running. Messages
associated with
nonfatal errors are discarded.

Is there any possible way to find out which process is sending these
erroneous messages.
0
12/2/2010 2:47:09 PM
comp.sys.tandem 2286 articles. 1 followers. Post Follow

7 Replies
189 Views

Similar Articles

[PageSpeed] 26
Prasad wrote:
> We are getting the following error in the EMS on daily basis.:
> "OSS error in method om_DecodePDU at location 1.  OSS Function:
> om_DecodePDU  Error: -5"
> Could anybody put some light on how do we get rid of this.
> I explored in to the SNMP manuals. It says that the error is that the
> process is receiving
> 
> -5 - The data being decoded is erroneous. This is a decoding error.
> Effect. If the error is fatal, the agent stops running. Messages
> associated with
> nonfatal errors are discarded.
> 
> Is there any possible way to find out which process is sending these
> erroneous messages.

The process ID of the process which sent the event to EMS is included in the EMS event data, and usually is displayed as part of the message display, between the time of the event and the TANDEM.SMP.xxx subsystem ID.  If the way you are viewing events does not show the process ID, you could try viewing the events using EMSDIST, using a command something like this from TACL:

   EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14:21, STOP 2010-12-1 14:25

That will display to the terminal all the events sent to $0 between 14:21 and 14:25 on December 1st.  Change the date and time to correspond to the time the event you are investigating occurred.

If you want to send the output to the spooler, change TEXTOUT [#MYTERM] to TEXTOUT $S.#LP1 or whatever spooler location you wish.

If the events were sent to an alternate collector, use its name in place of $0.

I know nothing of how the SNMP agent errors are generated.  It might be that the EMS event message is generated and logged by a different process than the one which actually encountered the error, in which case the process ID in the EMS message might not help you much.  Or if the data being processed that is in error was created in process A, then sent to another process B, where this error is detected, the EMS event will have the ID of process B, not process A.  In that case, perhaps you will have to see whether process B provides any other information to help find the origin of the bad data.  Or perhaps other event messages near this one in the log will provide some clue as to the origin of the bad data. 

Sometimes EMS events contain additional data that is not formatted in the normal text display.  The detailed description of the event message would say what additional data is included in an event message, but in a quick search, I did not find such detailed description of the SMP events.  In the case of this particular message, it would not surprise me to find that the whole SNMP message that is being decoded is included in the event, but I do not know that it is. 

You could check for additional data by using EMSDIST to dump the entire contents of the event message.  You could do that using an EMSDIST command something like:

   EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14:21, STOP 2010-12-1 14:25, DUMP ON

Without a detailed description of the contents of the event message, you might not be able to tell what the additional data means, but each item from the event message will be formatted separately for you to look at.  The output of event dumps is large, so you probably would want to narrow the time interval given by the TIME and STOP parameters to limit the number of events covered, or create a filter table to use with EMSDIST to select just the SMP events.

I believe there are other tools for viewing the full contents of an event, so if you are familiar with another way, use it.
0
kdick (495)
12/2/2010 3:53:26 PM
On Dec 2, 8:53=A0pm, Keith Dick <kd...@acm.org> wrote:
> Prasad wrote:
> > We are getting the following error in the EMS on daily basis.:
> > "OSS error in method om_DecodePDU at location 1. =A0OSS Function:
> > om_DecodePDU =A0Error: -5"
> > Could anybody put some light on how do we get rid of this.
> > I explored in to the SNMP manuals. It says that the error is that the
> > process is receiving
>
> > -5 - The data being decoded is erroneous. This is a decoding error.
> > Effect. If the error is fatal, the agent stops running. Messages
> > associated with
> > nonfatal errors are discarded.
>
> > Is there any possible way to find out which process is sending these
> > erroneous messages.
>
> The process ID of the process which sent the event to EMS is included in =
the EMS event data, and usually is displayed as part of the message display=
, between the time of the event and the TANDEM.SMP.xxx subsystem ID. =A0If =
the way you are viewing events does not show the process ID, you could try =
viewing the events using EMSDIST, using a command something like this from =
TACL:
>
> =A0 =A0EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14=
:21, STOP 2010-12-1 14:25
>
> That will display to the terminal all the events sent to $0 between 14:21=
 and 14:25 on December 1st. =A0Change the date and time to correspond to th=
e time the event you are investigating occurred.
>
> If you want to send the output to the spooler, change TEXTOUT [#MYTERM] t=
o TEXTOUT $S.#LP1 or whatever spooler location you wish.
>
> If the events were sent to an alternate collector, use its name in place =
of $0.
>
> I know nothing of how the SNMP agent errors are generated. =A0It might be=
 that the EMS event message is generated and logged by a different process =
than the one which actually encountered the error, in which case the proces=
s ID in the EMS message might not help you much. =A0Or if the data being pr=
ocessed that is in error was created in process A, then sent to another pro=
cess B, where this error is detected, the EMS event will have the ID of pro=
cess B, not process A. =A0In that case, perhaps you will have to see whethe=
r process B provides any other information to help find the origin of the b=
ad data. =A0Or perhaps other event messages near this one in the log will p=
rovide some clue as to the origin of the bad data.
>
> Sometimes EMS events contain additional data that is not formatted in the=
 normal text display. =A0The detailed description of the event message woul=
d say what additional data is included in an event message, but in a quick =
search, I did not find such detailed description of the SMP events. =A0In t=
he case of this particular message, it would not surprise me to find that t=
he whole SNMP message that is being decoded is included in the event, but I=
 do not know that it is.
>
> You could check for additional data by using EMSDIST to dump the entire c=
ontents of the event message. =A0You could do that using an EMSDIST command=
 something like:
>
> =A0 =A0EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14=
:21, STOP 2010-12-1 14:25, DUMP ON
>
> Without a detailed description of the contents of the event message, you =
might not be able to tell what the additional data means, but each item fro=
m the event message will be formatted separately for you to look at. =A0The=
 output of event dumps is large, so you probably would want to narrow the t=
ime interval given by the TIME and STOP parameters to limit the number of e=
vents covered, or create a filter table to use with EMSDIST to select just =
the SMP events.
>
> I believe there are other tools for viewing the full contents of an event=
, so if you are familiar with another way, use it.

Thanks Keith,

I went through the SNMP manual and found out that we can alter the the
subsystem TRACE prameter ON through SCF commands to write into the
TRACE file.
Later we can read the Trace file using the PTRACE utility. I tried the
PTRACE on some existing trace files but was not able to understand
whats in it. It would be great If you could help me out to find
whether trace has some relevant information. Mean while I will try the
EMSDIST dump on command to tweak something out.

Below is a sample trace date :-
(Note :- The trace record does not correspond to the actual error
trace. its just a smaple)
11/04/2009 12:31:53.360004 >000.011883 #5              IP Out
Line  4326 of enoutput ( on Oct 25 2008)
Event: 45     Detail: 0D      Object: 3      Data:25
Object : Subnet         SN4
  Dst HW Addr : 00:00:0C:07:AC:01     Src HW Addr : 08:00:8E:07:2D:18
IP Header :  45 00 00 8A 6D 7E 40 00 3C 06 3F B1 23 75 82 12 23 75 C8
42
IP Version: 4   Hdr Len: 20  TTL: 60  TOS: 0    Xsum: 16305   Total
Len: 138
Flags: DF       ID: 28030 at Offset 0     Protocol: 6     (TCP)
Dest IP Address: <ip address>            Source IP Address: <ip
address>              ----- I have masked the iaddresses due to
security restrictions. hope you understand.
TCP Header:  27 16 04 74 33 08 A1 16 EF C9 CE 40 50 18 F0 00 99 5C 00
00
Src Port: 10006 Seq: 856203542     Window: 61440  Offset: 20
UrgPtr: 0
Dst Port: 1140  Ack: 4022980160    Xsum  : 39260  Flags : ACK,PSH


                    Associated Data -    98 bytes
 000:   0060   341C   3030   3035    3939   3730   381C
3242 .`4.000599708.2B
 008:   3543   3041   3636   1C31    3233   1C30   3030   3430
5C0A66.123.00040
 010:   3430   301C   3834   3530    4130   3430   3037   350F
400.8450A040075.
 018:   4040   1C3C   3030   1C65    6139   3130   4134   3034
@@.<00.ea910A404
 020:   3744   3939   4132   3333    3237   3231   3833   3033
7D99A23327218303
 028:   3038   4130   3233   3033    301C   4632   4641   3043
08A023030.F2FA0C
 030:   3133                                                   13

0
12/3/2010 9:22:00 AM
On Dec 3, 2:22=A0pm, Prasad <prasadb3...@gmail.com> wrote:
> On Dec 2, 8:53=A0pm, Keith Dick <kd...@acm.org> wrote:
>
>
>
>
>
> > Prasad wrote:
> > > We are getting the following error in the EMS on daily basis.:
> > > "OSS error in method om_DecodePDU at location 1. =A0OSS Function:
> > > om_DecodePDU =A0Error: -5"
> > > Could anybody put some light on how do we get rid of this.
> > > I explored in to the SNMP manuals. It says that the error is that the
> > > process is receiving
>
> > > -5 - The data being decoded is erroneous. This is a decoding error.
> > > Effect. If the error is fatal, the agent stops running. Messages
> > > associated with
> > > nonfatal errors are discarded.
>
> > > Is there any possible way to find out which process is sending these
> > > erroneous messages.
>
> > The process ID of the process which sent the event to EMS is included i=
n the EMS event data, and usually is displayed as part of the message displ=
ay, between the time of the event and the TANDEM.SMP.xxx subsystem ID. =A0I=
f the way you are viewing events does not show the process ID, you could tr=
y viewing the events using EMSDIST, using a command something like this fro=
m TACL:
>
> > =A0 =A0EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 =
14:21, STOP 2010-12-1 14:25
>
> > That will display to the terminal all the events sent to $0 between 14:=
21 and 14:25 on December 1st. =A0Change the date and time to correspond to =
the time the event you are investigating occurred.
>
> > If you want to send the output to the spooler, change TEXTOUT [#MYTERM]=
 to TEXTOUT $S.#LP1 or whatever spooler location you wish.
>
> > If the events were sent to an alternate collector, use its name in plac=
e of $0.
>
> > I know nothing of how the SNMP agent errors are generated. =A0It might =
be that the EMS event message is generated and logged by a different proces=
s than the one which actually encountered the error, in which case the proc=
ess ID in the EMS message might not help you much. =A0Or if the data being =
processed that is in error was created in process A, then sent to another p=
rocess B, where this error is detected, the EMS event will have the ID of p=
rocess B, not process A. =A0In that case, perhaps you will have to see whet=
her process B provides any other information to help find the origin of the=
 bad data. =A0Or perhaps other event messages near this one in the log will=
 provide some clue as to the origin of the bad data.
>
> > Sometimes EMS events contain additional data that is not formatted in t=
he normal text display. =A0The detailed description of the event message wo=
uld say what additional data is included in an event message, but in a quic=
k search, I did not find such detailed description of the SMP events. =A0In=
 the case of this particular message, it would not surprise me to find that=
 the whole SNMP message that is being decoded is included in the event, but=
 I do not know that it is.
>
> > You could check for additional data by using EMSDIST to dump the entire=
 contents of the event message. =A0You could do that using an EMSDIST comma=
nd something like:
>
> > =A0 =A0EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 =
14:21, STOP 2010-12-1 14:25, DUMP ON
>
> > Without a detailed description of the contents of the event message, yo=
u might not be able to tell what the additional data means, but each item f=
rom the event message will be formatted separately for you to look at. =A0T=
he output of event dumps is large, so you probably would want to narrow the=
 time interval given by the TIME and STOP parameters to limit the number of=
 events covered, or create a filter table to use with EMSDIST to select jus=
t the SMP events.
>
> > I believe there are other tools for viewing the full contents of an eve=
nt, so if you are familiar with another way, use it.
>
> Thanks Keith,
>
> I went through the SNMP manual and found out that we can alter the the
> subsystem TRACE prameter ON through SCF commands to write into the
> TRACE file.
> Later we can read the Trace file using the PTRACE utility. I tried the
> PTRACE on some existing trace files but was not able to understand
> whats in it. It would be great If you could help me out to find
> whether trace has some relevant information. Mean while I will try the
> EMSDIST dump on command to tweak something out.
>
> Below is a sample trace date :-
> (Note :- The trace record does not correspond to the actual error
> trace. its just a smaple)
> 11/04/2009 12:31:53.360004 >000.011883 #5 =A0 =A0 =A0 =A0 =A0 =A0 =A0IP O=
ut
> Line =A04326 of enoutput ( on Oct 25 2008)
> Event: 45 =A0 =A0 Detail: 0D =A0 =A0 =A0Object: 3 =A0 =A0 =A0Data:25
> Object : Subnet =A0 =A0 =A0 =A0 SN4
> =A0 Dst HW Addr : 00:00:0C:07:AC:01 =A0 =A0 Src HW Addr : 08:00:8E:07:2D:=
18
> IP Header : =A045 00 00 8A 6D 7E 40 00 3C 06 3F B1 23 75 82 12 23 75 C8
> 42
> IP Version: 4 =A0 Hdr Len: 20 =A0TTL: 60 =A0TOS: 0 =A0 =A0Xsum: 16305 =A0=
 Total
> Len: 138
> Flags: DF =A0 =A0 =A0 ID: 28030 at Offset 0 =A0 =A0 Protocol: 6 =A0 =A0 (=
TCP)
> Dest IP Address: <ip address> =A0 =A0 =A0 =A0 =A0 =A0Source IP Address: <=
ip
> address> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- I have masked the iaddresses du=
e to
> security restrictions. hope you understand.
> TCP Header: =A027 16 04 74 33 08 A1 16 EF C9 CE 40 50 18 F0 00 99 5C 00
> 00
> Src Port: 10006 Seq: 856203542 =A0 =A0 Window: 61440 =A0Offset: 20
> UrgPtr: 0
> Dst Port: 1140 =A0Ack: 4022980160 =A0 =A0Xsum =A0: 39260 =A0Flags : ACK,P=
SH
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Associated Data - =A0 =A098 bytes
> =A0000: =A0 0060 =A0 341C =A0 3030 =A0 3035 =A0 =A03939 =A0 3730 =A0 381C
> 3242 .`4.000599708.2B
> =A0008: =A0 3543 =A0 3041 =A0 3636 =A0 1C31 =A0 =A03233 =A0 1C30 =A0 3030=
 =A0 3430
> 5C0A66.123.00040
> =A0010: =A0 3430 =A0 301C =A0 3834 =A0 3530 =A0 =A04130 =A0 3430 =A0 3037=
 =A0 350F
> 400.8450A040075.
> =A0018: =A0 4040 =A0 1C3C =A0 3030 =A0 1C65 =A0 =A06139 =A0 3130 =A0 4134=
 =A0 3034
> @@.<00.ea910A404
> =A0020: =A0 3744 =A0 3939 =A0 4132 =A0 3333 =A0 =A03237 =A0 3231 =A0 3833=
 =A0 3033
> 7D99A23327218303
> =A0028: =A0 3038 =A0 4130 =A0 3233 =A0 3033 =A0 =A0301C =A0 4632 =A0 4641=
 =A0 3043
> 08A023030.F2FA0C
> =A0030: =A0 3133 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 13- Hide quoted text -
>
> - Show quoted text -

I tried the EMSDIST dump command following is the output.

                            Header_type:   %H1
                               Checksum:   F
                             Last_error:   token_not_found  (%HFFF8)
                     Last_error_tkncode:   (%H3,%H4,%HFDE6)  Ldev-
Number
                      Max_field_version:   %H0
                                   SSID:   TANDEM.SMP.G06
                       Used_byte_length:   %H9E
                     Buffer_byte_length:   %H9E
                          Console-Print:   T
                         Generating-CPU:   %HC
                               Emphasis:   F
                           Event-Number:   OSS Error  (%H4)
                  Standard-defined-type:   not-specified  (%H0)
                      User-defined-type:   undefined  (%H0)
                      Event-Hdr-Version:   %H2
                     ZEMS-TKN-FORWARDED:   F
                   Generation-Timestamp:   2010-11-19 20:43:43.549.145
                       Logged-Timestamp:   2010-11-19 20:43:43.580.237
                              Node-Name:   "<node name>"
                            Node-Number:   %H1E
                         Generating-PIN:   %H17B
                     Process-Descriptor:   "<\node.<process name>:
6211189"
                     ZEMS-TKN-REDUNDANT:   F
                       Suppress-Display:   F
                                 Userid:   %HFF %HFE

                           Subject-Mark:
                        ZSMP-TKN-METHOD:*  "om_DecodePDU"
                      ZSMP-TKN-LOCATION:   %H1
                        ZSMP-TKN-METHOD:   "decode"
                         ZSMP-TKN-ERROR:-  %HFFFB

0
12/3/2010 9:35:57 AM
Prasad wrote:
> On Dec 2, 8:53 pm, Keith Dick <kd...@acm.org> wrote:
> 
>>Prasad wrote:
>>
>>>We are getting the following error in the EMS on daily basis.:
>>>"OSS error in method om_DecodePDU at location 1.  OSS Function:
>>>om_DecodePDU  Error: -5"
>>>Could anybody put some light on how do we get rid of this.
>>>I explored in to the SNMP manuals. It says that the error is that the
>>>process is receiving
>>
>>>-5 - The data being decoded is erroneous. This is a decoding error.
>>>Effect. If the error is fatal, the agent stops running. Messages
>>>associated with
>>>nonfatal errors are discarded.
>>
>>>Is there any possible way to find out which process is sending these
>>>erroneous messages.
>>
>>The process ID of the process which sent the event to EMS is included in the EMS event data, and usually is displayed as part of the message display, between the time of the event and the TANDEM.SMP.xxx subsystem ID.  If the way you are viewing events does not show the process ID, you could try viewing the events using EMSDIST, using a command something like this from TACL:
>>
>>   EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14:21, STOP 2010-12-1 14:25
>>
>>That will display to the terminal all the events sent to $0 between 14:21 and 14:25 on December 1st.  Change the date and time to correspond to the time the event you are investigating occurred.
>>
>>If you want to send the output to the spooler, change TEXTOUT [#MYTERM] to TEXTOUT $S.#LP1 or whatever spooler location you wish.
>>
>>If the events were sent to an alternate collector, use its name in place of $0.
>>
>>I know nothing of how the SNMP agent errors are generated.  It might be that the EMS event message is generated and logged by a different process than the one which actually encountered the error, in which case the process ID in the EMS message might not help you much.  Or if the data being processed that is in error was created in process A, then sent to another process B, where this error is detected, the EMS event will have the ID of process B, not process A.  In that case, perhaps you will have to see whether process B provides any other information to help find the origin of the bad data.  Or perhaps other event messages near this one in the log will provide some clue as to the origin of the bad data.
>>
>>Sometimes EMS events contain additional data that is not formatted in the normal text display.  The detailed description of the event message would say what additional data is included in an event message, but in a quick search, I did not find such detailed description of the SMP events.  In the case of this particular message, it would not surprise me to find that the whole SNMP message that is being decoded is included in the event, but I do not know that it is.
>>
>>You could check for additional data by using EMSDIST to dump the entire contents of the event message.  You could do that using an EMSDIST command something like:
>>
>>   EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14:21, STOP 2010-12-1 14:25, DUMP ON
>>
>>Without a detailed description of the contents of the event message, you might not be able to tell what the additional data means, but each item from the event message will be formatted separately for you to look at.  The output of event dumps is large, so you probably would want to narrow the time interval given by the TIME and STOP parameters to limit the number of events covered, or create a filter table to use with EMSDIST to select just the SMP events.
>>
>>I believe there are other tools for viewing the full contents of an event, so if you are familiar with another way, use it.
> 
> 
> Thanks Keith,
> 
> I went through the SNMP manual and found out that we can alter the the
> subsystem TRACE prameter ON through SCF commands to write into the
> TRACE file.
> Later we can read the Trace file using the PTRACE utility. I tried the
> PTRACE on some existing trace files but was not able to understand
> whats in it. It would be great If you could help me out to find
> whether trace has some relevant information. Mean while I will try the
> EMSDIST dump on command to tweak something out.
> 
> Below is a sample trace date :-
> (Note :- The trace record does not correspond to the actual error
> trace. its just a smaple)
> 11/04/2009 12:31:53.360004 >000.011883 #5              IP Out
> Line  4326 of enoutput ( on Oct 25 2008)
> Event: 45     Detail: 0D      Object: 3      Data:25
> Object : Subnet         SN4
>   Dst HW Addr : 00:00:0C:07:AC:01     Src HW Addr : 08:00:8E:07:2D:18
> IP Header :  45 00 00 8A 6D 7E 40 00 3C 06 3F B1 23 75 82 12 23 75 C8
> 42
> IP Version: 4   Hdr Len: 20  TTL: 60  TOS: 0    Xsum: 16305   Total
> Len: 138
> Flags: DF       ID: 28030 at Offset 0     Protocol: 6     (TCP)
> Dest IP Address: <ip address>            Source IP Address: <ip
> address>              ----- I have masked the iaddresses due to
> security restrictions. hope you understand.
> TCP Header:  27 16 04 74 33 08 A1 16 EF C9 CE 40 50 18 F0 00 99 5C 00
> 00
> Src Port: 10006 Seq: 856203542     Window: 61440  Offset: 20
> UrgPtr: 0
> Dst Port: 1140  Ack: 4022980160    Xsum  : 39260  Flags : ACK,PSH
> 
> 
>                     Associated Data -    98 bytes
>  000:   0060   341C   3030   3035    3939   3730   381C
> 3242 .`4.000599708.2B
>  008:   3543   3041   3636   1C31    3233   1C30   3030   3430
> 5C0A66.123.00040
>  010:   3430   301C   3834   3530    4130   3430   3037   350F
> 400.8450A040075.
>  018:   4040   1C3C   3030   1C65    6139   3130   4134   3034
> @@.<00.ea910A404
>  020:   3744   3939   4132   3333    3237   3231   3833   3033
> 7D99A23327218303
>  028:   3038   4130   3233   3033    301C   4632   4641   3043
> 08A023030.F2FA0C
>  030:   3133                                                   13
> 

I'm sorry, Prasad, but I do not know very much about data communications.  So I cannot help you very much with interpreting the trace output.  The trace record you show appears to me to be a TCP/IP packet, just judging by some of the names given to the fields.  If you can find the trace record that corresponds to the SNMP message that is triggering the EMS event, perhaps the source address would tell you from where it is coming, which I think was your original question.  But I do not know how you can identify which record in the trace is related to the EMS event, and I do not know whether the TCP/IP packet in that record will come from the process that created the troublesome SNMP message or from some intermediary process.

I image that the part of the trace that follows "Associated Data - 98 bytes" in one of the trace records will contain the troublesome SNMP message.  If you know enough about SNMP messages to recognize them in a dump, perhaps you can find the troublesome SNMP message by looking at the associated data part of the trace record dumps.  Once you find it, perhaps by looking at that SNMP message, you could tell from where it comes.

Let me emphasize that I am just guessing in this whole post, so it might be that none of this is an appropriate way to approach your problem.
0
kdick (495)
12/3/2010 10:49:02 PM
Prasad wrote:
> On Dec 3, 2:22 pm, Prasad <prasadb3...@gmail.com> wrote:
> 
>>On Dec 2, 8:53 pm, Keith Dick <kd...@acm.org> wrote:
>>
>>
>>
>>
>>
>>
>>>Prasad wrote:
>>>
>>>>We are getting the following error in the EMS on daily basis.:
>>>>"OSS error in method om_DecodePDU at location 1.  OSS Function:
>>>>om_DecodePDU  Error: -5"
>>>>Could anybody put some light on how do we get rid of this.
>>>>I explored in to the SNMP manuals. It says that the error is that the
>>>>process is receiving
>>
>>>>-5 - The data being decoded is erroneous. This is a decoding error.
>>>>Effect. If the error is fatal, the agent stops running. Messages
>>>>associated with
>>>>nonfatal errors are discarded.
>>
>>>>Is there any possible way to find out which process is sending these
>>>>erroneous messages.
>>
>>>The process ID of the process which sent the event to EMS is included in the EMS event data, and usually is displayed as part of the message display, between the time of the event and the TANDEM.SMP.xxx subsystem ID.  If the way you are viewing events does not show the process ID, you could try viewing the events using EMSDIST, using a command something like this from TACL:
>>
>>>   EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14:21, STOP 2010-12-1 14:25
>>
>>>That will display to the terminal all the events sent to $0 between 14:21 and 14:25 on December 1st.  Change the date and time to correspond to the time the event you are investigating occurred.
>>
>>>If you want to send the output to the spooler, change TEXTOUT [#MYTERM] to TEXTOUT $S.#LP1 or whatever spooler location you wish.
>>
>>>If the events were sent to an alternate collector, use its name in place of $0.
>>
>>>I know nothing of how the SNMP agent errors are generated.  It might be that the EMS event message is generated and logged by a different process than the one which actually encountered the error, in which case the process ID in the EMS message might not help you much.  Or if the data being processed that is in error was created in process A, then sent to another process B, where this error is detected, the EMS event will have the ID of process B, not process A.  In that case, perhaps you will have to see whether process B provides any other information to help find the origin of the bad data.  Or perhaps other event messages near this one in the log will provide some clue as to the origin of the bad data.
>>
>>>Sometimes EMS events contain additional data that is not formatted in the normal text display.  The detailed description of the event message would say what additional data is included in an event message, but in a quick search, I did not find such detailed description of the SMP events.  In the case of this particular message, it would not surprise me to find that the whole SNMP message that is being decoded is included in the event, but I do not know that it is.
>>
>>>You could check for additional data by using EMSDIST to dump the entire contents of the event message.  You could do that using an EMSDIST command something like:
>>
>>>   EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 14:21, STOP 2010-12-1 14:25, DUMP ON
>>
>>>Without a detailed description of the contents of the event message, you might not be able to tell what the additional data means, but each item from the event message will be formatted separately for you to look at.  The output of event dumps is large, so you probably would want to narrow the time interval given by the TIME and STOP parameters to limit the number of events covered, or create a filter table to use with EMSDIST to select just the SMP events.
>>
>>>I believe there are other tools for viewing the full contents of an event, so if you are familiar with another way, use it.
>>
>>Thanks Keith,
>>
>>I went through the SNMP manual and found out that we can alter the the
>>subsystem TRACE prameter ON through SCF commands to write into the
>>TRACE file.
>>Later we can read the Trace file using the PTRACE utility. I tried the
>>PTRACE on some existing trace files but was not able to understand
>>whats in it. It would be great If you could help me out to find
>>whether trace has some relevant information. Mean while I will try the
>>EMSDIST dump on command to tweak something out.
>>
>>Below is a sample trace date :-
>>(Note :- The trace record does not correspond to the actual error
>>trace. its just a smaple)
>>11/04/2009 12:31:53.360004 >000.011883 #5              IP Out
>>Line  4326 of enoutput ( on Oct 25 2008)
>>Event: 45     Detail: 0D      Object: 3      Data:25
>>Object : Subnet         SN4
>>  Dst HW Addr : 00:00:0C:07:AC:01     Src HW Addr : 08:00:8E:07:2D:18
>>IP Header :  45 00 00 8A 6D 7E 40 00 3C 06 3F B1 23 75 82 12 23 75 C8
>>42
>>IP Version: 4   Hdr Len: 20  TTL: 60  TOS: 0    Xsum: 16305   Total
>>Len: 138
>>Flags: DF       ID: 28030 at Offset 0     Protocol: 6     (TCP)
>>Dest IP Address: <ip address>            Source IP Address: <ip
>>address>              ----- I have masked the iaddresses due to
>>security restrictions. hope you understand.
>>TCP Header:  27 16 04 74 33 08 A1 16 EF C9 CE 40 50 18 F0 00 99 5C 00
>>00
>>Src Port: 10006 Seq: 856203542     Window: 61440  Offset: 20
>>UrgPtr: 0
>>Dst Port: 1140  Ack: 4022980160    Xsum  : 39260  Flags : ACK,PSH
>>
>>                    Associated Data -    98 bytes
>> 000:   0060   341C   3030   3035    3939   3730   381C
>>3242 .`4.000599708.2B
>> 008:   3543   3041   3636   1C31    3233   1C30   3030   3430
>>5C0A66.123.00040
>> 010:   3430   301C   3834   3530    4130   3430   3037   350F
>>400.8450A040075.
>> 018:   4040   1C3C   3030   1C65    6139   3130   4134   3034
>>@@.<00.ea910A404
>> 020:   3744   3939   4132   3333    3237   3231   3833   3033
>>7D99A23327218303
>> 028:   3038   4130   3233   3033    301C   4632   4641   3043
>>08A023030.F2FA0C
>> 030:   3133                                                   13- Hide quoted text -
>>
>>- Show quoted text -
> 
> 
> I tried the EMSDIST dump command following is the output.
> 
>                             Header_type:   %H1
>                                Checksum:   F
>                              Last_error:   token_not_found  (%HFFF8)
>                      Last_error_tkncode:   (%H3,%H4,%HFDE6)  Ldev-
> Number
>                       Max_field_version:   %H0
>                                    SSID:   TANDEM.SMP.G06
>                        Used_byte_length:   %H9E
>                      Buffer_byte_length:   %H9E
>                           Console-Print:   T
>                          Generating-CPU:   %HC
>                                Emphasis:   F
>                            Event-Number:   OSS Error  (%H4)
>                   Standard-defined-type:   not-specified  (%H0)
>                       User-defined-type:   undefined  (%H0)
>                       Event-Hdr-Version:   %H2
>                      ZEMS-TKN-FORWARDED:   F
>                    Generation-Timestamp:   2010-11-19 20:43:43.549.145
>                        Logged-Timestamp:   2010-11-19 20:43:43.580.237
>                               Node-Name:   "<node name>"
>                             Node-Number:   %H1E
>                          Generating-PIN:   %H17B
>                      Process-Descriptor:   "<\node.<process name>:
> 6211189"
>                      ZEMS-TKN-REDUNDANT:   F
>                        Suppress-Display:   F
>                                  Userid:   %HFF %HFE
> 
>                            Subject-Mark:
>                         ZSMP-TKN-METHOD:*  "om_DecodePDU"
>                       ZSMP-TKN-LOCATION:   %H1
>                         ZSMP-TKN-METHOD:   "decode"
>                          ZSMP-TKN-ERROR:-  %HFFFB
> 

There seems to be no extra data in this event.

From the event header fields, it shows that the event was created by process 12,379 of Expand system number 30.  The userid of that process was 255,254.  The system name and process descriptor are displayed in what seem to me to be an odd way.  I do not know why they are not formatted more normally.  You can see the timestamp.  The rest of the data mainly is internal EMS information, so probably not of interested to you.
0
kdick (495)
12/3/2010 11:15:24 PM
On 4 Dez., 00:15, Keith Dick <kd...@acm.org> wrote:
> Prasad wrote:
> > On Dec 3, 2:22 pm, Prasad <prasadb3...@gmail.com> wrote:
>
> >>On Dec 2, 8:53 pm, Keith Dick <kd...@acm.org> wrote:
>
> >>>Prasad wrote:
>
> >>>>We are getting the following error in the EMS on daily basis.:
> >>>>"OSS error in method om_DecodePDU at location 1. =A0OSS Function:
> >>>>om_DecodePDU =A0Error: -5"
> >>>>Could anybody put some light on how do we get rid of this.
> >>>>I explored in to the SNMP manuals. It says that the error is that the
> >>>>process is receiving
>
> >>>>-5 - The data being decoded is erroneous. This is a decoding error.
> >>>>Effect. If the error is fatal, the agent stops running. Messages
> >>>>associated with
> >>>>nonfatal errors are discarded.
>
> >>>>Is there any possible way to find out which process is sending these
> >>>>erroneous messages.
>
> >>>The process ID of the process which sent the event to EMS is included =
in the EMS event data, and usually is displayed as part of the message disp=
lay, between the time of the event and the TANDEM.SMP.xxx subsystem ID. =A0=
If the way you are viewing events does not show the process ID, you could t=
ry viewing the events using EMSDIST, using a command something like this fr=
om TACL:
>
> >>> =A0 EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 1=
4:21, STOP 2010-12-1 14:25
>
> >>>That will display to the terminal all the events sent to $0 between 14=
:21 and 14:25 on December 1st. =A0Change the date and time to correspond to=
 the time the event you are investigating occurred.
>
> >>>If you want to send the output to the spooler, change TEXTOUT [#MYTERM=
] to TEXTOUT $S.#LP1 or whatever spooler location you wish.
>
> >>>If the events were sent to an alternate collector, use its name in pla=
ce of $0.
>
> >>>I know nothing of how the SNMP agent errors are generated. =A0It might=
 be that the EMS event message is generated and logged by a different proce=
ss than the one which actually encountered the error, in which case the pro=
cess ID in the EMS message might not help you much. =A0Or if the data being=
 processed that is in error was created in process A, then sent to another =
process B, where this error is detected, the EMS event will have the ID of =
process B, not process A. =A0In that case, perhaps you will have to see whe=
ther process B provides any other information to help find the origin of th=
e bad data. =A0Or perhaps other event messages near this one in the log wil=
l provide some clue as to the origin of the bad data.
>
> >>>Sometimes EMS events contain additional data that is not formatted in =
the normal text display. =A0The detailed description of the event message w=
ould say what additional data is included in an event message, but in a qui=
ck search, I did not find such detailed description of the SMP events. =A0I=
n the case of this particular message, it would not surprise me to find tha=
t the whole SNMP message that is being decoded is included in the event, bu=
t I do not know that it is.
>
> >>>You could check for additional data by using EMSDIST to dump the entir=
e contents of the event message. =A0You could do that using an EMSDIST comm=
and something like:
>
> >>> =A0 EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1 1=
4:21, STOP 2010-12-1 14:25, DUMP ON
>
> >>>Without a detailed description of the contents of the event message, y=
ou might not be able to tell what the additional data means, but each item =
from the event message will be formatted separately for you to look at. =A0=
The output of event dumps is large, so you probably would want to narrow th=
e time interval given by the TIME and STOP parameters to limit the number o=
f events covered, or create a filter table to use with EMSDIST to select ju=
st the SMP events.
>
> >>>I believe there are other tools for viewing the full contents of an ev=
ent, so if you are familiar with another way, use it.
>
> >>Thanks Keith,
>
> >>I went through the SNMP manual and found out that we can alter the the
> >>subsystem TRACE prameter ON through SCF commands to write into the
> >>TRACE file.
> >>Later we can read the Trace file using the PTRACE utility. I tried the
> >>PTRACE on some existing trace files but was not able to understand
> >>whats in it. It would be great If you could help me out to find
> >>whether trace has some relevant information. Mean while I will try the
> >>EMSDIST dump on command to tweak something out.
>
> >>Below is a sample trace date :-
> >>(Note :- The trace record does not correspond to the actual error
> >>trace. its just a smaple)
> >>11/04/2009 12:31:53.360004 >000.011883 #5 =A0 =A0 =A0 =A0 =A0 =A0 =A0IP=
 Out
> >>Line =A04326 of enoutput ( on Oct 25 2008)
> >>Event: 45 =A0 =A0 Detail: 0D =A0 =A0 =A0Object: 3 =A0 =A0 =A0Data:25
> >>Object : Subnet =A0 =A0 =A0 =A0 SN4
> >> =A0Dst HW Addr : 00:00:0C:07:AC:01 =A0 =A0 Src HW Addr : 08:00:8E:07:2=
D:18
> >>IP Header : =A045 00 00 8A 6D 7E 40 00 3C 06 3F B1 23 75 82 12 23 75 C8
> >>42
> >>IP Version: 4 =A0 Hdr Len: 20 =A0TTL: 60 =A0TOS: 0 =A0 =A0Xsum: 16305 =
=A0 Total
> >>Len: 138
> >>Flags: DF =A0 =A0 =A0 ID: 28030 at Offset 0 =A0 =A0 Protocol: 6 =A0 =A0=
 (TCP)
> >>Dest IP Address: <ip address> =A0 =A0 =A0 =A0 =A0 =A0Source IP Address:=
 <ip
> >>address> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- I have masked the iaddresses =
due to
> >>security restrictions. hope you understand.
> >>TCP Header: =A027 16 04 74 33 08 A1 16 EF C9 CE 40 50 18 F0 00 99 5C 00
> >>00
> >>Src Port: 10006 Seq: 856203542 =A0 =A0 Window: 61440 =A0Offset: 20
> >>UrgPtr: 0
> >>Dst Port: 1140 =A0Ack: 4022980160 =A0 =A0Xsum =A0: 39260 =A0Flags : ACK=
,PSH
>
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Associated Data - =A0 =A098 byt=
es
> >> 000: =A0 0060 =A0 341C =A0 3030 =A0 3035 =A0 =A03939 =A0 3730 =A0 381C
> >>3242 .`4.000599708.2B
> >> 008: =A0 3543 =A0 3041 =A0 3636 =A0 1C31 =A0 =A03233 =A0 1C30 =A0 3030=
 =A0 3430
> >>5C0A66.123.00040
> >> 010: =A0 3430 =A0 301C =A0 3834 =A0 3530 =A0 =A04130 =A0 3430 =A0 3037=
 =A0 350F
> >>400.8450A040075.
> >> 018: =A0 4040 =A0 1C3C =A0 3030 =A0 1C65 =A0 =A06139 =A0 3130 =A0 4134=
 =A0 3034
> >>@@.<00.ea910A404
> >> 020: =A0 3744 =A0 3939 =A0 4132 =A0 3333 =A0 =A03237 =A0 3231 =A0 3833=
 =A0 3033
> >>7D99A23327218303
> >> 028: =A0 3038 =A0 4130 =A0 3233 =A0 3033 =A0 =A0301C =A0 4632 =A0 4641=
 =A0 3043
> >>08A023030.F2FA0C
> >> 030: =A0 3133 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 13- Hide quoted text -
>
> >>- Show quoted text -
>
> > I tried the EMSDIST dump command following is the output.
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Header_type: =
=A0 %H1
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Checksum=
: =A0 F
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Last_error: =
=A0 token_not_found =A0(%HFFF8)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Last_error_tkncode: =A0 (%H3=
,%H4,%HFDE6) =A0Ldev-
> > Number
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Max_field_version: =A0 %H0
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
SSID: =A0 TANDEM.SMP.G06
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Used_byte_length: =A0 %H=
9E
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Buffer_byte_length: =A0 %H9E
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Console-Print: =A0 =
T
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Generating-CPU: =A0 =
%HC
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Emphasis=
: =A0 F
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Event-Number: =
=A0 OSS Error =A0(%H4)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Standard-defined-type: =A0 not-spec=
ified =A0(%H0)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 User-defined-type: =A0 unde=
fined =A0(%H0)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Event-Hdr-Version: =A0 %H2
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ZEMS-TKN-FORWARDED: =A0 F
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Generation-Timestamp: =A0 2010-1=
1-19 20:43:43.549.145
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Logged-Timestamp: =A0 20=
10-11-19 20:43:43.580.237
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Node-Name: =
=A0 "<node name>"
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Node-Number: =
=A0 %H1E
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Generating-PIN: =A0 =
%H17B
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Process-Descriptor: =A0 "<\n=
ode.<process name>:
> > 6211189"
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ZEMS-TKN-REDUNDANT: =A0 F
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Suppress-Display: =A0 F
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0User=
id: =A0 %HFF %HFE
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject-Mark:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZSMP-TKN-METHOD:* =A0"o=
m_DecodePDU"
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZSMP-TKN-LOCATION: =A0 %H1
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZSMP-TKN-METHOD: =A0 "d=
ecode"
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ZSMP-TKN-ERROR:- =A0=
%HFFFB
>
> There seems to be no extra data in this event.
>
> From the event header fields, it shows that the event was created by proc=
ess 12,379 of Expand system number 30. =A0The userid of that process was 25=
5,254. =A0The system name and process descriptor are displayed in what seem=
 to me to be an odd way. =A0I do not know why they are not formatted more n=
ormally. =A0You can see the timestamp. =A0The rest of the data mainly is in=
ternal EMS information, so probably not of interested to you.- Zitierten Te=
xt ausblenden -
>
> - Zitierten Text anzeigen -

I do not think that the event message contains the necessary
information. The $ZSNMP trap handler catches a trap and has problems
decoding that trap. If the time of this event is predictable it would
make sense to start a trace for a short timeframe. You can issue a
trace command against $ZSNMP, like TRACE PROCESS $ZSNMP, to.....
Details can be found in the SNMP Configuration and Management Manual.
0
12/6/2010 8:34:19 AM
On Dec 6 2010, 3:34=A0am, wbreidbach <wolfgang.breidb...@bv-
zahlungssysteme.de> wrote:
> On 4 Dez., 00:15, Keith Dick <kd...@acm.org> wrote:
>
>
>
>
>
> > Prasad wrote:
> > > On Dec 3, 2:22 pm, Prasad <prasadb3...@gmail.com> wrote:
>
> > >>On Dec 2, 8:53 pm, Keith Dick <kd...@acm.org> wrote:
>
> > >>>Prasad wrote:
>
> > >>>>We are getting the following error in the EMS on daily basis.:
> > >>>>"OSS error in method om_DecodePDU at location 1. =A0OSS Function:
> > >>>>om_DecodePDU =A0Error: -5"
> > >>>>Could anybody put some light on how do we get rid of this.
> > >>>>I explored in to the SNMP manuals. It says that the error is that t=
he
> > >>>>process is receiving
>
> > >>>>-5 - The data being decoded is erroneous. This is a decoding error.
> > >>>>Effect. If the error is fatal, the agent stops running. Messages
> > >>>>associated with
> > >>>>nonfatal errors are discarded.
>
> > >>>>Is there any possible way to find out which process is sending thes=
e
> > >>>>erroneous messages.
>
> > >>>The process ID of the process which sent the event to EMS is include=
d in the EMS event data, and usually is displayed as part of the message di=
splay, between the time of the event and the TANDEM.SMP.xxx subsystem ID. =
=A0If the way you are viewing events does not show the process ID, you coul=
d try viewing the events using EMSDIST, using a command something like this=
 from TACL:
>
> > >>> =A0 EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1=
 14:21, STOP 2010-12-1 14:25
>
> > >>>That will display to the terminal all the events sent to $0 between =
14:21 and 14:25 on December 1st. =A0Change the date and time to correspond =
to the time the event you are investigating occurred.
>
> > >>>If you want to send the output to the spooler, change TEXTOUT [#MYTE=
RM] to TEXTOUT $S.#LP1 or whatever spooler location you wish.
>
> > >>>If the events were sent to an alternate collector, use its name in p=
lace of $0.
>
> > >>>I know nothing of how the SNMP agent errors are generated. =A0It mig=
ht be that the EMS event message is generated and logged by a different pro=
cess than the one which actually encountered the error, in which case the p=
rocess ID in the EMS message might not help you much. =A0Or if the data bei=
ng processed that is in error was created in process A, then sent to anothe=
r process B, where this error is detected, the EMS event will have the ID o=
f process B, not process A. =A0In that case, perhaps you will have to see w=
hether process B provides any other information to help find the origin of =
the bad data. =A0Or perhaps other event messages near this one in the log w=
ill provide some clue as to the origin of the bad data.
>
> > >>>Sometimes EMS events contain additional data that is not formatted i=
n the normal text display. =A0The detailed description of the event message=
 would say what additional data is included in an event message, but in a q=
uick search, I did not find such detailed description of the SMP events. =
=A0In the case of this particular message, it would not surprise me to find=
 that the whole SNMP message that is being decoded is included in the event=
, but I do not know that it is.
>
> > >>>You could check for additional data by using EMSDIST to dump the ent=
ire contents of the event message. =A0You could do that using an EMSDIST co=
mmand something like:
>
> > >>> =A0 EMSDIST TYPE P, COLLECTOR $0, TEXTOUT [#MYTERM], TIME 2010-12-1=
 14:21, STOP 2010-12-1 14:25, DUMP ON
>
> > >>>Without a detailed description of the contents of the event message,=
 you might not be able to tell what the additional data means, but each ite=
m from the event message will be formatted separately for you to look at. =
=A0The output of event dumps is large, so you probably would want to narrow=
 the time interval given by the TIME and STOP parameters to limit the numbe=
r of events covered, or create a filter table to use with EMSDIST to select=
 just the SMP events.
>
> > >>>I believe there are other tools for viewing the full contents of an =
event, so if you are familiar with another way, use it.
>
> > >>Thanks Keith,
>
> > >>I went through the SNMP manual and found out that we can alter the th=
e
> > >>subsystem TRACE prameter ON through SCF commands to write into the
> > >>TRACE file.
> > >>Later we can read the Trace file using the PTRACE utility. I tried th=
e
> > >>PTRACE on some existing trace files but was not able to understand
> > >>whats in it. It would be great If you could help me out to find
> > >>whether trace has some relevant information. Mean while I will try th=
e
> > >>EMSDIST dump on command to tweak something out.
>
> > >>Below is a sample trace date :-
> > >>(Note :- The trace record does not correspond to the actual error
> > >>trace. its just a smaple)
> > >>11/04/2009 12:31:53.360004 >000.011883 #5 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
IP Out
> > >>Line =A04326 of enoutput ( on Oct 25 2008)
> > >>Event: 45 =A0 =A0 Detail: 0D =A0 =A0 =A0Object: 3 =A0 =A0 =A0Data:25
> > >>Object : Subnet =A0 =A0 =A0 =A0 SN4
> > >> =A0Dst HW Addr : 00:00:0C:07:AC:01 =A0 =A0 Src HW Addr : 08:00:8E:07=
:2D:18
> > >>IP Header : =A045 00 00 8A 6D 7E 40 00 3C 06 3F B1 23 75 82 12 23 75 =
C8
> > >>42
> > >>IP Version: 4 =A0 Hdr Len: 20 =A0TTL: 60 =A0TOS: 0 =A0 =A0Xsum: 16305=
 =A0 Total
> > >>Len: 138
> > >>Flags: DF =A0 =A0 =A0 ID: 28030 at Offset 0 =A0 =A0 Protocol: 6 =A0 =
=A0 (TCP)
> > >>Dest IP Address: <ip address> =A0 =A0 =A0 =A0 =A0 =A0Source IP Addres=
s: <ip
> > >>address> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- I have masked the iaddresse=
s due to
> > >>security restrictions. hope you understand.
> > >>TCP Header: =A027 16 04 74 33 08 A1 16 EF C9 CE 40 50 18 F0 00 99 5C =
00
> > >>00
> > >>Src Port: 10006 Seq: 856203542 =A0 =A0 Window: 61440 =A0Offset: 20
> > >>UrgPtr: 0
> > >>Dst Port: 1140 =A0Ack: 4022980160 =A0 =A0Xsum =A0: 39260 =A0Flags : A=
CK,PSH
>
> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Associated Data - =A0 =A098 b=
ytes
> > >> 000: =A0 0060 =A0 341C =A0 3030 =A0 3035 =A0 =A03939 =A0 3730 =A0 38=
1C
> > >>3242 .`4.000599708.2B
> > >> 008: =A0 3543 =A0 3041 =A0 3636 =A0 1C31 =A0 =A03233 =A0 1C30 =A0 30=
30 =A0 3430
> > >>5C0A66.123.00040
> > >> 010: =A0 3430 =A0 301C =A0 3834 =A0 3530 =A0 =A04130 =A0 3430 =A0 30=
37 =A0 350F
> > >>400.8450A040075.
> > >> 018: =A0 4040 =A0 1C3C =A0 3030 =A0 1C65 =A0 =A06139 =A0 3130 =A0 41=
34 =A0 3034
> > >>@@.<00.ea910A404
> > >> 020: =A0 3744 =A0 3939 =A0 4132 =A0 3333 =A0 =A03237 =A0 3231 =A0 38=
33 =A0 3033
> > >>7D99A23327218303
> > >> 028: =A0 3038 =A0 4130 =A0 3233 =A0 3033 =A0 =A0301C =A0 4632 =A0 46=
41 =A0 3043
> > >>08A023030.F2FA0C
> > >> 030: =A0 3133 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 13- Hide quoted text -
>
> > >>- Show quoted text -
>
> > > I tried the EMSDIST dump command following is the output.
>
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Header_type: =
=A0 %H1
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Checks=
um: =A0 F
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Last_error=
: =A0 token_not_found =A0(%HFFF8)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Last_error_tkncode: =A0 (%=
H3,%H4,%HFDE6) =A0Ldev-
> > > Number
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Max_field_version: =A0 %H=
0
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0SSID: =A0 TANDEM.SMP.G06
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Used_byte_length: =A0 =
%H9E
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Buffer_byte_length: =A0 %H=
9E
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Console-Print: =
=A0 T
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Generating-CPU: =
=A0 %HC
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Emphas=
is: =A0 F
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Event-Number: =
=A0 OSS Error =A0(%H4)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Standard-defined-type: =A0 not-sp=
ecified =A0(%H0)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 User-defined-type: =A0 un=
defined =A0(%H0)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Event-Hdr-Version: =A0 %H=
2
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ZEMS-TKN-FORWARDED: =A0 F
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Generation-Timestamp: =A0 2010=
-11-19 20:43:43.549.145
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Logged-Timestamp: =A0 =
2010-11-19 20:43:43.580.237
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Node-Name=
: =A0 "<node name>"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Node-Number: =
=A0 %H1E
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Generating-PIN: =
=A0 %H17B
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Process-Descriptor: =A0 "<=
\node.<process name>:
> > > 6211189"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ZEMS-TKN-REDUNDANT: =A0 F
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Suppress-Display: =A0 =
F
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Us=
erid: =A0 %HFF %HFE
>
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject-Mark:
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZSMP-TKN-METHOD:* =A0=
"om_DecodePDU"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZSMP-TKN-LOCATION: =A0 %H=
1
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZSMP-TKN-METHOD: =A0 =
"decode"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ZSMP-TKN-ERROR:- =
=A0%HFFFB
>
> > There seems to be no extra data in this event.
>
> > From the event header fields, it shows that the event was created by pr=
ocess 12,379 of Expand system number 30. =A0The userid of that process was =
255,254. =A0The system name and process descriptor are displayed in what se=
em to me to be an odd way. =A0I do not know why they are not formatted more=
 normally. =A0You can see the timestamp. =A0The rest of the data mainly is =
internal EMS information, so probably not of interested to you.- Zitierten =
Text ausblenden -
>
> > - Zitierten Text anzeigen -
>
> I do not think that the event message contains the necessary
> information. The $ZSNMP trap handler catches a trap and has problems
> decoding that trap. If the time of this event is predictable it would
> make sense to start a trace for a short timeframe. You can issue a
> trace command against $ZSNMP, like TRACE PROCESS $ZSNMP, to.....
> Details can be found in the SNMP Configuration and Management Manual.- Hi=
de quoted text -
>
> - Show quoted text -

I had the same problem when one of the solarwind server tried to
monitor the tandem server by sending SNMPv2-format getBulkRequest and
SNMPAGT supports only SNMPv1...
0
withmanu (63)
1/4/2011 7:42:03 PM
Reply:
Similar artilces about - $ZSNMP error.: