Re: converting character to packed

[Robin Vowels]

From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>

Sent: Monday, October 24, 2016 5:49 AM



On 2016-10-23, at 06:05, robi...@dodo.com.au wrote:


Monetary fields tend to have the finny characters in known positions,
commas (or periods)every third position. The decimal point (period or
comma) also is in a fixed position.All these are in fixed positions
relative to the least significant digit of the amount.
 

But the currency symbol floats unless you have leading zeroes for
a fixed width.


A drifting currency symbol, if it exists, can be dealt with
trivially with TRT.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: converting character to packed

[Paul Gilmartin]

On 2016-10-23, at 06:05, robi...@dodo.com.au wrote:

> Monetary fields tend to have the finny characters in known positions,
> commas (or periods)every third position. The decimal point (period or
> comma) also is in a fixed position.All these are in fixed positions
> relative to the least significant digit of the amount.
>  
But the currency symbol floats unless you have leading zeroes for
a fixed width.

-- gil

Re: converting character to packed

[robin51]

Monetary fields tend to have the finny characters in known positions,
commas (or periods)every third position. The decimal point (period or
comma) also is in a fixed position.All these are in fixed positions
relative to the least significant digit of the amount.

- Original Message -
From: "IBM Mainframe Assembler List" 
To:
Cc:
Sent:Sat, 22 Oct 2016 14:46:47 -0600
Subject:Re: converting character to packed

 On 2016-10-18, at 13:19, Tony Harminc wrote:

 > On 18 October 2016 at 02:34,  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.
 > 
 > This was the classic way to reverse a string, long before the
 > existence of the MVCIN instruction.
 > 
 That can rearrange characters in a string and even eliminate "funny"
 characters, but I believe you need to know a priori where the funny
 characters are to omit their positions from the string being
translated.

 -- gil
Email sent using Dodo Webmail

Re: converting character to packed

[Paul Gilmartin]

On 2016-10-18, at 13:19, Tony Harminc wrote:

> On 18 October 2016 at 02:34,   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.
> 
> This was the classic way to reverse a string, long before the
> existence of the MVCIN instruction.
>  
That can rearrange characters in a string and even eliminate "funny"
characters, but I believe you need to know a priori where the funny
characters are to omit their positions from the string being translated.

-- gil

Rif: Re: converting character to packed

[aldo . crosio]

The first question I must ask is:
what is the main language?
the string to be converted is fixed or variable length?
whether before or after the string?
the currency above, following the string and, contiguous or separated?
there is a need to vary parametrically decimal point or currency?

 In case of cobol what is the arrival picture?
For example:
01 output   S9(017)V9(2)  COMP-3.

It will correct answers to the strings that follow?


"^" character to indicate blanks.
.. 1 2 3 4 5 6 7 8 9 0’
$1,234.56   x’0123456c’
1,234.56x’0123456c’
-1,234.56   x’0123456d’
1,234,567.89x’00123456789c’
1234567,89  x’00123456789c’
-1234567,89 x’00123456789d’
123.4.567,89error
123456789   x’12345678900c
1,234,567.8934^^x’00123456789c’
^^^1234.56  x’0123456c’
$^^^1234.56 x’0123456c’
-^^^1234.56 x’0123456d’
^^^1234.56- x’0123456d’


Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute nel 
presente messaggio, corredato dei relativi allegati, sono strettamente 
riservate ed a uso esclusivo dei destinatari. Qualora Le fosse pervenuto per 
errore, La invitiamo ad eliminarlo immediatamente, dandocene gentilmente 
comunicazione. Grazie.
 ***  ***  *** 

Re: converting character to packed

[Tony Harminc]

On 18 October 2016 at 02:34,   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.

This was the classic way to reverse a string, long before the
existence of the MVCIN instruction.

Tony H.

Re: converting character to packed

[Martin Truebner]

Tony,

>> here are inherent problems with using TR. The following are examples of 
valid input that has to be handled correctly. 

I am fully aware of all these- and i posted this before 

I posted my solution with the explicit stated assumption- this is a
fields produced/checked/verified by a computer (such as a field in a
listing that needs further processing). 

I would never ever dare to use such code if the data was entered by a human. 

Martin

Re: converting character to packed

[Gary Gregory]

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
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: converting character to packed

Michael,

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.
$1,000.00^
1,000.00^^
+1,000.00^
-1,000.00^
1,000.00-^
^^^1000.00
1000^^
1000.0
1000.000^^

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, robi...@dodo.com.au wrote:
>>
>> Won't a TR followed by a PACK do this?
>> Email sent using Dodo Webmail
>
>

Re: converting character to packed

[Michael Stack]

True, Tony - this solution was for a fixed format.

