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.)
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.
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
----- Original Message -----
From: "IBM Mainframe Assembler List"
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
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.
Senior Application Architect
On 2016-10-17 15:11, robi...@dodo.com.au wrote:
Won't a TR followed by a PACK do this?
Email sent using Dodo Webmail