Re: Don Higgins has retired from z390 development again

[Steve Thompson]

Amen!!

Enjoy your retirement.

Steve Thompson

On 3/5/2024 4:47 PM, David Kreuter wrote:

All the best and two beautiful words: “clear scan”
David

From: IBM Mainframe Assembler List  on behalf of 
Ecbyahoo <086a7e5ec0f7-dmarc-requ...@listserv.uga.edu>
Sent: Tuesday, March 5, 2024 4:16:29 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Subject: Re: Don Higgins has retired from z390 development again

Don,

That is great news about the clear scans and I hope you have a wonderful and 
relaxing retirement with your wife!

E.Clay
"The best of all is, God is with us." John Wesley


On Mar 5, 2024, at 12:45 PM, Don Higgins  wrote:

All



I have retired again from z390 development after having survived esophageal
cancer, kidney cancer, and thyroid cancer over the past 2 years.  All my
scans are now clear of cancer, and I feel well again.  So at 79 I'm planning
to spend more time with my wife Charlotte traveling and relaxing.



I will miss working with the current z390 core development team: Abe
Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on.



I also miss working with Melvyn Maltz and John Ehrman who supported z390.
Melvyn developed the z390 CICS emulation, and John invited me to present
z390 at several SHARE sessions.



For those interested in learning more about z390, the current development
site is here:  https://github.com/z390development/z390



The original website I maintained from 2004 until 2012 when I turned it over
to Abe is here:  https://z390.org/



All z390 code is written in J2SE Java  and is open source.



The purpose of z390 is to help those interested in learning, developing, and
executing mainframe assembler programs on Windows and Linux.



Don Higgins

d...@higgins.net 

www.donhiggins.org 




--
Regards, Steve Thompson

Re: Don Higgins has retired from z390 development again

[David Kreuter]

All the best and two beautiful words: “clear scan”
David

From: IBM Mainframe Assembler List  on behalf 
of Ecbyahoo <086a7e5ec0f7-dmarc-requ...@listserv.uga.edu>
Sent: Tuesday, March 5, 2024 4:16:29 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Subject: Re: Don Higgins has retired from z390 development again

Don,

That is great news about the clear scans and I hope you have a wonderful and 
relaxing retirement with your wife!

E.Clay
"The best of all is, God is with us." John Wesley

> On Mar 5, 2024, at 12:45 PM, Don Higgins  wrote:
>
> All
>
>
>
> I have retired again from z390 development after having survived esophageal
> cancer, kidney cancer, and thyroid cancer over the past 2 years.  All my
> scans are now clear of cancer, and I feel well again.  So at 79 I'm planning
> to spend more time with my wife Charlotte traveling and relaxing.
>
>
>
> I will miss working with the current z390 core development team: Abe
> Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on.
>
>
>
> I also miss working with Melvyn Maltz and John Ehrman who supported z390.
> Melvyn developed the z390 CICS emulation, and John invited me to present
> z390 at several SHARE sessions.
>
>
>
> For those interested in learning more about z390, the current development
> site is here:  https://github.com/z390development/z390
>
>
>
> The original website I maintained from 2004 until 2012 when I turned it over
> to Abe is here:  https://z390.org/
>
>
>
> All z390 code is written in J2SE Java  and is open source.
>
>
>
> The purpose of z390 is to help those interested in learning, developing, and
> executing mainframe assembler programs on Windows and Linux.
>
>
>
> Don Higgins
>
> d...@higgins.net 
>
> www.donhiggins.org 
>
>

Re: Don Higgins has retired from z390 development again

[Ecbyahoo]

Don,

That is great news about the clear scans and I hope you have a wonderful and 
relaxing retirement with your wife!

E.Clay
"The best of all is, God is with us." John Wesley