At 09:14 AM 10/18/2016, you wrote:
>Michael,
>
>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.
>$1,000.00^
>1,000.00^^
>+1,000.00^
>-1,000.00^
>1,000.00-^
>^^^1000.00
>1000^^
>1000.0
>1000.000^^
>
>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, robi...@dodo.com.au wrote:
>>>
>>>Won't a TR followed by a PACK do this?
>>>Email sent using Dodo Webmail
>>

Re: converting character to packed

[Tony Thigpen]

Michael,

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.

$1,000.00^
1,000.00^^
+1,000.00^
-1,000.00^
1,000.00-^
^^^1000.00
1000^^
1000.0
1000.000^^

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, robi...@dodo.com.au wrote:

Won't a TR followed by a PACK do this?
Email sent using Dodo Webmail

Re: converting character to packed

[Michael Stack]

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, robi...@dodo.com.au wrote:
>
> Won't a TR followed by a PACK do this?
>Email sent using Dodo Webmail

Re: converting character to packed

[Richard Kuebbing]

That would be interesting code to see

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of robi...@dodo.com.au
Sent: Tuesday, October 18, 2016 2:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: converting character to packed

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, robi...@dodo.com.au wrote:

 Won't a TR followed by a PACK do this?
Email sent using Dodo Webmail


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you

Re: converting character to packed

[Tony Thigpen]

Martin,

"the data input was manual into..." means that someone actually typed 
the data into a field. The data is unedited and may contain mistakes. 
The data can not be trusted.


In this case, he needs a complete edit process either before are during 
the convert-to-packed process.


Tony Thigpen

Martin Truebner wrote on 10/18/2016 02:47 AM:

Greg,


the data input was manual into a 20 byte character field including $
signs, commas, and periods (ex. $13,532,908.01)


i do not understand the word "manual" in this sentence (english is not
my native language) - I assume a meaning of "prepared"
"edited", "printed into", "manual entered with verification of format"
- something that made sure it is the way it must be.

If this is really the case then


 convert to pack decimal for additional reporting


could be easy accomplished with this

first we eliminate the leading $ sign
TR   SOURCE,TR_KILL_DOLLAR
MVC  FIELD15,PATTERN
TR   FIELD15,SOURCE-1
PACK PACKED,FIELD15

PATTERN   DC   AL1(1,3,4,5,7,8,9,11,12,13,15,16,17,19,20)
FIELD15   DS   CL15  field without dollar,comma and no period
PACKEDDS   PL8

TR_KILL_DOLLAR   DC  256AL1(*-TR_KILL_DOLLAR)
   ORGTR_KILL_DOLLAR+C'$'
   DC C' '
   ORG

will prepare the data from the field SOURCE as packed decimal with
two decimals in fields PACKED.

--
even with extra overhead for a TR, I do believe it is the fastest
solution.

Rif: Re: converting character to packed

[aldo . crosio]

The first question I must ask is:
what is the main language?
the string to be converted is fixed or variable length?
whether before or after the string?
the currency above, following the string and, contiguous or separated?
there is a need to vary parametrically decimal point or currency?

Furthermore:
I believe that you have the need to have a multi-function editing routine.
He also never thought of using, for the calculation and / or alignment of
floating point fields?

in particular a similar function:
The edited numeric string can contain the sign (first or last significant
position) the decimal separator and one or more separators  properly
positioned


Call is like:
Workink-storage.
01  HDNUM-PKT.
88   HDNUM__STRIP_NUM   VALUE   1.
88   HDNUM__STRIP   VALUE   2.
88   HDNUM__TRIMVALUE   3.
88   HDNUM__STRIP_NUM_TRIM  VALUE   4.
88   HDNUM__STRIP_TRIM  VALUE   5.
88   HDNUM__STR_HFP VALUE   6.
88   HDNUM__VSTR_HFPVALUE   7.
88   HDNUM__BIN_HFP VALUE   8.
88   HDNUM__B32_HFP VALUE   8.
88   HDNUM__B64_HFP VALUE   9.
88   HDNUM__HFP_STR VALUE  10.
88   HDNUM__HFP_STRRVALUE  11.
88   HDNUM__HEX_H   VALUE  12.
88   HDNUM__HEX_W   VALUE  13.
88   HDNUM__HEX_D   VALUE  14.
88   HDNUM__NUMERO  VALUE  15.
88   HDNUM__OPTION-TRAILING VALUE  16.
88   HDNUM__OPTION-LEADING  VALUE  17.
88   HDNUM__OPTION-BOTH VALUE  18.
88   HDNUM__OPTION-COMPRESS VALUE  19.
88   HDNUM__OPTION-ALL  VALUE  20.
88   HDNUM__COMPRESSVALUE  21.
88   HDNUM__ALL VALUE  22.
88   HDNUM__NUMERO_FIX  VALUE  23.
88   HDNUM__VSTR_HFP_CLOB   VALUE  24.
88   HDNUM__HFPS_STRVALUE  25.
88   HDNUM__HFPS_STRR   VALUE  26.
88   HDNUM__DECIMAL VALUE  27.
88   HDNUM__STR_HFP_CLOBVALUE  28.
88   HDNUM__LSPALL  VALUE  29.
88   HDNUM__NUMERIC VALUE  30.
88   HDNUM__GRAFIC  VALUE  31.
88   HDNUM__STRHFP_2VALUE  32.
88   HDNUM__VSTRHFP_2   VALUE  33.
02 UNIEDIT-SUBFUN   PIC S9(04) BINARY.
02 UNIEDIT-CODES.
   04 UNIEDIT_FCPIC S9(04) BINARY.
   04 UNIEDIT_FSPIC S9(04) BINARY.
   04 UNIEDIT_EXTRA_FNCTPIC X(4).
  88  HDNUM_VIRGOLA VALUE X'FFEF6B00'.
  88  HDNUM_VIRGOLA_X   VALUE X'FFEF6B6B'.
  88  HDNUM_PUNTO   VALUE X'FFEF4B00'.
  88  HDNUM_PUNTO_X VALUE X'FFEF4B4B'.
  88  HDNUM_ONLY_ABEND  VALUE X'FFEF'.
   04 UNIEDIT_EXTRA_1  REDEFINES UNIEDIT_EXTRA_FNCT.

  06  FILLERPIC X(2).
  88  HDNUM_ABEND   VALUE X''.
  06  FILLERPIC X(2).

