: 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 ha
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
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 possibilit
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
: 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&#
> 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.
Otherwis
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.ib
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
- 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 starte
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 m
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
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 co
>> 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
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
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'
I
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.
ht
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 b
--
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
: 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
iday, 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'F0F0F1F
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
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.”
T
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>
du/~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 nota
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)
@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
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
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
R 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
T
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 righ
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.
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
>> ...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
EMBLER-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 S
: 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
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
il 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 af
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
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
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
40 matches
Mail list logo
