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?
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.
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
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.
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.
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.
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
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.
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.
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.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.