Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Fri, 23 May 2003 @ 20:48:10 GMT


     
  <Prev Next>   <<First <Prev Next> Last>>  


Subj:   Re: Capturing Data Leaving Teradata Machine
 
From:   Anomy Anom

This is probably more information than you want but this is an example of the corrupted data. Is anyone good at reading hex?

This is a snippet of an e-mail from the application that is receiving the corrupt data.

*******************************************

Problem: Intermittently we get a corrupted data field in one of the structures.

Notes: Jianhong sent to me a section of the data that was interpreted as corrupted. The third field with the large negative number was the corrupted Field. Jianhong explained to me how the structure laid out and I've added it as a header to the structure data below. The fields lay out as long,long,long,long,6 chars,1 char,long,1 char. We then tried to determine if the field was being received at the server as corrupted and we would then attempt to characterize the corruption. We collected a snoop on the interface that displays the data as its received off the TCP stack before any applications get hold of it. The time stamp of the data from Jianhong's application is 15:41:04. I searched the snoop for the pattern in the 6 char field and found it at timestamp 15:42:56 (there can be a little difference between timestamps relative how they are collected.

As you can see below, 3 of the 5 long fields have very large numbers. The hex value in the field is shown as "bb6f 3f00". I wrote a little program to display this field as hex, long, and then I removed the sign bit and displayed it again (the program and the output are shown below). The result is that the field bb6f 3f00 will display as -1150337280 which is the same as we see in Jianhong's structure. This proves that this is the corrupted data packet and that it is received in error. Since this is a tcp packet, we know that the packet is correct, so the field must have been produced with the corruption at the sender side. One possibility is simply that we had an overflow into the sign bit.

15:41:04 fediNCDSvr 18169 ds_getAccCktDet.C:881 ds_getAccCktDet :
exec_getFacCha
nMpg return list==>
ckt info ==> {
|{
1char 1char
vv vv
|---long--|--long---|--long---|long-|6char||--long---||
|591038208|258795776|-1150337280|288| 19 E||258821953||
|591038208|258795776|-1150337280|288| 21 E||258821953||
|591038208|258795776|-1150337280|288| 22 E||258821953||
|591038208|258795776|-1150337280|288| 23 E||258821953||
|591038208|258795776|-1150337280|288| 24 E||258821953||
|591038208|258795776|-1150337280|288| 20 E||258821953||
|591038208|258795776|-1150337280|288| 18 E||258821953||
|591038208|258795776|-1150337280|288| 17 E||258821953||
}

Hex snoop represnetation (from xhx):

80566 15:42:56.98550 knt0lb.ims.att.com -> ks720.ims.att.com ETHER
Type=0800
(IP), size = 617 bytes
80566 15:42:56.98550 knt0lb.ims.att.com -> ks720.ims.att.com IP
D=135.38.22.199
S=135.38.207.6 LEN=603, ID=49600
80566 15:42:56.98550 knt0lb.ims.att.com -> ks720.ims.att.com TCP D=56367

S=1025
Ack=2032709812 Seq=2535327421 Len=563 Win=24820

0: 0003 ba17 cfa0 00d0 0457 93fc 0800 4500 .........W.\374..E.
16: 025b c1c0 4000 3d06 85c2 8726 cf06 8726 .[..@.=....&...&
32: 16c7 0401 dc2f 971e 06bd 7928 b0b4 5018 ...../....y(..P.
48: 60f4 738a 0000 0302 0500 0000 0000 01ff `.s.............
64: 0000 0000 0000 0000 0000 009d 6b91 0000 ............k...
80: bd57 a848 e7bd 0000 0023 007f 0000 0000 .W.H.....#......
96: 0000 0000 0000 0000 0000 0008 0014 0001 ................
112: 0000 0008 0000 0008 0001 0000 9d5f 0047 ............._.G
128: 0026 0008 01f0 0004 02f0 0004 01f0 0004 .&..............
144: 01f0 0004 01c4 0005 01c5 0001 02f1 0004 ................
160: 01c5 0001 000a 0020 001e 233a 8700 0f6c ....... ..#:...l
176: e900 bb6f 3f00 0000 0120 2031 3920 4500 ...o?.... 19 E.
192: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
208: e900 bb6f 3f00 0000 0120 2032 3120 4500 ...o?.... 21 E.
224: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
240: e900 bb6f 3f00 0000 0120 2032 3220 4500 ...o?.... 22 E.
256: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
272: e900 bb6f 3f00 0000 0120 2032 3320 4500 ...o?.... 23 E.
288: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
304: e900 bb6f 3f00 0000 0120 2032 3420 4500 ...o?.... 24 E.
320: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
336: e900 bb6f 3f00 0000 0120 2032 3020 4500 ...o?.... 20 E.
352: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
368: e900 bb6f 3f00 0000 0120 2031 3820 4500 ...o?.... 18 E.
384: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l
400: e900 bb6f 3f00 0000 0120 2031 3720 4500 ...o?.... 17 E.
416: 0f6d 4f41 000b 0006 0001 0008 0014 0002 .mOA............

Select structure element for comparison with Jianhong's data:

258795776
160: 01c5 0001 000a 0020 001e 233a 8700 0f6c ....... ..#:...l
|3144630016| 0 288 b 1 9 b E
176: e900 bb6f 3f00 0000 0120 2031 3920 4500 ...o?.... 19 E.
192: 0f6d 4f41 000a 0020 001e 233a 8700 0f6c .mOA... ..#:...l

Test Program:

#include
main()
{
long i;
printf("Hex value=0x%x, Decimal value=%d\n", 0xbb6f3f00, 0xbb6f3f00);
printf("Without the sign bit decimal value=%d\n", 0x3b6f3f00);
}

Test Program Output:
Hex value=0xbb6f3f00, Decimal value=-1150337280
Without the sign bit decimal value=997146368


     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016