Good point. I use set symbols for unprintable characters. Like: &TAB SETC BYTE(05)
VAR DC C'This has a&TAB. tab in it.' -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of David Bond > Sent: Tuesday, February 21, 2012 2:13 PM > To: [email protected] > Subject: Re: FLOWASM enhancement thought > > On Tue, 21 Feb 2012 13:53:19 -0600, McKown, John wrote: > >Me again. With a weird UNIX vi mindset thought. It might be > nice if FLOWASM > could replace TABS (0x05) in my source, which are not in a > string, with a > blank. If it weren't for the "not in a string", it would be a > simple TR. I'm > thinking that it would likely be easiest to simply do a loop, > looking at > each character in the buffer and replacing it with a blank, > unless within a > string. Is there any reason why this would cause a problem? > > The "not in a string" part is tricky with the HLASM language. > An apostrophe > does not start a string if it is part of an attribute > reference (e.g. L'), > nor if it is in the remarks field. > > Why not simply replace all tabs with blanks? Anyone foolish > enough to use > tab characters in strings gets what they deserve if they ever > transfer the > source. > > David > >