01  LS-CAMPO-GRAFPIC X(48).
01  XML-P2-LEN   PIC S9(8) BINARY.
01  HFP-RESP.
02  HFP-STAT   PIC  S9(9)   BINARY.
02  HFP-SEGNO  PIC  S9(9)   BINARY.
02  HFP-DATI-HFP.
04  HDRESP-RISULTATO   COMP-2.
04  HDRESP-INT-18  PIC  S9(18)  BINARY.
04  HDRESP-INTERO  PIC  S9(18)  BINARY.
04  HDRESP-DECIMALEPIC  S9(18)  BINARY.
04  HDNUM-STRLGTH  PIC  S9(4)   BINARY.
04  HDNUM-STR.
05  HDNUM-STRCHAR  PIC  X
   OCCURS1 TO 48
   DEPENDING ON HDNUM-STRLGTH.

Procedure division.
MOVE your-string to LS-CAMPO-GRAF TO LEN
MOVE LENGTH  OF LS-CAMPO-GRAF TO LEN
SET  HDNUM__GRAFIC  TO   TRUE
CALL UNI_EDIT   USING HDNUM-PKT
LEN
LS-CAMPO-GRAF
HFP-RESP

In particolare:

In  HDRESP-RISULTATO   result in floating-point ecc….



Aldo Crosio
tel:   051-4991812 /3488858416
fax:  051-6255762


CSE Consorzio Servizi Bancari
Società consortile a responsabilità limitata
Via Emilia n. 272
40068-San Lazzaro di Savena (BO)


Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute nel 
presente messaggio, corredato dei relativi allegati, sono strettamente 
riservate ed a uso esclusivo dei destinatari. Qualora Le fosse pervenuto per 
errore, La invitiamo ad eliminarlo immediatamente, dandocene gentilmente 
comunicazione. Grazie.
 ***  ***  *** 

Re: converting character to packed

[Martin Truebner]

Greg,

>> the data input was manual into a 20 byte character field including $
>> signs, commas, and periods (ex. $13,532,908.01) 

i do not understand the word "manual" in this sentence (english is not
my native language) - I assume a meaning of "prepared"
"edited", "printed into", "manual entered with verification of format"
- something that made sure it is the way it must be. 

If this is really the case then

>>  convert to pack decimal for additional reporting

could be easy accomplished with this   

first we eliminate the leading $ sign
   TR   SOURCE,TR_KILL_DOLLAR
   MVC  FIELD15,PATTERN   
   TR   FIELD15,SOURCE-1
   PACK PACKED,FIELD15

PATTERN   DC   AL1(1,3,4,5,7,8,9,11,12,13,15,16,17,19,20)
FIELD15   DS   CL15  field without dollar,comma and no period
PACKEDDS   PL8 

TR_KILL_DOLLAR   DC  256AL1(*-TR_KILL_DOLLAR)
  ORGTR_KILL_DOLLAR+C'$'
  DC C' '
  ORG

will prepare the data from the field SOURCE as packed decimal with
two decimals in fields PACKED.

--
even with extra overhead for a TR, I do believe it is the fastest
solution. 

Re: converting character to packed

[robin51]

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, robi...@dodo.com.au wrote:

 Won't a TR followed by a PACK do this?
Email sent using Dodo Webmail

Re: converting character to packed

[Gary Weinhold]

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

DATAKINETICS | Data Performance & Optimization

Phone:  +1.613.523.5500 x216
Email:  weinh...@dkl.com

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]

Visit us online at www.DKL.com

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



__

On 2016-10-17 15:11, robi...@dodo.com.au wrote:

