Re: SDWA - SDWACMPC conversion

[Seymour J Metz]

WTF? Since when does CVD convert binary to hex?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Robin Vowels 
Sent: Friday, April 13, 2018 11:45 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion

From: "Seymour J Metz" 
Sent: Saturday, April 14, 2018 12:17 AM


> Of course; the standard way to convert binary to hex is the UNPK/TR with a 
> one byte pad.

There is no such "standard" way.

The usual way is to use CVD.

---
This email has been checked for viruses by Avast antivirus software.
https://secure-web.cisco.com/1c6fN-SgQQowDZCfQnXtugYG68qjxfp_nu23HvkUAdeIyYPcA3Du5YhkeTBfbx6d1v5FrkWemk5U_0aZAFXu_LyOFlJbxAfBfsVkCD-1AiRmVhTQETMMdx_ayo8-MwkDZJElMVXXrEoBJI3S05jBa5oYsZocvwcYSbEkuy9fwq2g7KAGO7tmyOwMOwzPqHAUvAs-6YB992w6iQJZuGdN4W6kKdCJ7EKQ4ZAZ9K7GLGNxzmvCb5ehWEw7SZkX4cRTr7gSEep2z50PE8Xa7Qw8wcZe-YvWsz7Z1fzQVIVIoPorvimuhxb3ytAPLBZphXIu4G-pu-Mdebr8ETJiXbomA0tNP4J_C9_tbDOqQI93yu0-BV8MSrWdvbVGKEzD0Ms8vLFflCcbAW_rKF_zzRBnjzA/https%3A%2F%2Fwww.avast.com%2Fantivirus

Re: SDWA - SDWACMPC conversion

[Seymour J Metz]

This thread starting with converting a system completion code to printable 
form, which is hexadecimal. Had it been a user completion code, then 
CVD/UNPK/OI would have been appropriate.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of robi...@dodo.com.au 
Sent: Saturday, April 14, 2018 3:44 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion

Since the object is to convert four decimal digits (range 0-9)
to EBCDIC, OC is sufficient.

- Original Message -
From: "IBM Mainframe Assembler List" 
To:
Cc:
Sent:Sat, 14 Apr 2018 08:52:19 +0200

 >> OC WORK,='F0F0F0F0F0F0'

 >> instead of NC. No TR required.

 Oh - they changed EBCDIC code. C'A' is now equal to X'FA'

 Why didn't anyone tell me?

 Martin

Re: SDWA - SDWACMPC conversion

[Steve Smith]

Indeed... but, J. Scott's technique is actually different (and at least to
me interesting).  It also has the benefit of being actual working code.

btw, my suggested "improvement" isn't complete; another OI is needed for
the next-to-last byte of &target.

And if you're paranoid about the possibility of it being used in sub-240
byte routines, then sure, my changes won't do.


On Mon, Apr 16, 2018 at 10:54 PM, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2018-04-16, at 20:48:39, Charles Mills wrote:
>
> > Good grief! How many experienced z assembler programmers does it take to
> convert 12 bits of binary to hex?
> >
> Errr...  One to write the code and twenty to prate about it on
> ASSEMBLER-LIST?
>
> --gil
>



-- 
sas

Re: SDWA - SDWACMPC conversion

[Paul Gilmartin]

On 2018-04-16, at 20:48:39, Charles Mills wrote:

> Good grief! How many experienced z assembler programmers does it take to 
> convert 12 bits of binary to hex?
>  
Errr...  One to write the code and twenty to prate about it on ASSEMBLER-LIST?

--gil

Re: SDWA - SDWACMPC conversion

[Charles Mills]

Good grief! How many experienced z assembler programmers does it take to 
convert 12 bits of binary to hex?

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of glen herrmannsfeldt
Sent: Monday, April 16, 2018 3:06 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SDWA - SDWACMPC conversion

> Maybe I'm missing something, as this is a bit trickier than the usual
> shlop, but wouldn't it be more efficient to OI the last byte of &TARGET
> with x'F0', and skip the MVZ?  Using =C'0123...'-C'0'  for the TR table of
> course.

Maybe you are planning to do this a few billion times. 

Otherwise, do you mean more efficient in execution time,
memory used, or time spent coding and debugging?

Using the offset translation table requires that the origin is
appropriate, such that the displacement isn’t negative. 

As a general purpose macro, when you can’t be sure where
or when it might be used, that could be a problem. 

In addition, note the trial execution required when the translate
table crosses a page boundary.  

But most likely more time has been spent discussing the efficiency
than lost by any inefficiencies in the macro.

—glen=

Re: SDWA - SDWACMPC conversion

[glen herrmannsfeldt]

> Maybe I'm missing something, as this is a bit trickier than the usual
> shlop, but wouldn't it be more efficient to OI the last byte of &TARGET
> with x'F0', and skip the MVZ?  Using =C'0123...'-C'0'  for the TR table of
> course.

Maybe you are planning to do this a few billion times. 

Otherwise, do you mean more efficient in execution time,
memory used, or time spent coding and debugging?

Using the offset translation table requires that the origin is
appropriate, such that the displacement isn’t negative. 

As a general purpose macro, when you can’t be sure where
or when it might be used, that could be a problem. 

In addition, note the trial execution required when the translate
table crosses a page boundary.  

But most likely more time has been spent discussing the efficiency
than lost by any inefficiencies in the macro.

—glen

Re: SDWA - SDWACMPC conversion

[Steve Smith]

Maybe I'm missing something, as this is a bit trickier than the usual
shlop, but wouldn't it be more efficient to OI the last byte of &TARGET
with x'F0', and skip the MVZ?  Using =C'0123...'-C'0'  for the TR table of
course.

