<< What it is? What the difference is ... >> >From the earliest, data fields have been padded with ASCII [032] "soft" spaces, primarily to align data structures. Since data consumers expected to be able to READ the output, early 'garbage-out' teams developed space-stripping routines as soon as the 'garbage in' teams went off-shift.
The 'hard' space represents an early compromise between the two teams; found on many of the dedicated word processors of the 1970s (and, if memory serves, the original intent for the mapping [Alt]-255 on the original IBM Model 5150 keyboard in 1980). But ASCII is a seven-bit specification defining characters 0-127, predating the PC era. The eight-bit processor made character positions 128-255 available to anyone with a dream or a language not-English; so how CHR(255) displays and/or prints on your system depends on your display/output font set. As for your output, how CHR(255) is interpreted at the receiving end depends on whether the agency in question insists on straight-ASCII data; or if not, whether they receive a CHR(255) as what you intend. Hope this helps. bruce/safesectors > -------- Original Message -------- > Subject: [RBASE-L] - Re: Stripping "blanks" off the end of file lines > From: "Heffelfinger, Duane" <[email protected]> > Date: Sun, March 08, 2009 9:36 pm > To: [email protected] (RBASE-L Mailing List) > > > Dennis or others, > > > > Can you expand a little bit further on the hard space? What it is? What the > difference is between a hard and soft space? > > > > When I see a file with CHAR(255) it produces this character (ΓΏ) when I view > the file. Is that expected? Will the IRS computers accept this as a space? > > > > I have another method that I've used for a very long time by placing a > character at position 513, then stripping it using another piece of software > I developed. > > > > This year I've added the state data to the irs record and would consider > changing to something purely Rbase if I could get it to pass the irs computer > system. > > > > Thanks for any input. > > > > Duey > > > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath > Sent: Wednesday, February 25, 2009 3:57 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - Re: Stripping "blanks" off the end of file lines > > > > You don't have to work that hard. > > > > Build up your text string and then use my sput suggestion to drop a hard > space at position 255 and you are done! > > It is dead simple. You will wind up with soft blanks with a hard blank at > the end. RBASE automatically fills a string with spaces when you sput beyond > the length of the string. > > > > Example: > > Set var vtmp = 'xxx' > > Set var vtmp = (SPUT(.vTmp,char(255),512)) > > > > This will create a string of 3 x's followed by 508 spaces followed by a hard > space. > > > > > > Dennis > > > > ________________________________ > > From: [email protected] [mailto:[email protected]] On Behalf Of Gray, Damon > Sent: Wednesday, February 25, 2009 3:47 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - Re: Stripping "blanks" off the end of file lines > > > > I believe I can make this work, because the last data element for each > employee record is at position 489. thus I can append the required hard > blanks with SPUT at position 490 to get the required 512 length. > > > > You have all be VERY helpful ... as always! ;-) > > > > > > > > ________________________________ > > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Wednesday, February 25, 2009 1:38 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - Re: Stripping "blanks" off the end of file lines > > > > Oh wow, if Dennis is right then that would be a problem.... If this is a > fixed-length file, with everything in the same "columns", then you could > create 2 variables of 250 each and then concatenate them together. But if > the individual data elements are variable in length then that wouldn't work > ... > > Karen > > > > > > > > Damon, > > I just checked the docs. > > SFIL only works to 500 characters! > > > > Dennis