Won't a TR followed by a PACK do this?

- Original Message -
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Mon, 17 Oct 2016 15:04:52 -0400
Subject:Re: converting character to packed

since it was my original question and thanks for all of the
suggestions, the data input was manual into a 20 byte character field
including $ signs, commas, and periods (ex. $13,532,908.01) and I am
trying to convert to pack decimal for additional reporting on a zOS
MVS machine
Email sent using Dodo Webmail

Re: converting character to packed

[robin51]

Won't a TR followed by a PACK do this? 

- Original Message -
From: "IBM Mainframe Assembler List" 
To:
Cc:
Sent:Mon, 17 Oct 2016 15:04:52 -0400
Subject:Re: converting character to packed

 since it was my original question and thanks for all of the
suggestions, the data input was manual into a 20 byte character field
including $ signs, commas, and periods (ex. $13,532,908.01) and I am
trying to convert to pack decimal for additional reporting on a zOS
MVS machine 
Email sent using Dodo Webmail

Re: converting character to packed

[Greg Gray]

since it was my original question and thanks for all of the suggestions, the 
data input was manual into a 20 byte character field including $ signs, commas, 
and periods (ex. $13,532,908.01) and I am trying to convert to pack decimal for 
additional reporting on a zOS MVS machine.

Re: converting character to packed

[Gary Weinhold]

It all depends on the application requirements; it the data has been previously 
edited/verified to ensure that it conforms to the described pattern, then it is 
most efficient to rely on that verification particularly if the packing routine 
is heavily used.  If the input is directly from a free-form input source, then 
verification would be needed, either in the routine or preceding it.

Gary

Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone:  +1.613.523.5500 x216<tel:+1.613.523.5500%20x216>
Email:  weinh...@dkl.com<mailto:weinh...@dkl.com>

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/>

Visit us online at www.DKL.com<http://www.dkl.com/>

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig>

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



__
On 2016-10-14 12:02, Steve Smith wrote:

Possibly good points, but no one was hired to code a complete solution, and
no one has published specifications.  He wanted some ideas on how to
approach his problem.

Chris Webster's technique is nice, as it shows what can be done in these
modern times if you've cracked open the PoOp since 1979.

sas

On Fri, Oct 14, 2016 at 4:55 AM, Tony Thigpen 
<t...@vse2pdf.com><mailto:t...@vse2pdf.com> wrote:



All the examples and comments (so far) don't even come close to what may
be needed. The assumption so far has been that the input has exactly 2
numbers after the decimal point and that the number is positive.

A true "de-edit" routine needs to take into considerations:
1) The decimal point may or may not exists within the entered data.
2) The number of digits after the decimal point is variable.
3) What type of rounding or truncation is needed if there are too many
digits after the decimal point.
4) There may be a "-" (minus sigh) either before or after the number.
5) There are other ways besides a "-" that may indicate that the number is
negative. (I.e., "CR" or even a par of "()" characters around the number.)
6) There are different monetary indicators other than the US $ sign.
7) Is there any type of character validation needed? (I.e, what do you do
if something other than "0-9,-,+,commna,decimal_point" is found in the data?

And those items are just what I can think of off the top of my head. There
are sure to be other items to consider.

Tony Thigpen


Webster, Chris wrote on 10/13/2016 06:30 PM:



A modified version for current hardware.  The storage references are kept
to a minimum.

   LGHI 11,15 max digits
   LGHI 15,0

IP010DS0H
   LLGC 1,0(,8)
   CLIJL 1,C'0',IP020   < zero
   CLIJH 1,C'9',IP020   > nine
   NILL 1,15 clear 'F'
   AGR 15,1
   SLLG 15,15,4 ready for next digit
   JCT  11,IP020
   JIP030 too many chars

IP020DS0H
LAR8,1(,R8)  next character
JCT  R9,IP010

IP030DS0H
   AGHI 15,X'C' sign
   STG 15,0(10)

...chris.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSER
V.UGA.EDU] On Behalf Of Ze'ev Atlas
Sent: October-13-16 9:41 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU<mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Subject: Re: converting character to packed

ClassicWe sould make a.macro out of it  :)ZA

Sent from Yahoo Mail on Android

  On Thu, Oct 13, 2016 at 12:17 PM, Richard Rogers<
