How can one correctly input big and little endian hex representations?

[art297]

The following is what I've tried thus far:

data _null_;

  filename='c:\art\file1.dat';

  file dummy filevar=filename recfm=f lrecl=1;

  do i=1 to 24 ;

    input char $hex2. +1 @;

    put char $char1. ;

  end;

  input;

cards;

FF D8 FF E0 17 00 4A 46 49 46 00 01 01 01 00 60 00 60 00 00 FF E1 5C 1C

;

data want;

  infile 'c:\art\file1.dat';

  input;

  x=input(substr(_infile_,5,2),pibr4.);

  y=input(substr(_infile_,5,2),pib4.);

run;

I would have expected x to have a value of 23 and y to have a value of 5888, but they both get a value of 23.

What am I doing wrong?

[Tom]

Art -

I do not think that the PIBR informat does what you want. From reading the man page I cannot figure out what it is supposed to do.

You should use the REVERSE function to change the byte order.  Also make your informat length match your data length.

data _null_;

  input x $hex4. ;

  front = input(x,pib2.);

  back = input(reverse(x),pib2.);

  put x= hex4. front= back= ;

cards;

0100

1700

run;

x=0100 front=1 back=256

x=1700 front=23 back=5888

[art297]

Tom,

Reverse is definitely a possibility and I am currently rewriting the code accordingly to see if it will correct the problem.  It is a bit late, already, thus I probably won't get to test it until tomorrow morning.

[DLing · Accepted solution]

I ran the above code on Intel PC, Win XP, SAS 9.1.3, and both x and y are 23.

I think on Intel machines, SAS informat of pib4. (native format) and pibr4. (intel format) are the same so x and y have the same value.

If i use s370fpib2. this switches to a different endian from the Intel PC, and generates 5888.

[art297]

Using the s370fpipW informat, where applicable, solved all of my problems.  The data structure I am working on specifies whether numbers are represented in big or little endian form.  Interestingly, wnen trying to use the Window's Explorer in XP to change a pictures title, it changed the from from little to big endian (along with totally messing up the industry standards for the format).  I'll post my current code, shortly, in the thread that is actually dealing with the whole solution (see: http://communities.sas.com/message/107245#107245 ).

Tom's suggestion for using the reverse function was definitely also a possibility, but required the code to be a lot messier.

[FriedEgg]

Hi Art,

Very good work so far.  Here is a great reference point for your topic:

http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a001258728.htm

[art297]

Thanks, but I had already read that, yet didn't discover (realize) the answer until DLing had recommended trying the s370fpib2 informat.  Once I correct all of the code and get it running on an XP, I'll have to see if it works the same on all other systems.

[FriedEgg]

Yes it is a common issue, you can read about it more it is commonly referred to as the NUXI problem, I beleive.  It is because of the particularities of the system running to code and what that systems endianess is.

[DLing]

Dealing with endian-ness is no fun, actually it's a royal pain in the rear.  We have IBM mainframes, Solaris UNIX mid-range servers and Intel PC's.  You need to know the endian of the data as well as the endian of the machine you are running on to pick the right formats/informats.  Most people (rightly so) don't want to care about how machines store numbers.  Those that grew up accessing databases never had to worry about data representation and are shocked that this is even necessary.