> On Mar 5, 2024, at 12:45 PM, Don Higgins  wrote:
> 
> All
> 
> 
> 
> I have retired again from z390 development after having survived esophageal
> cancer, kidney cancer, and thyroid cancer over the past 2 years.  All my
> scans are now clear of cancer, and I feel well again.  So at 79 I'm planning
> to spend more time with my wife Charlotte traveling and relaxing.
> 
> 
> 
> I will miss working with the current z390 core development team: Abe
> Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on.
> 
> 
> 
> I also miss working with Melvyn Maltz and John Ehrman who supported z390.
> Melvyn developed the z390 CICS emulation, and John invited me to present
> z390 at several SHARE sessions.
> 
> 
> 
> For those interested in learning more about z390, the current development
> site is here:  https://github.com/z390development/z390
> 
> 
> 
> The original website I maintained from 2004 until 2012 when I turned it over
> to Abe is here:  https://z390.org/
> 
> 
> 
> All z390 code is written in J2SE Java  and is open source.
> 
> 
> 
> The purpose of z390 is to help those interested in learning, developing, and
> executing mainframe assembler programs on Windows and Linux.
> 
> 
> 
> Don Higgins
> 
> d...@higgins.net 
> 
> www.donhiggins.org   
> 
> 

Re: Don Higgins has retired from z390 development again

[Abe Kornelis]

Don,

We've worked together for over 20 years with on z390.
I have always appreciated your kind patience
and your responsiveness when issues were uncovered.

I hope you will enjoy your retirement for a while.
Family, friends, and all other things you might want to do.

Thank you for your kindness, your friendliness,
and for all the years of cooperation.
And thank you for creating and sharing z390.

May you have many more years in good health!
We'll miss you - we'll think of you.

Kind regards,
Abe
===


Op 05/03/2024 om 21:45 schreef d...@higgins.net:
>
> *All*
>
> * *
>
> *I have retired again from z390 development after having survived
> esophageal cancer, kidney cancer, and thyroid cancer over the past 2
> years.  All my scans are now clear of cancer, and I feel well again. 
> So at 79 I’m planning to spend more time with my wife Charlotte
> traveling and relaxing.*
>
> * *
>
> *I will miss working with the current z390 core development team: Abe
> Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on.*
>
> * *
>
> *I also miss working with Melvyn Maltz and John Ehrman who supported
> z390.  Melvyn developed the z390 CICS emulation, and John invited me
> to present z390 at several SHARE sessions.*
>
> * *
>
> *For those interested in learning more about z390, the current
> development site is here:  https://github.com/z390development/z390 *
>
> * *
>
> *The original website I maintained from 2004 until 2012 when I turned
> it over to Abe is here:  https://z390.org/*
>
> * *
>
> *All z390 code is written in J2SE Java  and is open source. *
>
> * *
>
> *The purpose of z390 is to help those interested in learning,
> developing, and executing mainframe assembler programs on Windows and
> Linux.*
>
> * *
>
> Don Higgins
>
> d...@higgins.net
>
> www.donhiggins.org 
>
>  
>

Don Higgins has retired from z390 development again

[Don Higgins]

All

 

I have retired again from z390 development after having survived esophageal
cancer, kidney cancer, and thyroid cancer over the past 2 years.  All my
scans are now clear of cancer, and I feel well again.  So at 79 I'm planning
to spend more time with my wife Charlotte traveling and relaxing.

 

I will miss working with the current z390 core development team: Abe
Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on.

 

I also miss working with Melvyn Maltz and John Ehrman who supported z390.
Melvyn developed the z390 CICS emulation, and John invited me to present
z390 at several SHARE sessions.

 

For those interested in learning more about z390, the current development
site is here:  https://github.com/z390development/z390 

 

The original website I maintained from 2004 until 2012 when I turned it over
to Abe is here:  https://z390.org/

 

All z390 code is written in J2SE Java  and is open source. 

 

The purpose of z390 is to help those interested in learning, developing, and
executing mainframe assembler programs on Windows and Linux.

 

Don Higgins

d...@higgins.net  

www.donhiggins.org   

 