On Mon, Apr 16, 2018 at 11:59 AM, Jonathan Scott <
jonathan_sc...@vnet.ibm.com> wrote:

> Here's a simplified version of a macro which I've been using to convert
> data to printable hex for over 30 years.  It uses the extra one-byte
> move instead of needing a pad byte, so that the user doesn't need to
> know about that, and sets the zones to zero so that it only needs a
> 16-byte table, which can default to being a literal.
>
>  MACRO
> &LABEL   TOHEX &TARGET,&SOURCE
> &LABEL   UNPK  &TARGET.(L'&TARGET-1),&SOURCE
>  MVC   &TARGET+L'&TARGET-1(1),&SOURCE+L'&SOURCE-1
>  NI&TARGET,X'0F'
>  MVZ   &TARGET+1(L'&TARGET-1),&TARGET
>  TR&TARGET,=C'0123456789ABCDEF'
>  MEND  ,
>
> The NI and MVZ can alternatively be done using NC with a literal, and in
> the real macro the 16-byte hex table can be provided as a parameter.
>
> Jonathan Scott
> IBM Hursley, UK
>



-- 
sas

Re: SDWA - SDWACMPC conversion

[Jonathan Scott]

Here's a simplified version of a macro which I've been using to convert
data to printable hex for over 30 years.  It uses the extra one-byte
move instead of needing a pad byte, so that the user doesn't need to
know about that, and sets the zones to zero so that it only needs a
16-byte table, which can default to being a literal.

 MACRO
&LABEL   TOHEX &TARGET,&SOURCE
&LABEL   UNPK  &TARGET.(L'&TARGET-1),&SOURCE
 MVC   &TARGET+L'&TARGET-1(1),&SOURCE+L'&SOURCE-1
 NI&TARGET,X'0F'
 MVZ   &TARGET+1(L'&TARGET-1),&TARGET
 TR&TARGET,=C'0123456789ABCDEF'
 MEND  ,

The NI and MVZ can alternatively be done using NC with a literal, and in
the real macro the 16-byte hex table can be provided as a parameter.

Jonathan Scott
IBM Hursley, UK

Re: SDWA - SDWACMPC conversion

[robin51]

- Original Message -
From: "IBM Mainframe Assembler List" 
Sent:Mon, 16 Apr 2018 09:06:37 -0400

 On Sat, 14 Apr 2018 17:44:37 +1000, robi...@dodo.com.au wrote:

 >>Since the object is to convert four decimal digits (range 0-9)
 >>to EBCDIC, OC is sufficient.

 > It is? This thread started out about converting System Completion
code to 
 > three characters representing hexadecimal, then diverged into a
more 
 > general discussion of converting binary values into printable hex.
I must
 > have missed the part where it diverged to converting decimal digits
to 
 > printable characters. For that, there is no need to OR anything but
the 
 > last byte of the UNPKed data.

That's what I just said.

However, if the aim is to convert a 12-bit binary integer value to
display form, treating each four bits as a hex digit in the range
0-9,A-F,
you cannot use UNPK.
The reason relates to the last two nibbles.  UNPK swaps these two
nibbles during the conversion.
Thus, using OI to put in a zone of F destroys the final digit.

To use UNPK, then you need to UNPK one extra trailing byte.
The nibbles of the extra byte will be swapped (as expected)
but they can be ignored.  The four nibbles obtained from the
12-bit binary integer will be in four separate bytes, with a zone of
F.
(the leading zoned digit will, of course, be zero, and can be ignored
too.)

Re: SDWA - SDWACMPC conversion

[Tom Marchant]

On Sat, 14 Apr 2018 17:44:37 +1000, robi...@dodo.com.au wrote:

>Since the object is to convert four decimal digits (range 0-9)
>to EBCDIC, OC is sufficient.

It is? This thread started out about converting System Completion code to 
three characters representing hexadecimal, then diverged into a more 
general discussion of converting binary values into printable hex. I must
 have missed the part where it diverged to converting decimal digits to 
printable characters. For that, there is no need to OR anything but the 
last byte of the UNPKed data.

-- 
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Martin Truebner]

Robin,

right you are 

- I did not pay attention to that side-condition

I had something about 4095 in the back of my head (=3 hex digits)

Martin

Re: SDWA - SDWACMPC conversion

[robin51]

Since the object is to convert four decimal digits (range 0-9)
to EBCDIC, OC is sufficient.

- Original Message -
From: "IBM Mainframe Assembler List" 
To:
Cc:
Sent:Sat, 14 Apr 2018 08:52:19 +0200

 >> OC WORK,='F0F0F0F0F0F0'

 >> instead of NC. No TR required.

 Oh - they changed EBCDIC code. C'A' is now equal to X'FA'

 Why didn't anyone tell me?

 Martin

Re: SDWA - SDWACMPC conversion

[Martin Truebner]

>>  OCWORK,'F0F0F0F0F0F0'

>> instead of NC.  No TR required.

Oh - they changed EBCDIC code. C'A' is now equal to X'FA'

Why didn't anyone tell me?

Martin

Re: SDWA - SDWACMPC conversion

[Robin Vowels]

From: "Robin Vowels" 
Sent: Saturday, April 14, 2018 2:35 PM

Should be

   OCWORK,='F0F0F0F0F0F0'

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

Re: SDWA - SDWACMPC conversion

[Robin Vowels]

From: "Donald Blake" 
Sent: Friday, April 13, 2018 7:00 AM



Let me try that again ...

WORK  DS CL6
 DS X  , Slack byte

 UNPK  WORK(7),SDWACMPC(4)
  NC   WORK,=X'0F0F0F0F0F0F'
  TR  WORK,=C'0123456789ABCDEF'


If you're going to do it that way, try

   OCWORK,'F0F0F0F0F0F0'

instead of NC.  No TR required.

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

Re: SDWA - SDWACMPC conversion

[Robin Vowels]

From: "Seymour J Metz" 
Sent: Saturday, April 14, 2018 12:17 AM



Of course; the standard way to convert binary to hex is the UNPK/TR with a one 
byte pad.


There is no such "standard" way.

The usual way is to use CVD.

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

Re: SDWA - SDWACMPC conversion

[Robin Vowels]

From: "Martin Ward" 
Sent: Saturday, April 14, 2018 12:13 AM



On 13/04/18 15:02, Seymour J Metz wrote:

Unpacking x'0123' gives you x'F0F132'; the OI then gives you
x'F0F1F2'; what you want is x'F0F1F2F3'. Or with an UNNPK length of 4
you get x'F0F0F1F2'; still not what you want.


Suppose the byte after the X'0123' is X'xy' (where x and y are
any hex digits).

Unpacking X'0123xy' (with a source length of 3 and a destination
length of 5) gives you X'F0F1F2F3yx' which, when you drop
the last byte, gives you what you want.


I was wondering when someone would come up with this.


This assumes that there is an addressable byte immediately after X'0123'
For a general solution, copy the source field to a sufficiently
large work area before unpacking.


For a general solution, just use UNPK as above,
and define a byte following the source.

If this is not possible, then move the 2 bytes.

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

Re: SDWA - SDWACMPC conversion

[Keven]

Okay, I was getting some wires crossed over this in that I 
conflated the special case of converting binary data to a hexadecimal character 
string and the general case where binary data in (putatively) packed decima 
format is converted to a decimal character string.I’ve written code to perform  
both tasks many times and am actually a pretty competent (accomplished, even) 
Mainframe assembler programmer but I’m also at the end of a long sabbatical 
leave and some rust build-up is inevitable I guess.I’m excited to put my 
talents back into income-generating use once more.
Sorry for any confusion y’all Keven







On Fri, Apr 13, 2018 at 9:17 AM -0500, "Seymour J Metz"  wrote:










Of course; the standard way to convert binary to hex is the UNPK/TR with a one 
byte pad.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf of Martin Ward 
Sent: Friday, April 13, 2018 10:13 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion

On 13/04/18 15:02, Seymour J Metz wrote:
> Unpacking x'0123' gives you x'F0F132'; the OI then gives you
> x'F0F1F2'; what you want is x'F0F1F2F3'. Or with an UNNPK length of 4
> you get x'F0F0F1F2'; still not what you want.

Suppose the byte after the X'0123' is X'xy' (where x and y are
any hex digits).

Unpacking X'0123xy' (with a source length of 3 and a destination
length of 5) gives you X'F0F1F2F3yx' which, when you drop
the last byte, gives you what you want.

This assumes that there is an addressable byte immediately after X'0123'
For a general solution, copy the source field to a sufficiently
large work area before unpacking.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | 
http://secure-web.cisco.com/1lagfs9GjyiyLT82Ko-qpifb67fwapePMSu4hk-KLL9Cuw1Dv2lxf8XLjorCTFzvoSytC7yetXWud7Orhlxk8PYk2LT-BzzCB8QwgqWQ_GCl4XFLonmHV3QiPFFyWl9r3O-RxMr7EeW3bVXA3qdr2uLLpSBdLHSC60Mn8oc-3gZ41bV8MvqSvV2Ig1wvac7TCVYI1Cokf6ZY9CjAYVJw4WlnxYGp1tVFbM0xqtfdCpHjy7cukGyH_q0RN0d3mUEOjjk0SKUZAf2MormdyraoJO6BTIHydBjmiIVddu2xpMi9Hx2PNm4Cl0_qTJ87Rh6fafPhM7N-Oa8b9SJW_MFdcQBqUtFxnIoGqg1ctU1RIK9dYB5M4DuJjmw8ruEWV0a5qVyPVSkBz4xFAePDKA2WdVA/http%3A%2F%2Fwww.gkc.org.uk
G.K.Chesterton site: 
http://secure-web.cisco.com/1EFv6ITm-cNPZyc6WUhu5xV68B2nBl3Uk0xaQxJ76I90PTqR9iuF72rwOH7ANwbiSgc7DNIU5g0WWZMJGbQmDPStTPrE83paP9H2Q-VQADfxQ-5CzA0xoQG_9UpkKcdu_0ijk4iCGKzcCg3Nrs958Hus8IdtODBeclqOWt4vZoC7ZGGpNDS0G0VHoJBw2-ZRuhkgYVwFLTMu940d6JODhT89XdKnccfHj_anNDgRZBpiQ7Ank09WBMK6Df1MpajbefsCgKWLKJw7mlS64zezTcmi1GTD9gY1o6LfdujKrGRx4l8yXds6KJtvJ9CllXxJcl4J4ue6vs7uhskTYVuueIAFCXm3fWu8HCr0YGoUnhY67xGoXYVzm3OZAF2KCjQTAMxumXfFxJRqHVsuMk6yTtQ/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc
 | Erdos number: 4

Re: SDWA - SDWACMPC conversion

[Seymour J Metz]

Of course; the standard way to convert binary to hex is the UNPK/TR with a one 
byte pad.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Martin Ward 
Sent: Friday, April 13, 2018 10:13 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion

On 13/04/18 15:02, Seymour J Metz wrote:
> Unpacking x'0123' gives you x'F0F132'; the OI then gives you
> x'F0F1F2'; what you want is x'F0F1F2F3'. Or with an UNNPK length of 4
> you get x'F0F0F1F2'; still not what you want.

Suppose the byte after the X'0123' is X'xy' (where x and y are
any hex digits).

Unpacking X'0123xy' (with a source length of 3 and a destination
length of 5) gives you X'F0F1F2F3yx' which, when you drop
the last byte, gives you what you want.

This assumes that there is an addressable byte immediately after X'0123'
For a general solution, copy the source field to a sufficiently
large work area before unpacking.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | 
http://secure-web.cisco.com/1lagfs9GjyiyLT82Ko-qpifb67fwapePMSu4hk-KLL9Cuw1Dv2lxf8XLjorCTFzvoSytC7yetXWud7Orhlxk8PYk2LT-BzzCB8QwgqWQ_GCl4XFLonmHV3QiPFFyWl9r3O-RxMr7EeW3bVXA3qdr2uLLpSBdLHSC60Mn8oc-3gZ41bV8MvqSvV2Ig1wvac7TCVYI1Cokf6ZY9CjAYVJw4WlnxYGp1tVFbM0xqtfdCpHjy7cukGyH_q0RN0d3mUEOjjk0SKUZAf2MormdyraoJO6BTIHydBjmiIVddu2xpMi9Hx2PNm4Cl0_qTJ87Rh6fafPhM7N-Oa8b9SJW_MFdcQBqUtFxnIoGqg1ctU1RIK9dYB5M4DuJjmw8ruEWV0a5qVyPVSkBz4xFAePDKA2WdVA/http%3A%2F%2Fwww.gkc.org.uk
G.K.Chesterton site: 
http://secure-web.cisco.com/1EFv6ITm-cNPZyc6WUhu5xV68B2nBl3Uk0xaQxJ76I90PTqR9iuF72rwOH7ANwbiSgc7DNIU5g0WWZMJGbQmDPStTPrE83paP9H2Q-VQADfxQ-5CzA0xoQG_9UpkKcdu_0ijk4iCGKzcCg3Nrs958Hus8IdtODBeclqOWt4vZoC7ZGGpNDS0G0VHoJBw2-ZRuhkgYVwFLTMu940d6JODhT89XdKnccfHj_anNDgRZBpiQ7Ank09WBMK6Df1MpajbefsCgKWLKJw7mlS64zezTcmi1GTD9gY1o6LfdujKrGRx4l8yXds6KJtvJ9CllXxJcl4J4ue6vs7uhskTYVuueIAFCXm3fWu8HCr0YGoUnhY67xGoXYVzm3OZAF2KCjQTAMxumXfFxJRqHVsuMk6yTtQ/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc
 | Erdos number: 4

Re: SDWA - SDWACMPC conversion

[Alan Atkinson]

I lost half this thread, but wouldn't this whole deal be easier if you used a 
mix of SRL and SRDL in an even odd pair to separate the nibbles and then either 
a couple of OI's depending on the value of the nibble or a table "0-9A-F" to 
index into? That way you'd get the hex value to look up.


ALAN ATKINSON |   SR. DIRECTOR SOFTWARE ARCHITECTURE
T 212 633 5313  | 
aatkin...@mediaocean.com<https://webmail.mediaocean.com/owa/redir.aspx?C=1_58sqLAcDTMwKZpc1tNXWVDQTlmH0jWAS1Lk8vIVfjzpmZ34jPUCA..&URL=mailto%3aaatkinson%40mediaocean.com>
45 WEST 18TH STREET, NEW YORK, NY 10011
MEDIAOCEAN.COM  |  @TEAMMEDIAOCEAN

The information contained in this message is intended for the addressee only 
and may contain confidential information, which
if received in error you should not copy or distribute. Email transmission 
cannot be guaranteed to be secure or free of errors, so
no reliance may be placed on this message without the written confirmation from 
an authorized representative.
Any view expressed may not necessarily be the views of Mediaocean.

From: IBM Mainframe Assembler List  on behalf 
of Seymour J Metz 
Sent: Friday, April 13, 2018 10:02:09 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SDWA - SDWACMPC conversion

Unpacking x'0123' gives you x'F0F132'; the OI then gives you x'F0F1F2'; what 
you want is x'F0F1F2F3'. Or with an UNNPK length of 4 you get x'F0F0F1F2'; 
still not what you want.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Keven 
Sent: Thursday, April 12, 2018 7:40 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion





“Keep in mind that UNPK swaps bits 0-3 of the right byte with 
bits 4-7.”
That’s why the Or Immediate is there; it enforces a zone nibble of 0xF for the 
last hex digit and ensures correct execution of the TRanslate.









On Thu, Apr 12, 2018 at 3:00 PM -0500, "Seymour J Metz"  wrote:










Keep in mind that UNPK swaps bits 0-3 of the right byte with bits 4-7.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf of Keven
Sent: Wednesday, April 11, 2018 4:15 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion





Good point; I should have stuck with HEXTBL-240 but I decided 
last minute that hexadecimal notation would make for a better aesthetic and for 
some reason X’C0’ stepped forward instead of the apposite value.
Using the UNPK/OI does mean no reading past the last byte of the value to be 
converted which may be desirable for a generalized implementation.
Keven









On Fri, Apr 6, 2018 at 9:22 AM -0500, "J R"  wrote:










As you're concerned with robustness, it might be better to address the 
translate table thus:

 TRZONED,HEXTBL-X'F0'X'C1C2C3'

> On Apr 5, 2018, at 18:29, Keven  wrote:
>
> TRZONED,HEXTBL-X'C0'X'C1C2C3'

Re: SDWA - SDWACMPC conversion

[Martin Ward]

On 13/04/18 15:02, Seymour J Metz wrote:

Unpacking x'0123' gives you x'F0F132'; the OI then gives you
x'F0F1F2'; what you want is x'F0F1F2F3'. Or with an UNNPK length of 4
you get x'F0F0F1F2'; still not what you want.


Suppose the byte after the X'0123' is X'xy' (where x and y are
any hex digits).

Unpacking X'0123xy' (with a source length of 3 and a destination
length of 5) gives you X'F0F1F2F3yx' which, when you drop
the last byte, gives you what you want.

This assumes that there is an addressable byte immediately after X'0123'
For a general solution, copy the source field to a sufficiently
large work area before unpacking.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

Re: SDWA - SDWACMPC conversion

[Seymour J Metz]

Unpacking x'0123' gives you x'F0F132'; the OI then gives you x'F0F1F2'; what 
you want is x'F0F1F2F3'. Or with an UNNPK length of 4 you get x'F0F0F1F2'; 
still not what you want.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Keven 
Sent: Thursday, April 12, 2018 7:40 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion





“Keep in mind that UNPK swaps bits 0-3 of the right byte with 
bits 4-7.”
That’s why the Or Immediate is there; it enforces a zone nibble of 0xF for the 
last hex digit and ensures correct execution of the TRanslate.









On Thu, Apr 12, 2018 at 3:00 PM -0500, "Seymour J Metz"  wrote:










Keep in mind that UNPK swaps bits 0-3 of the right byte with bits 4-7.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf of Keven
Sent: Wednesday, April 11, 2018 4:15 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion





Good point; I should have stuck with HEXTBL-240 but I decided 
last minute that hexadecimal notation would make for a better aesthetic and for 
some reason X’C0’ stepped forward instead of the apposite value.
Using the UNPK/OI does mean no reading past the last byte of the value to be 
converted which may be desirable for a generalized implementation.
Keven









On Fri, Apr 6, 2018 at 9:22 AM -0500, "J R"  wrote:










As you're concerned with robustness, it might be better to address the 
translate table thus:

 TRZONED,HEXTBL-X'F0'X'C1C2C3'

> On Apr 5, 2018, at 18:29, Keven  wrote:
>
> TRZONED,HEXTBL-X'C0'X'C1C2C3'

Re: SDWA - SDWACMPC conversion

[Keven]

What are you talking about?What point are you trying to make?









On Thu, Apr 12, 2018 at 3:30 PM -0500, "Tom Marchant" 
<00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:










On Wed, 11 Apr 2018 20:15:12 +, Keven  wrote:

>Using the UNPK/OI does mean no reading past the last byte of the value to be 
>converted which may be desirable for a generalized implementation.

Sure, you could do something like this to convert two bytes to four hex digits:

  UNPK OUT(3),IN(2)
  MVC  OUT+3(1),IN+1
  OIOUT+2,X'F0'
  OIOUT+3,X'F0'
  TROUT(4),TRTABLE-240

Or you can do:

  UNPK OUT(5),IN(3)
  TROUT(4),TRTABLE-240

IN  DS  XL2
OUT DS CL5
TRTABLE DC C'0123456789ABCDEF'

I would opt for the latter.

-- 
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Keven]

“Keep in mind that UNPK swaps bits 0-3 of the right byte with 
bits 4-7.”
That’s why the Or Immediate is there; it enforces a zone nibble of 0xF for the 
last hex digit and ensures correct execution of the TRanslate.









On Thu, Apr 12, 2018 at 3:00 PM -0500, "Seymour J Metz"  wrote:










Keep in mind that UNPK swaps bits 0-3 of the right byte with bits 4-7.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf of Keven 
Sent: Wednesday, April 11, 2018 4:15 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion





Good point; I should have stuck with HEXTBL-240 but I decided 
last minute that hexadecimal notation would make for a better aesthetic and for 
some reason X’C0’ stepped forward instead of the apposite value.
Using the UNPK/OI does mean no reading past the last byte of the value to be 
converted which may be desirable for a generalized implementation.
Keven









On Fri, Apr 6, 2018 at 9:22 AM -0500, "J R"  wrote:










As you're concerned with robustness, it might be better to address the 
translate table thus:

 TRZONED,HEXTBL-X'F0'X'C1C2C3'

> On Apr 5, 2018, at 18:29, Keven  wrote:
>
> TRZONED,HEXTBL-X'C0'X'C1C2C3'

Fwd: SDWA - SDWACMPC conversion

[Donald Blake]

Let me try that again ...

WORK  DS CL6
  DS X  , Slack byte

  UNPK  WORK(7),SDWACMPC(4)
   NC   WORK,=X'0F0F0F0F0F0F'
   TR  WORK,=C'0123456789ABCDEF'



-- 
Donald H. Blake
Ecclesiastes 12:1

SDWA - SDWACMPC conversion

[Donald Blake]

WORK  DS CL6
  DS X  , Slack byte

  UNPK  WORK(7),SDWACMPC
   NI   WORK,=X'0F0F0F0F0F0F'
   TR  WORK,=C'0123456789ABCDEF'


-- 
Donald H. Blake
Ecclesiastes 12:1

Re: SDWA - SDWACMPC conversion

[Tom Marchant]

On Wed, 11 Apr 2018 20:15:12 +, Keven  wrote:

>Using the UNPK/OI does mean no reading past the last byte of the value to be 
>converted which may be desirable for a generalized implementation.

Sure, you could do something like this to convert two bytes to four hex digits:

  UNPK OUT(3),IN(2)
  MVC  OUT+3(1),IN+1
  OIOUT+2,X'F0'
  OIOUT+3,X'F0'
  TROUT(4),TRTABLE-240

Or you can do:

  UNPK OUT(5),IN(3)
  TROUT(4),TRTABLE-240

IN  DS  XL2
OUT DS CL5
TRTABLE DC C'0123456789ABCDEF'

I would opt for the latter.

-- 
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Seymour J Metz]

Keep in mind that UNPK swaps bits 0-3 of the right byte with bits 4-7.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Keven 
Sent: Wednesday, April 11, 2018 4:15 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: SDWA - SDWACMPC conversion





Good point; I should have stuck with HEXTBL-240 but I decided 
last minute that hexadecimal notation would make for a better aesthetic and for 
some reason X’C0’ stepped forward instead of the apposite value.
Using the UNPK/OI does mean no reading past the last byte of the value to be 
converted which may be desirable for a generalized implementation.
Keven









On Fri, Apr 6, 2018 at 9:22 AM -0500, "J R"  wrote:










As you're concerned with robustness, it might be better to address the 
translate table thus:

 TRZONED,HEXTBL-X'F0'X'C1C2C3'

> On Apr 5, 2018, at 18:29, Keven  wrote:
>
> TRZONED,HEXTBL-X'C0'X'C1C2C3'

Re: SDWA - SDWACMPC conversion

[Keven]

Good point; I should have stuck with HEXTBL-240 but I decided 
last minute that hexadecimal notation would make for a better aesthetic and for 
some reason X’C0’ stepped forward instead of the apposite value.
Using the UNPK/OI does mean no reading past the last byte of the value to be 
converted which may be desirable for a generalized implementation.
Keven









On Fri, Apr 6, 2018 at 9:22 AM -0500, "J R"  wrote:










As you're concerned with robustness, it might be better to address the 
translate table thus:  

 TRZONED,HEXTBL-X'F0'X'C1C2C3'

> On Apr 5, 2018, at 18:29, Keven  wrote:
> 
> TRZONED,HEXTBL-X'C0'X'C1C2C3'

Re: SDWA - SDWACMPC conversion

[Tom Marchant]

On Thu, 5 Apr 2018 17:29:26 -0500, Keven wrote:

>*  Assume that SDWACMPC contains a value of X'ABC000'
>
>*  Value of ZONED/5 after execution
>
>   UNPKZONED,SDWACMPC(2)   X'FAFB0C'
>   OI  ZONED+2,X'F0'   X'FAFBFC'
>   TR  ZONED,HEXTBL-X'C0'  X'C1C2C3'
>
>*  I guess you're preferring something like:
>
>   UNPKZONE5,SDWACMPC  X'FAFBFCF000'
>   TR  ZONED,HEXTBL-X'C0'  XC1C2C3'
>
>ZONE5  DS  0CL5
>ZONED  DS  CL3
>   DS  2X
>HEXTBL DC  C'0123456789ABCDEF'

Yes, in the case of the system completion code, you're right. It can be done 
that way, and the OI is needed. For the general case of converting full bytes 
to displayable hex, it needs to be done the second way, unpacking one 
extra byte.

And J R is correct, it should be HEXTBL-F'F0'

--
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Keven]