rcrogers@gmail.com<mailto:rcrogers@gmail.com>> wrote:   Just a stab, 
FWIW
*  R8 ==> INCOMING FIELD
*  R9  =  INCOMING FIELD LENGTH
*  R10 ==> PL8 PACKED DECIMAL RESULT
*R11  =  WORK - DIGIT COUNT
*R12 ==> CL16 - WORK - SAVE DIGITS INCMPACK DS0H
INCOMING PACK
SRR11,R11  DIGIT COUNT
LAR12,IPWORK
IP010DS0H
CLI  0(R8),C'0'  Q-DIGIT
BLIP020  N
CLI  0(R8),C'9'  INSURANCE - NO CHARS > '9'
BHIP020
MVC  0(1,R12),0(R8)  SAVE DIGIT
LAR11,1(,R11) DIGIT COUNT
CHR11,=H'16'  Q-TOO MANY DIGITS
BNL  IP030  Y-HAVE ALL WE CAN HANDLE
LAR12,1(,R12) NEXT DIGIT SAVE AREA
IP020DS0H
LAR8,1(,R8)  NEXT INCOMING BYTE
BCT  R9,IP010
IP030DS0H
BCTR  R11,R0ADJUST FOR 'EX'
EXR11,IPPACK
*PACK  0(8,R10),IPWORK(*-*)
*R10 ==> PL16 PACKED DECIMAL
*TTD - EXIT INCOMING PACK ROUTINE, EG, B  CONTINUE ON IPPACK
PACK  0(8,R10),IPWORK(*-*) IPWORK  DSCL16

-Original Messag

Re: converting character to packed

[Steve Smith]

Possibly good points, but no one was hired to code a complete solution, and
no one has published specifications.  He wanted some ideas on how to
approach his problem.

Chris Webster's technique is nice, as it shows what can be done in these
modern times if you've cracked open the PoOp since 1979.

sas

On Fri, Oct 14, 2016 at 4:55 AM, Tony Thigpen <t...@vse2pdf.com> wrote:

> All the examples and comments (so far) don't even come close to what may
> be needed. The assumption so far has been that the input has exactly 2
> numbers after the decimal point and that the number is positive.
>
> A true "de-edit" routine needs to take into considerations:
> 1) The decimal point may or may not exists within the entered data.
> 2) The number of digits after the decimal point is variable.
> 3) What type of rounding or truncation is needed if there are too many
> digits after the decimal point.
> 4) There may be a "-" (minus sigh) either before or after the number.
> 5) There are other ways besides a "-" that may indicate that the number is
> negative. (I.e., "CR" or even a par of "()" characters around the number.)
> 6) There are different monetary indicators other than the US $ sign.
> 7) Is there any type of character validation needed? (I.e, what do you do
> if something other than "0-9,-,+,commna,decimal_point" is found in the data?
>
> And those items are just what I can think of off the top of my head. There
> are sure to be other items to consider.
>
> Tony Thigpen
>
>
> Webster, Chris wrote on 10/13/2016 06:30 PM:
>
>> A modified version for current hardware.  The storage references are kept
>> to a minimum.
>>
>> LGHI 11,15 max digits
>> LGHI 15,0
>>
>> IP010DS0H
>> LLGC 1,0(,8)
>> CLIJL 1,C'0',IP020   < zero
>> CLIJH 1,C'9',IP020   > nine
>> NILL 1,15 clear 'F'
>> AGR 15,1
>> SLLG 15,15,4 ready for next digit
>> JCT  11,IP020
>> JIP030 too many chars
>>
>> IP020DS0H
>>  LAR8,1(,R8)  next character
>>  JCT  R9,IP010
>>
>> IP030DS0H
>> AGHI 15,X'C' sign
>> STG 15,0(10)
>>
>> ...chris.
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSER
>> V.UGA.EDU] On Behalf Of Ze'ev Atlas
>> Sent: October-13-16 9:41 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: converting character to packed
>>
>> ClassicWe sould make a.macro out of it  :)ZA
>>
>> Sent from Yahoo Mail on Android
>>
>>On Thu, Oct 13, 2016 at 12:17 PM, Richard Rogers<
>> rcrogers@gmail.com> wrote:   Just a stab, FWIW
>> *  R8 ==> INCOMING FIELD
>> *  R9  =  INCOMING FIELD LENGTH
>> *  R10 ==> PL8 PACKED DECIMAL RESULT
>> *R11  =  WORK - DIGIT COUNT
>> *R12 ==> CL16 - WORK - SAVE DIGITS INCMPACK DS0H
>> INCOMING PACK
>>  SRR11,R11  DIGIT COUNT
>>  LAR12,IPWORK
>> IP010DS0H
>>  CLI  0(R8),C'0'  Q-DIGIT
>>  BLIP020  N
>>  CLI  0(R8),C'9'  INSURANCE - NO CHARS > '9'
>>  BHIP020
>>  MVC  0(1,R12),0(R8)  SAVE DIGIT
>>  LAR11,1(,R11) DIGIT COUNT
>>  CHR11,=H'16'  Q-TOO MANY DIGITS
>>  BNL  IP030  Y-HAVE ALL WE CAN HANDLE
>>  LAR12,1(,R12) NEXT DIGIT SAVE AREA
>> IP020DS0H
>>  LAR8,1(,R8)  NEXT INCOMING BYTE
>>  BCT  R9,IP010
>> IP030DS0H
>>  BCTR  R11,R0ADJUST FOR 'EX'
>>  EXR11,IPPACK
>> *PACK  0(8,R10),IPWORK(*-*)
>> *R10 ==> PL16 PACKED DECIMAL
>> *TTD - EXIT INCOMING PACK ROUTINE, EG, B  CONTINUE ON IPPACK
>> PACK  0(8,R10),IPWORK(*-*) IPWORK  DSCL16
>>
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSER
>> V.UGA.EDU]
>> On Behalf Of Greg Gray
>> Sent: Thursday, October 13, 2016 08:22
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: converting character to packed
>>
>> I have character data in a field (ex. $13,501,298.01) and I need to
>> remove the special characters and convert field from char to packed?  Can
>> someone give a suggestion on the best and simplest way to do it, thanks?
>>
>>
>>
>>


