Does anyone have any performance data on the SRST (Search String) instruction?  
Recently I read it was more efficient than TRT but I didn't see any specifics. 

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Tony Thigpen
Sent: Tuesday, October 18, 2016 9:14 AM
Subject: Re: converting character to packed


There are inherent problems with using TR. The following are examples of valid 
input that has to be handled correctly. I have used the "^" 
character to indicate blanks.

Properly identifying the decimal place and the number of trailing digits is 
critical before the data is stored in a packed field and it can not be handled 
by any simple TR instruction.

Sign identification can also be an issue since there is no standard of putting 
it first or last.

(And as others have said, the TR and TRT instruction are cpu hogs when compared 
to a simple loop though the data.)

Tony Thigpen

Michael Stack wrote on 10/18/2016 09:59 AM:
> This is by far the easiest, if not the simplest, solution. There was, once 
> upon a time, an example in an IBM pub, but for the life of me, I cannot 
> recall where. Still, one TR will do it; create a result field whose bytes are 
> indexes into the source value treated as a TR table such that only the 
> numeric values are selected. Easy. Thanks for reminding me, Robin.
> Mike
> At 01:34 AM 10/18/2016, you wrote:
>> Using TR in a different way omits the commas and decimal point, sign,
>> and any other funny characters.
>> To do this, you swap the roles of the translate table and the string
>> being translated.
>> ----- Original Message -----
>> From: "IBM Mainframe Assembler List"
>> To:
>> Cc:
>> Sent:Mon, 17 Oct 2016 16:24:18 -0400
>> Subject:Re: converting character to packed
>> The TR command would leave all the non-numeric characters in the
>> data, translated as you specified, so you'd have to have a technique
>> to pass through the result to remove them. A TRT instruction would
>> help you find the non-numeric characters, but in this case it would be
>> considerably slower in execution than the character by character loop
>> approaches suggested.
>> If the original manually-entered data is not edited as it's entered,
>> there could be many other characters besides "$",",","." and EBCDIC
>> numeric characters in it. That's something TRT could check for.
>> Gary Weinhold
>> Senior Application Architect
>> __________
>> On 2016-10-17 15:11, wrote:
>> Won't a TR followed by a PACK do this?
>> Email sent using Dodo Webmail

Reply via email to