I think using  OI is valid for implementing a robust solution for completing 
the task at hand.


*   Assume that SDWACMPC contains a value of X'ABC000'

*   Value of ZONED/5 after execution

UNPKZONED,SDWACMPC(2)   X'FAFB0C'
OI  ZONED+2,X'F0'   X'FAFBFC'
TR  ZONED,HEXTBL-X'C0'  X'C1C2C3'

*   I guess you're preferring something like:

UNPKZONE5,SDWACMPC  X'FAFBFCF000'
TR  ZONED,HEXTBL-X'C0'  XC1C2C3'

ZONE5   DS  0CL5
ZONED   DS  CL3
DS  2X
HEXTBL  DC  C'0123456789ABCDEF'



-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Tom Marchant
Sent: Thursday, April 5, 2018 9:52 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SDWA - SDWACMPC conversion

On Thu, 5 Apr 2018 14:45:15 +, Keven wrote:

>After UNPK you may need an OI to fix the sign nibble of the resultant 
>zoned decimal valuE (i.e., ensure that all the zoned digits are 0xf0 to
>0xff) if you want to use a 16-byte translation table.

No. You need to unpack one more byte on the right.

--
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Tom Marchant]

On Thu, 5 Apr 2018 14:45:15 +, Keven wrote:

>After UNPK you may need an OI to fix the sign nibble of the resultant 
>zoned decimal valuE (i.e., ensure that all the zoned digits are 0xf0 to 
>0xff) if you want to use a 16-byte translation table.