-- 
sas

Re: converting character to packed

[Tony Thigpen]

All the examples and comments (so far) don't even come close to what may 
be needed. The assumption so far has been that the input has exactly 2 
numbers after the decimal point and that the number is positive.


A true "de-edit" routine needs to take into considerations:
1) The decimal point may or may not exists within the entered data.
2) The number of digits after the decimal point is variable.
3) What type of rounding or truncation is needed if there are too many 
digits after the decimal point.

4) There may be a "-" (minus sigh) either before or after the number.
5) There are other ways besides a "-" that may indicate that the number 
is negative. (I.e., "CR" or even a par of "()" characters around the 
number.)

6) There are different monetary indicators other than the US $ sign.
7) Is there any type of character validation needed? (I.e, what do you 
do if something other than "0-9,-,+,commna,decimal_point" is found in 
the data?


And those items are just what I can think of off the top of my head. 
There are sure to be other items to consider.


Tony Thigpen

Webster, Chris wrote on 10/13/2016 06:30 PM:

A modified version for current hardware.  The storage references are kept to a 
minimum.

LGHI 11,15 max digits
LGHI 15,0

IP010DS0H
LLGC 1,0(,8)
CLIJL 1,C'0',IP020   < zero
CLIJH 1,C'9',IP020   > nine
NILL 1,15 clear 'F'
AGR 15,1
SLLG 15,15,4 ready for next digit
JCT  11,IP020
JIP030 too many chars

IP020DS0H
 LAR8,1(,R8)  next character
 JCT  R9,IP010

IP030DS0H
AGHI 15,X'C' sign
STG 15,0(10)

...chris.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Ze'ev Atlas
Sent: October-13-16 9:41 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: converting character to packed

ClassicWe sould make a.macro out of it  :)ZA

Sent from Yahoo Mail on Android

   On Thu, Oct 13, 2016 at 12:17 PM, Richard Rogers<rcrogers@gmail.com> 
wrote:   Just a stab, FWIW
*  R8 ==> INCOMING FIELD
*  R9  =  INCOMING FIELD LENGTH
*  R10 ==> PL8 PACKED DECIMAL RESULT
*R11  =  WORK - DIGIT COUNT
*R12 ==> CL16 - WORK - SAVE DIGITS INCMPACK DS0H  INCOMING PACK
 SRR11,R11  DIGIT COUNT
 LAR12,IPWORK
IP010DS0H
 CLI  0(R8),C'0'  Q-DIGIT
 BLIP020  N
 CLI  0(R8),C'9'  INSURANCE - NO CHARS > '9'
 BHIP020
 MVC  0(1,R12),0(R8)  SAVE DIGIT
 LAR11,1(,R11) DIGIT COUNT
 CHR11,=H'16'  Q-TOO MANY DIGITS
 BNL  IP030  Y-HAVE ALL WE CAN HANDLE
 LAR12,1(,R12) NEXT DIGIT SAVE AREA
IP020DS0H
 LAR8,1(,R8)  NEXT INCOMING BYTE
 BCT  R9,IP010
IP030DS0H
 BCTR  R11,R0ADJUST FOR 'EX'
 EXR11,IPPACK
*PACK  0(8,R10),IPWORK(*-*)
*R10 ==> PL16 PACKED DECIMAL
*TTD - EXIT INCOMING PACK ROUTINE, EG, B  CONTINUE ON IPPACK  PACK  
0(8,R10),IPWORK(*-*) IPWORK  DSCL16

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Greg Gray
Sent: Thursday, October 13, 2016 08:22
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: converting character to packed

I have character data in a field (ex. $13,501,298.01) and I need to remove the 
special characters and convert field from char to packed?  Can someone give a 
suggestion on the best and simplest way to do it, thanks?

Re: converting character to packed

[Martin Truebner]

None of the solutions presented here does any considering of
commas or points.

The input comes from carbon based units and they are known to need all
kind of helps to get a number correct. 

So my solution would be to check for
-1) just one decimal point and 
-2) commas at every forth position counting from the decimal point to the left. 
 

it could be without decimal point and/or without the commas- but
if there they have to be in the correct position.

so 12345.98 or 12,345.98 or 1,234,598 or 1234 would be valid but