Re: Decimal Floating Point Numbers

[Gary L Peskin]

But you need to look at the bias for the exponent.  Both views would be encoded 
the same. I guess I didn't explain this very well before but this example will 
help.  For the short format, there are 7 significant digits.  For the LUV, bias 
of the exponent is 95.  For the RUV, bias of the exponent is 101.  See this in 
figure 20-2 that we mentioned before.

Also, I think we're getting cohorts mixed up with LUV/RUV. What you're showing 
below are two different members of a cohort.  Not too different views of the 
same representation. But that's another story. I think you'll see what I mean 
below.

Let's take the number 7.  This can be encoded with the LUV as 7.00 x 10**0  
or as 700. x 10**-6.  In both cases the significand is represented the 
exact same as 700.  For LUV, the decimal point is implied to the right of 
the seven.  For RUV, the implied decimal is to the right of the rightmost zero.

For LUV, the unbiased exponent is 95 since 95 - 95 = 0.
For RUV, the unbiased exponent is 95 since 95 - 101 = -6.

So in BOTH cases, the unbiased exponent (which is what is encoded in the 
representation in memory) is 95. And in both cases the significand is encoded 
as 700. The representation in memory is the SAME. It's just a matter of 
whether you want to look at as

7.00 x 10 * (95-95)
-or-
700 x 10 * (95-101)

I hope this example helps.

Take care,
Gary

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Abe Kornelis
Sent: Tuesday, March 5, 2024 8:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Decimal Floating Point Numbers

Hi Peter,

thanks for your response. Nice to hear from you :-)

They would be encoded quite differently.
Say you'd encode the value seven.
In LUV this would be 7.0*10**0
In RUV this would be 07*10**0

In either case the number of zero digits would depend on the format of the DFP: 
D/E/X

For the sake of completeness:
In LUV the digit 7 would go into the combination field In RUV the digit would 
be at the end of the significand.

Unless I am quite mistaken, which is still quite conceivable :-(

Kind regards,
Abe
===


Op 05/03/2024 om 15:19 schreef Peter Relson:
> I am imagining (and could easily be wrong) that the hex data is identical 
> across the views (and thus the instruction implementation does not care about 
> the view), and it's only a question of which bits you choose to look at (or 
> what arithmetic logical manipulation you use) if formatting the value for 
> human consumption.
>
> For example, the exponent differs, as does the significand (a term I had not 
> known of until seeing it in the POp).
>
> I don't know what kind of dump was being looked at, but perhaps there's a 
> formatting option within the dump viewing program that might say "show me 
> this as a Right-Unit View DFP value".
>
> Peter Relson
> z/OS Core Technology Design

Re: Decimal Floating Point Numbers

[Gary L Peskin]

Abe.  I think you're still missing the point.  I'll reply to a later message to 
straighten this out.

Gary

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Abe Kornelis
Sent: Monday, March 4, 2024 3:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Decimal Floating Point Numbers

Hi Gary,

Thanks for the PoP quote. I must have missed that one.

Otherwise, I roughly got as far as you did.
One can move the (virtual) decimal point at will, provided you adjust the 
exponent value accordingly.

When e.g. adding two DFP numbers, the LUV vs. RUV does not seem to matter - the 
addition results are the same in either case.

When adding a RUV-encoded value to a LUV-encoded value the addition is bound to 
produce rubbish.
So it seems relevant to know how to distinguish.

Since the processor seems not to make the distinction, I think I must be 
something...

Kind regards,
Abe
===