No. You need to unpack one more byte on the right.

-- 
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Tom Marchant]

On Thu, 5 Apr 2018 13:45:04 +0200, Pieter Wiid wrote:

>Not quite -- TR always wants a 256-byte table, so the standard 
>TR xx,HEX-C'0' only works if there are 240 byte before your hex table.

TR will only reference the locations in the translate table that are 
actually needed for the translation. For this purpose, the table can 
be 16 bytes, but you do need a register that points to 240 bytes 
before the table (or before). There are many ways to ensure that, 
including the LAY that Martin mentioned, or LARL, either of which 
is 6 bytes long.

-- 
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Keven]

After UNPK you may need an OI to fix the sign nibble of the 
resultant zoned decimal valuE (i.e., ensure that all the zoned digits are 0xf0 
to 0xff) if you want to use a 16-byte translation table.
K3n









On Thu, Apr 5, 2018 at 9:07 AM -0500, "Martin Truebner"  
wrote:










>> ...so the standard TR xx,HEX-C'0' only works if there are 240 byte
>> before your hex table.

Which could be avoided with 
 
 LAY  SPARE_REGISTER,HEX-C'0'

with only 4 bytes extra

Martin

Re: SDWA - SDWACMPC conversion

[Martin Truebner]

>> ...so the standard TR xx,HEX-C'0' only works if there are 240 byte
>> before your hex table.