1,23,45.98 or 12.345.98 or 12345.5,98 would not be valid

AND

since commas and points are exchanged in meaning in come countries i
would create code that could easy be adjusted for that.

Martin

Re: converting character to packed

[Webster, Chris]

A modified version for current hardware.  The storage references are kept to a 
minimum.

LGHI 11,15 max digits
LGHI 15,0

IP010DS0H
LLGC 1,0(,8)
CLIJL 1,C'0',IP020   < zero
CLIJH 1,C'9',IP020   > nine
NILL 1,15 clear 'F'
AGR 15,1
SLLG 15,15,4 ready for next digit
JCT  11,IP020
JIP030 too many chars

IP020DS0H
LAR8,1(,R8)  next character
JCT  R9,IP010

IP030DS0H
AGHI 15,X'C' sign
STG 15,0(10)

...chris.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Ze'ev Atlas
Sent: October-13-16 9:41 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: converting character to packed

ClassicWe sould make a.macro out of it  :)ZA

Sent from Yahoo Mail on Android 
 
  On Thu, Oct 13, 2016 at 12:17 PM, Richard Rogers<rcrogers@gmail.com> 
wrote:   Just a stab, FWIW
*      R8 ==> INCOMING FIELD
*      R9  =  INCOMING FIELD LENGTH
*      R10 ==> PL8 PACKED DECIMAL RESULT
*        R11  =  WORK - DIGIT COUNT
*        R12 ==> CL16 - WORK - SAVE DIGITS INCMPACK DS    0H      INCOMING PACK
        SR    R11,R11  DIGIT COUNT
        LA    R12,IPWORK
IP010    DS    0H
        CLI  0(R8),C'0'  Q-DIGIT
        BL    IP020      N
        CLI  0(R8),C'9'  INSURANCE - NO CHARS > '9'
        BH    IP020
        MVC  0(1,R12),0(R8)  SAVE DIGIT
        LA    R11,1(,R11) DIGIT COUNT
        CH    R11,=H'16'  Q-TOO MANY DIGITS
        BNL  IP030      Y-HAVE ALL WE CAN HANDLE
        LA    R12,1(,R12) NEXT DIGIT SAVE AREA
IP020    DS    0H
        LA    R8,1(,R8)  NEXT INCOMING BYTE
        BCT  R9,IP010
IP030    DS    0H
        BCTR  R11,R0    ADJUST FOR 'EX'
        EX    R11,IPPACK
*        PACK  0(8,R10),IPWORK(*-*)
*        R10 ==> PL16 PACKED DECIMAL
*        TTD - EXIT INCOMING PACK ROUTINE, EG, B  CONTINUE ON IPPACK  PACK  
0(8,R10),IPWORK(*-*) IPWORK  DS    CL16

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Greg Gray
Sent: Thursday, October 13, 2016 08:22
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: converting character to packed

I have character data in a field (ex. $13,501,298.01) and I need to remove the 
special characters and convert field from char to packed?  Can someone give a 
suggestion on the best and simplest way to do it, thanks?
  

Re: converting character to packed

[Ze'ev Atlas]

ClassicWe sould make a.macro out of it  :)ZA

Sent from Yahoo Mail on Android 
 
  On Thu, Oct 13, 2016 at 12:17 PM, Richard Rogers 
wrote:   Just a stab, FWIW
*      R8 ==> INCOMING FIELD
*      R9  =  INCOMING FIELD LENGTH
*      R10 ==> PL8 PACKED DECIMAL RESULT
*        R11  =  WORK - DIGIT COUNT
*        R12 ==> CL16 - WORK - SAVE DIGITS
INCMPACK DS    0H      INCOMING PACK
        SR    R11,R11  DIGIT COUNT
        LA    R12,IPWORK
IP010    DS    0H
        CLI  0(R8),C'0'  Q-DIGIT
        BL    IP020      N
        CLI  0(R8),C'9'  INSURANCE - NO CHARS > '9'
        BH    IP020
        MVC  0(1,R12),0(R8)  SAVE DIGIT
        LA    R11,1(,R11) DIGIT COUNT
        CH    R11,=H'16'  Q-TOO MANY DIGITS
        BNL  IP030      Y-HAVE ALL WE CAN HANDLE
        LA    R12,1(,R12) NEXT DIGIT SAVE AREA
IP020    DS    0H
        LA    R8,1(,R8)  NEXT INCOMING BYTE
        BCT  R9,IP010
IP030    DS    0H        
        BCTR  R11,R0    ADJUST FOR 'EX'
        EX    R11,IPPACK
*        PACK  0(8,R10),IPWORK(*-*)
*        R10 ==> PL16 PACKED DECIMAL 
*        TTD - EXIT INCOMING PACK ROUTINE, EG, B  CONTINUE ON
IPPACK  PACK  0(8,R10),IPWORK(*-*)
IPWORK  DS    CL16

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Greg Gray
Sent: Thursday, October 13, 2016 08:22
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: converting character to packed