Op 04/03/2024 om 09:08 schreef Gary L Peskin:
> Hi, Abe -
>
>  
>
> In the version of the PoP that I'm looking at, it states that ". Except where 
> otherwise indicated, ...DFP [is defined] in terms of the right-units view. So 
> I think that's just a convention in the documentation.
>
>  
>
> As far as LUV vs RUV, a given value is represented the same in a register or 
> storage regardless of whether you view it as LUV or RUV.  These are just 
> "views" at the number.  You can view it as if the decimal point is either to 
> the right of the leftmost digit (LUV) or to the right of the rightmost digit 
> (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same 
> as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for 
> the exponent in figure 20-2 differ by the same amount as the number of digits 
> in the significand. By considering the bias as having changed, it just 
> accounts for where the decimal point is even though the representation is the 
> same. It’s just a question of how you want to view the number. I probably 
> didn’t explain this very well but I hope you get  the idea.
>
>  
>
> Frankly, I think this whole LUV vs RUV discussion is more confusing than 
> helpful but I guess some people like to think of their numbers as x. * 
> 10y and others prefer to think of them as x * 10z.
>
>  
>
> And figure 9-1 is just showing the possible range of values with an unbiased 
> exponent. It’s not meant to indicate any representation of the top/bottom of 
> the range in memory which uses biased exponents.
>
>  
>
> HTH,
>
> Gary
>
>  
>
> -Original Message-
> From: IBM Mainframe Assembler List  
> On Behalf Of Abe Kornelis
> Sent: Sunday, March 3, 2024 10:29 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Decimal Floating Point Numbers
>
>  
>
> All,
>
>  
>
> There's something with decimal floating point numbers that has been eluding 
> me for a long time.
>
>  
>
> According to PoP chapter 20, DFP numbers may be encoded as either Left-Units 
> View or Right-Units View.
>
> As shown in e.g. figure 20-2.
>
>  
>
> Yet when looking at a DFP value in a dump, it seems to be impossible to tell 
> which view applies.
>
> Just like a packed decimal does not have the decimal point encoded - you just 
> have to know where the programmer decided it to be.
>
> Is it indeed like that with LUV vs. RUV - you just have to know?
>
>  
>
> Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV 
> representation limits.
>
> Instruction descriptions equally make no mention of LUV vs. RUV.
>
>  
>
> To me it appears the instruction always treat the data as RUV. Is this 
> correct?
>
> Or am I missing something obvious?
>
>  
>
> Thanks in advance,
>
> Abe Kornelis.
>
> ==

Re: Decimal Floating Point Numbers

[Abe Kornelis]

Hi Peter,

thanks for your response. Nice to hear from you :-)

They would be encoded quite differently.
Say you'd encode the value seven.
In LUV this would be 7.0*10**0
In RUV this would be 07*10**0

In either case the number of zero digits would depend
on the format of the DFP: D/E/X

For the sake of completeness:
In LUV the digit 7 would go into the combination field
In RUV the digit would be at the end of the significand.

Unless I am quite mistaken, which is still quite conceivable :-(

Kind regards,
Abe
===


Op 05/03/2024 om 15:19 schreef Peter Relson:
> I am imagining (and could easily be wrong) that the hex data is identical 
> across the views (and thus the instruction implementation does not care about 
> the view), and it's only a question of which bits you choose to look at (or 
> what arithmetic logical manipulation you use) if formatting the value for 
> human consumption.
>
> For example, the exponent differs, as does the significand (a term I had not 
> known of until seeing it in the POp).
>
> I don't know what kind of dump was being looked at, but perhaps there's a 
> formatting option within the dump viewing program that might say "show me 
> this as a Right-Unit View DFP value".
>
> Peter Relson
> z/OS Core Technology Design

Re: Decimal Floating Point Numbers

[Peter Relson]

I am imagining (and could easily be wrong) that the hex data is identical 
across the views (and thus the instruction implementation does not care about 
the view), and it's only a question of which bits you choose to look at (or 
what arithmetic logical manipulation you use) if formatting the value for human 
consumption.

For example, the exponent differs, as does the significand (a term I had not 
known of until seeing it in the POp).

I don't know what kind of dump was being looked at, but perhaps there's a 
formatting option within the dump viewing program that might say "show me this 
as a Right-Unit View DFP value".

Peter Relson
z/OS Core Technology Design