LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous (more recent) messageNext (less recent) messagePrevious (more recent) in topicNext (less recent) in topicPrevious (more recent) by same authorNext (less recent) by same authorPrevious page (July 2000, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Tue, 11 Jul 2000 16:12:04 GMT
Reply-To:   sashole@mediaone.net
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   Paul Dorfman <paul_dorfman@HOTMAIL.COM>
Subject:   Re: What is EBCDIC text?
Comments:   To: icj808@USWEST.NET
Content-Type:   text/plain; format=flowed

paula <icj808@USWEST.NET>, in part, wrote:

>When converting data from fixed EBCDIC format to be read int SAS v8 >NT, I >have two choices for record format: variable or fixed, and 4 >choices for >data format: ASCII, binary, EBCDIC text, and another >one. Does anyone know >what EBCDIC is? I thought it is to preserve >the original EBCDIC format, >but under V8NT, it reacts as if a >regular ASCII format. I am not sure >EBCDIC text is any different >EBCDIC. Any advice is appreciated.

Paula,

EBCDIC stands simply for Extended Binary-Coded-Decimal-Interchange Code used to represent characters internally in the real computer. The binary representations of a character are different between EBCDIC and ASCII. For instance, the capital letter 'A' is represented in the following manner in the two collating schemes:

Collating Hex Binary sequence number ----------------------------------------- EBCDIC 193 C1 11000001 ----------------------------------------- ASCII 65 41 01000001 -----------------------------------------

As you see, they are quite different. But this is only half the trouble. As if it were not enough, real computers use bytes in forward order to represent strings, whilst Intel-based stuff (and VAX for whatever reason) has the bytes reversed. In other words, looking at '0100'x, you would naturally expect this hex constant to be a 16-radix representation of the number 256 because

01 * 16**1 + 00 * 16**0 = 256,

right? And in EBCDIC, it is right:

5 data _null_; 6 n = input('0100'x, pib2.); 7 put n=; 8 run; n=256

However, executing the same piece under Windoze returns not 256 but just 1, because the PC reads the bytes in reverse:

00 * 16**1 + 01 * 16**0 = 1.

This is the main reason why we need S370* (in)formats. Using S370FPIB2. instead of PIB2. above will return the same result on any computer. Additionally, S370* recode individual bytes from one collating system to another. Hence the rule of unloading flat files from the real computer:

1) Unload it as *binary*, that is, 'as is', without conversions of any kind. 2) On the PC side, read it letting $EBCDIC (instead of $CHAR) and the S370* informat family handle the conversions.

Works every time.

Kind regards, ====================== Paul M. Dorfman Jacksonville, Fl ======================

________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


Back to: Top of message | Previous page | Main SAS-L page