Which could be avoided with 
 
 LAY  SPARE_REGISTER,HEX-C'0'

with only 4 bytes extra

Martin

Re: SDWA - SDWACMPC conversion

[Dougie Lawson]

Don't forget that the valid range for user abend codes is U (unlikely
to be used) to U4095.
With IMS any user abend code below U3500 is reserved as an IMS abend, any
code in the range U3500 to U4093 is an abend in user's code (or LE)

U4094 and U4095 are also reserved for IMS.

Regards, Dougie

On 5 April 2018 at 13:41, Charles Mills  wrote:

> Good point. Some of the system ABENDs are incredibly broad and generic.
> Without the reason code, you are guessing.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Keven
> Sent: Thursday, April 5, 2018 4:27 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: SDWA - SDWACMPC conversion
>
>
>
>
>
> Don’t forget about any ABEND Reason Code.If bit SDWARCF is
> on in SDWACMPF then there’s a valid Reason Code in SDWACRC.  SDWACRC is in
> the SDWARC1 Extension, the address of which is in SDWASVRP.  SDWASVRP is in
> the SDWAPTRS area which is pointed to by SDWAXPAD.
> The somewhat torturous route to the Reason Code suggests to me that it was
> not part of the original specifications for RTM termination services...
> K3n
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Apr 4, 2018 at 4:57 PM -0500, "Charles Mills" 
> wrote:
>
>
>
>
>
>
>
>
>
>
> My code is half in assembler and half in C++ so not much use to others but
>
> - one of the twelve bits fields is the User ABEND code. If it is non-zero,
> format it as U where  is the decimal (CVD and UNPK) value of the 12
> bits.
> - the other is the System ABEND code. If it is non-zero, format it as Sxxx
> where xxx is the hex value of the twelve bits. There are other threads here
> that have covered binary to hex conversion -- there are lots of ways to do
> it.
>
> They should never both be non-zero on an ABEND. It is possible but
> unlikely they are both zero. If so, I think there is a bit somewhere that
> tells you whether this is a U or an S000 ABEND. If it were me and I was
> trying to be compact, I might just format the S-code if it were non-zero,
> and else the U-code (zero or not).
>
> Charles
>
>
> -Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU
> ]
> On Behalf Of esst...@juno.com
> Sent: Wednesday, April 4, 2018 2:30 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: SDWA - SDWACMPC conversion
>
> Hi,
>
> As usual, I'm looking into some old ESTAE code.
> More specifically the System Diagnostic Work area.
> Does anyone have any sample code to share which interprets and converts
> the two 12-Bit codes of SDWACMPC into a displayable format ?
> .
> I'm trying to keep the size of the module small and would prefer not to
> use any Translation Table.
> .
> Anyone have any code they could share ?
> .
> .
> Thank You
> Paul D'Angelo
> .
> .
> .
>
>


