Some of these things might be useful behaviors in specific situations but are bizarre as defaults (or in the case of 3.3, apparently, as the *only* behavior).
I knew the basic behavior of the ISPF editor but was not aware of the behavior you describe. (I use it for source code editing, mostly FB 80 assembler or JCL, so I never have problems with the subtleties you describe.) *Sounds* to me like one of those "it works this way because it was convenient to my internal logic" implementations. Sigh. I guess perhaps it is literally "preserve the existing line length, whatever it is." Possibly someone wrote a requirement "if there are trailing blanks, don't delete them, preserve the original length" and the programmer focused on a literal interpretation of that last phrase. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, May 01, 2013 10:36 AM To: [email protected] Subject: Re: Trailing blanks in VB dataset On Wed, 1 May 2013 07:43:42 -0400, Charles Mills wrote: >A profile option for the ISPF editor. PRESERVEBLANKS or something like that. > PRESERVE, simply, IIRC. And (as documented) it preserves not trailing blanks but line legths. If you insert characters it deletes trailing blanks; if you delete characters it adds trailing blanks to compensate. I wonder who requested that. >I am surprised that ISPF 3.3 would do that, but try IEGENER in batch. I >would be stunned if it does that. > ISPF 3.3 has done that for 30 years in my experience. And worse: it even removed trailing blanks copying VB to VB. IEBGENER is your friend. >A SITE option for FTP. PRESERVEBLANKS or something like that. Or, FTP to a UNIX file. FTP is more honest in that case. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
