Solaris/Linux compatibility problems

[Carter Bullard]

Hey Guys,
   Yes indeed, if I move the "record_len" field around, I indeed can get all
things to work.  I'll make the change in "G" and warn everyone about the
problems.  That should happen, however, on Monday, as I am now on
the road.

   For those on the list, there is a problem (don't know when it raised its
head) where some Solaris compilers want to align (long long) variables
on quad word boundaries.  Result, some Solaris clients can't read any
data, and thus we don't have machine independence.

   The solution is to move some variable around in the Argus Record.
No problem, just all Argus-2.0 data prior to release "G" will be
incompatible.

Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426


 -----Original Message-----
From: Walter Wong [mailto:wcw+ at cmu.edu]
Sent: Wednesday, December 06, 2000 10:17 AM
To: Mark Poepping; Carter Bullard
Subject: RE: byte order?



I pulled the data file from black-bird. The name of the file reflects the
date (11/23 was it?)

Why does the linux version not care that the size of the record is 0?

Walter

-----Original Message-----
From: Mark Poepping [mailto:poepping at CMU.EDU]
Sent: Wednesday, December 06, 2000 9:14 AM
To: carter at qosient.com; 'Walter Wong'
Subject: RE: byte order?



I'd expect 'E', since that's what's running on black-bird, but I'm not sure
where Walter got the data.  I'll do 'F' later today.
mark.


-----Original Message-----
From: Carter Bullard [mailto:carter at qosient.com]
Sent: Wednesday, December 06, 2000 9:10 AM
To: 'Walter Wong'; 'Mark Poepping'
Subject: RE: byte order?


Hey Guys,
   An update on our problem.  The Argus Start Record that we're working with
thinks that the size of the argus records in this stream are zero (0) bytes
long.  So we bail on the first read.  This I can fix, BUT, the better
solution
is to find out how this value got to be zero (0).  So, what version
generated
this output file?  Was it "A" by any chance?

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

-----Original Message-----
From: Walter Wong [mailto:wcw+ at cmu.edu]
Sent: Tuesday, December 05, 2000 8:30 PM
To: Mark Poepping
Cc: Carter Bullard
Subject: RE: byte order?


Good point...

machine is sol2.nas.cmu.edu. You should be able to ssh in.

file is in /mnt/dat.

Files should be the same -- one is just gzip'd and one is not.

'E' is compiled and in /mnt/argus/bin.

Walter

-----Original Message-----
From: Mark Poepping [mailto:poepping at CMU.EDU]
Sent: Tuesday, December 05, 2000 2:48 PM
To: Walter Wong
Cc: carter at qosient.com
Subject: RE: byte order?



I sponsor an account for carter, so yes, he does have access
to a sparc and linux.
mark.


-----Original Message-----
From: Walter Wong [mailto:wcw+ at cmu.edu]
Sent: Tuesday, December 05, 2000 10:16 AM
To: carter at qosient.com
Cc: 'Mark G Poepping'
Subject: RE: byte order?


oh man. You don't have a magic fix? Now I have to do some real work. :-)

Do you have access to both a sparc and a linux box? If not, let me know and
I'll try it the other way (generate a dump on a sparc and see if fails on
the linux box).... and if you are making me do more work, I guess I could
also step through the code and find out exactly where ArgusReadStreamSocket
is bugging out.

If you do have access to a sparc, I'll try to pare down the file and send it
to you. In its current form, the file is only a couple orders of magnitude
too big to email.

On a side note, if you do a 'ra -r *.gz -', a pclose (or wait3) doesn't
happen so the gzips stick around as zombies until the process exits.

Walter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20001206/98d0efe3/attachment.html>