-- 
http://twitter.com/DougieLawson

Re: SDWA - SDWACMPC conversion

[Charles Mills]

Good point. Some of the system ABENDs are incredibly broad and generic. Without 
the reason code, you are guessing.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Keven
Sent: Thursday, April 5, 2018 4:27 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SDWA - SDWACMPC conversion





Don’t forget about any ABEND Reason Code.If bit SDWARCF is on 
in SDWACMPF then there’s a valid Reason Code in SDWACRC.  SDWACRC is in the 
SDWARC1 Extension, the address of which is in SDWASVRP.  SDWASVRP is in the 
SDWAPTRS area which is pointed to by SDWAXPAD.
The somewhat torturous route to the Reason Code suggests to me that it was not 
part of the original specifications for RTM termination services...
K3n











On Wed, Apr 4, 2018 at 4:57 PM -0500, "Charles Mills"  wrote:










My code is half in assembler and half in C++ so not much use to others but

- one of the twelve bits fields is the User ABEND code. If it is non-zero, 
format it as U where  is the decimal (CVD and UNPK) value of the 12 
bits.
- the other is the System ABEND code. If it is non-zero, format it as Sxxx 
where xxx is the hex value of the twelve bits. There are other threads here 
that have covered binary to hex conversion -- there are lots of ways to do it.