I have character data in a field (ex. $13,501,298.01) and I need to remove
the special characters and convert field from char to packed?  Can someone
give a suggestion on the best and simplest way to do it, thanks?
  

Re: converting character to packed

[Paul Gilmartin]

On 2016-10-13, at 09:25, John P. Hartmann wrote:

> You did not say that is what you want, but then I didn't notice which forum 
> you wrote to, so mea culpa.
> 
> Anyhow, if your computer runs VM, you don't have to write assembler at all 
> (and if it runs MVS, make your requirement known to IBM).
>  
On z/OS, the first part is easy:

sed 's/[^0-9]//'  # (Pretty similar to the first Pipeline stage.)

The PACK part is harder.  Don't know about MVS.

-- gil

Re: converting character to packed

[Richard Rogers]

Just a stab, FWIW
*   R8 ==> INCOMING FIELD
*   R9  =  INCOMING FIELD LENGTH
*   R10 ==> PL8 PACKED DECIMAL RESULT
*R11  =  WORK - DIGIT COUNT
*R12 ==> CL16 - WORK - SAVE DIGITS
INCMPACK DS0H   INCOMING PACK
 SRR11,R11  DIGIT COUNT
 LAR12,IPWORK
IP010DS0H
 CLI   0(R8),C'0'  Q-DIGIT
 BLIP020   N
 CLI   0(R8),C'9'  INSURANCE - NO CHARS > '9'
 BHIP020
 MVC   0(1,R12),0(R8)  SAVE DIGIT
 LAR11,1(,R11) DIGIT COUNT
 CHR11,=H'16'  Q-TOO MANY DIGITS
 BNL   IP030   Y-HAVE ALL WE CAN HANDLE
 LAR12,1(,R12) NEXT DIGIT SAVE AREA
IP020DS0H
 LAR8,1(,R8)  NEXT INCOMING BYTE
 BCT   R9,IP010
IP030DS0H 
 BCTR  R11,R0 ADJUST FOR 'EX'
 EXR11,IPPACK
*PACK  0(8,R10),IPWORK(*-*)
*R10 ==> PL16 PACKED DECIMAL 
*TTD - EXIT INCOMING PACK ROUTINE, EG, B  CONTINUE ON
IPPACK   PACK  0(8,R10),IPWORK(*-*)
IPWORK   DSCL16

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Greg Gray
Sent: Thursday, October 13, 2016 08:22
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: converting character to packed

I have character data in a field (ex. $13,501,298.01) and I need to remove
the special characters and convert field from char to packed?  Can someone
give a suggestion on the best and simplest way to do it, thanks?

Re: converting character to packed

[John P. Hartmann]

You did not say that is what you want, but then I didn't notice which 
forum you wrote to, so mea culpa.


Anyhow, if your computer runs VM, you don't have to write assembler at 
all (and if it runs MVS, make your requirement known to IBM).


The instruction you want is PACK, but you must remove all punctuation 
first.  To do that you must copy the contents of the input buffer to a 
temporary buffer, omitting all punctuation, even the decimal point.


And then you must read the manual very carefully.

It boggles the mind why this question was asked at all in this context.


On 10/13/2016 04:56 PM, John McKown wrote:

That's not assembler code.​

Re: converting character to packed

[John McKown]

On Thu, Oct 13, 2016 at 9:42 AM, John P. Hartmann 
wrote:

> Aw, c'm on!
>
> (Untested:)
>
> pipe ... | change /$// | change /,// | spec 1-* c2p 1 | ...
>
> Do you guys still do bubble sorts?


​That's not assembler code.​

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

Re: converting character to packed

[John P. Hartmann]

Aw, c'm on!

(Untested:)

pipe ... | change /$// | change /,// | spec 1-* c2p 1 | ...

Do you guys still do bubble sorts?

On 10/13/2016 04:22 PM, Greg Gray wrote:

I have character data in a field (ex. $13,501,298.01) and I need to remove the 
special characters and convert field from char to packed?  Can someone give a 
suggestion on the best and simplest way to do it, thanks?

Re: converting character to packed

[Greg Gray]

thanks Chuck, I will give that a try!!!

Re: converting character to packed

[Hardee, Chuck]

Given that the decimal position and commas are for you and me and not the 
computer, I would set a field to all "0" and then start a loop on the right of 
each field and if the character is >= "0" and <= "9", move it to the next 
position in the output field. Decrement each pointer based upon whether you 
processed a digit or not and when the loop is done, pack the result. If you 
want binary, then convert the packed field to binary.

Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Greg Gray
Sent: Thursday, October 13, 2016 10:22 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: converting character to packed

I have character data in a field (ex. $13,501,298.01) and I need to remove the 
special characters and convert field from char to packed?  Can someone give a 
suggestion on the best and simplest way to do it, thanks?