Mark, That is even more elegant than my solution. One does not have to do anything to pad the lines!!!
Great stuff Dennis ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Mark Lindner Sent: Wednesday, February 25, 2009 4:29 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Stripping "blanks" off the end of file lines what we do is build up the string the same way but when it is output from code use a write with the width option ie out [FILENAME] loop to process/write data write .vdata=512 end of loop out screen and that seems to work just fine and creates lines that are the right length Mark Lindner Lindner & Associates PC 254 Second Ave Needham MA 02494 781 247 1100 Fax 781 247 1143 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, February 25, 2009 4:24 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Stripping "blanks" off the end of file lines Damon: 32 is a "soft" blank. 255 is a "hard" blank, so try that one. Karen I'm working an issue in which our W2 files are being rejected by the U.S. government because the "records" are not 512 bytes long. After burning a couple of hours on investigative techniques I won't bore you with or embarrass myself with, I'll tell you that indeed the records are NOT 512 bytes, but are 500 bytes. The last 12 bytes of each line (required by the specification) are being stripped off at some point when before the file is written to the disc. I start with this routine: SET VAR vBLANK = (CHAR(32)) CLEAR VAR vRECORD SET VAR vRECORD TEXT SET VAR vRECORD = (SFIL(.vBLANK,512)) And then use SPUT to place the various data items in their required position. The last piece written is a "P" at position 500. Positions 501 - 512 should be blanks, as created by the SFIL above, but instead are being stripped off. Any idea why?