They should never both be non-zero on an ABEND. It is possible but unlikely 
they are both zero. If so, I think there is a bit somewhere that tells you 
whether this is a U or an S000 ABEND. If it were me and I was trying to be 
compact, I might just format the S-code if it were non-zero, and else the 
U-code (zero or not).

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of esst...@juno.com
Sent: Wednesday, April 4, 2018 2:30 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: SDWA - SDWACMPC conversion

Hi,

As usual, I'm looking into some old ESTAE code.
More specifically the System Diagnostic Work area.
Does anyone have any sample code to share which interprets and converts the two 
12-Bit codes of SDWACMPC into a displayable format ?
.
I'm trying to keep the size of the module small and would prefer not to use any 
Translation Table.
.
Anyone have any code they could share ?
.
.
Thank You
Paul D'Angelo
.
.
.
  

Re: SDWA - SDWACMPC conversion

[Joseph Reichman]

On the CBT site there is a sample recovery routine generic ESTAE FRR etc. 
but it does WTO registers and probably abend code you could probably lift code 
from there 
Just go to the site and search for recovery 



> On Apr 4, 2018, at 5:30 PM, esst...@juno.com  wrote:
> 
> Hi,
> 
> As usual, I'm looking into some old ESTAE code.
> More specifically the System Diagnostic Work area.
> Does anyone have any sample code to share which interprets and converts the 
> two 12-Bit codes of SDWACMPC into a displayable format ?
> .
> I'm trying to keep the size of the module small and would prefer not to use 
> any Translation Table.
> .
> Anyone have any code they could share ?
> .
> .
> Thank You
> Paul D'Angelo
> .
> .
> .
> 

Re: SDWA - SDWACMPC conversion

[Pieter Wiid]

Not quite -- TR always wants a 256-byte table, so the standard TR xx,HEX-C'0' 
only works if there are 240 byte before your hex table.

Pieter.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Tom Marchant
Sent: 05 April 2018 13:39
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SDWA - SDWACMPC conversion

On Wed, 4 Apr 2018 21:30:24 GMT, esst...@juno.com wrote:

>I'm trying to keep the size of the module small and would prefer not to use 
>any Translation Table.

For conversion to displayable hex after an UNPK, you only need a 16-byte 
translate table.

--
Tom Marchant


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

Re: SDWA - SDWACMPC conversion

[Tom Marchant]

On Wed, 4 Apr 2018 21:30:24 GMT, esst...@juno.com wrote:

>I'm trying to keep the size of the module small and would prefer not to use 
>any Translation Table.

For conversion to displayable hex after an UNPK, you only need a 16-byte 
translate table.

-- 
Tom Marchant

Re: SDWA - SDWACMPC conversion

[Keven]

Don’t forget about any ABEND Reason Code.If bit SDWARCF is on 
in SDWACMPF then there’s a valid Reason Code in SDWACRC.  SDWACRC is in the 
SDWARC1 Extension, the address of which is in SDWASVRP.  SDWASVRP is in the 
SDWAPTRS area which is pointed to by SDWAXPAD.
The somewhat torturous route to the Reason Code suggests to me that it was not 
part of the original specifications for RTM termination services...
K3n











On Wed, Apr 4, 2018 at 4:57 PM -0500, "Charles Mills"  wrote:










My code is half in assembler and half in C++ so not much use to others but

- one of the twelve bits fields is the User ABEND code. If it is non-zero,
format it as U where  is the decimal (CVD and UNPK) value of the 12
bits.
- the other is the System ABEND code. If it is non-zero, format it as Sxxx
where xxx is the hex value of the twelve bits. There are other threads here
that have covered binary to hex conversion -- there are lots of ways to do
it.

They should never both be non-zero on an ABEND. It is possible but unlikely
they are both zero. If so, I think there is a bit somewhere that tells you
whether this is a U or an S000 ABEND. If it were me and I was trying to
be compact, I might just format the S-code if it were non-zero, and else the
U-code (zero or not).

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of esst...@juno.com
Sent: Wednesday, April 4, 2018 2:30 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: SDWA - SDWACMPC conversion

Hi,

As usual, I'm looking into some old ESTAE code.
More specifically the System Diagnostic Work area.
Does anyone have any sample code to share which interprets and converts the
two 12-Bit codes of SDWACMPC into a displayable format ?
.
I'm trying to keep the size of the module small and would prefer not to use
any Translation Table.
.
Anyone have any code they could share ?
.
.
Thank You
Paul D'Angelo
.
.
.
  

Re: SDWA - SDWACMPC conversion

[Charles Mills]

My code is half in assembler and half in C++ so not much use to others but

- one of the twelve bits fields is the User ABEND code. If it is non-zero,
format it as U where  is the decimal (CVD and UNPK) value of the 12
bits.
- the other is the System ABEND code. If it is non-zero, format it as Sxxx
where xxx is the hex value of the twelve bits. There are other threads here
that have covered binary to hex conversion -- there are lots of ways to do
it.

They should never both be non-zero on an ABEND. It is possible but unlikely
they are both zero. If so, I think there is a bit somewhere that tells you
whether this is a U or an S000 ABEND. If it were me and I was trying to
be compact, I might just format the S-code if it were non-zero, and else the
U-code (zero or not).

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of esst...@juno.com
Sent: Wednesday, April 4, 2018 2:30 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: SDWA - SDWACMPC conversion

Hi,

As usual, I'm looking into some old ESTAE code.
More specifically the System Diagnostic Work area.
Does anyone have any sample code to share which interprets and converts the
two 12-Bit codes of SDWACMPC into a displayable format ?
.
I'm trying to keep the size of the module small and would prefer not to use
any Translation Table.
.
Anyone have any code they could share ?
.
.
Thank You
Paul D'Angelo
.
.
.
  

SDWA - SDWACMPC conversion

[esst...@juno.com]

Hi,

As usual, I'm looking into some old ESTAE code.
More specifically the System Diagnostic Work area.
Does anyone have any sample code to share which interprets and converts the two 
12-Bit codes of SDWACMPC into a displayable format ?
.
I'm trying to keep the size of the module small and would prefer not to use any 
Translation Table.
.
Anyone have any code they could share ?
.
.
Thank You
Paul D'Angelo
.
.
.