Home > Archive > ASM370 > August 2007 > HLASM Floating Point Field - Remainder?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
HLASM Floating Point Field - Remainder?
|
|
| Hansedl 2007-06-19, 9:57 pm |
| Hi group,
I am looking at a record layout that has a floating point field.
The field is four bytes, it is for short data operations known as
format "E" and
uses 32 bits of data from the registers. The field contains
x'43E88000'. This means the x'43' denotes the sign bit and the
characteristic or
exponent. The x'E88000' is the mantissa or fraction (binary '1110
1000 1000'). The exponent is binary '100 0011' (67 decimal). In
order to support
negative characteristics, the assembler increases the exponent by 64
before converting it to binary. The bias is 64 so 67 - 64 = 3 (the
exponent).
So the value is '111.010001000' because we move the radix point three
places to the right. This field contains the Elapsed time, in seconds
which is
binary '111.010001000' which looks like about decimal number 7. This
is where may calculator doesn't keep up with precision. Binary
'11101000' is
decimal 232, but I don't think you can move the radix point around by
two. So binary '111.010001000' is 7 + a bit more. The binary '.
01000100'
enters as binary '1000100' and is decimal 68. But the leading zero
means something on '.010001000'. I could say the number is greater
than 7, but
floating point is known for accuracy and I would be loosing a bit of
accuracy.
Q). How do I figure out my "remainder" (.010001000)?
Another number I have is x'423c0000'. So x'42' is binary '1000010'
or decimal 66. And 66 - 64 = 2. So x'3C' is binary '111100'
adjusted two to
the right is binary '11.11' or about 3 with a remainder of
something? This field is the length of the sample period. The same
header is used for
different record layouts. I see this same field in a different record
displayed as x'43528000'. So my exponent is 3 and my fraction is x
'528000',
or perhaps binary '1010010 10000000 0000 0000'. So Binary '10100101'
is decimal 165, but I never get anywhere converting this number. So
binary
'101.0011' is just greater than 5.
Any tips on this would be appreciated.
Thank you, Dave H.
| |
| glen herrmannsfeldt 2007-06-19, 9:57 pm |
| Hansedl wrote:
(snip)
> uses 32 bits of data from the registers. The field contains
> x'43E88000'. This means the x'43' denotes the sign bit and the
> characteristic or
> exponent. The x'E88000' is the mantissa or fraction (binary '1110
> 1000 1000'). The exponent is binary '100 0011' (67 decimal). In
> order to support
> negative characteristics, the assembler increases the exponent by 64
> before converting it to binary. The bias is 64 so 67 - 64 = 3 (the
> exponent).
> So the value is '111.010001000' because we move the radix point three
> places to the right. This field contains the Elapsed time, in seconds
> which is
The exponent is base 16, so you move three hex digits, or 12 bits,
such that the value us X'E88' or decimal 3720.
(snip)
Another number I have is x'423c0000'. So x'42' is binary '1000010'
or decimal 66. And 66 - 64 = 2. So x'3C' is binary '111100'
adjusted two
Again two hex digits to the right for X'42' or 66.
If this is homework, please reference the newsgroup.
-- glen
| |
| Hansedl 2007-06-28, 9:57 pm |
| On Jun 19, 6:30 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Hansedl wrote:
>
> (snip)
>
>
> The exponent is base 16, so you move three hex digits, or 12 bits,
> such that the value us X'E88' or decimal 3720.
>
> (snip)
>
> Another number I have is x'423c0000'. So x'42' is binary '1000010'
> or decimal 66. And 66 - 64 = 2. So x'3C' is binary '111100'
> adjusted two
>
> Again two hex digits to the right for X'42' or 66.
>
> If this is homework, please reference the newsgroup.
>
> -- glen
Glen,
Thank you for your response. The records are from our z/VM system
Performance Monitor. I was asked to cut the interval times down. I
started by looking at what was actually collected. The first field
contains elapsed time in seconds so x'E88' is 3,270 seconds or 62
minutes. Doesn't look like I can report by 15 minute intervals with
this data. The second field is the length of the sample period so
x'3C' is 60. This may be in seconds. The third field is from the
same data but shows x'528' or 1,320. Possibly 22 seconds. Now I'll
call IBM and ask then about the intervals which I have found the
duration of.
Thanks again, Dave H.
| |
| Barry Schwarz 2007-06-28, 9:57 pm |
| On Wed, 27 Jun 2007 08:27:03 -0700, Hansedl
<david.l.hansen@co.hennepin.mn.us> wrote:
>On Jun 19, 6:30 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>Glen,
> Thank you for your response. The records are from our z/VM system
>Performance Monitor. I was asked to cut the interval times down. I
>started by looking at what was actually collected. The first field
>contains elapsed time in seconds so x'E88' is 3,270 seconds or 62
>minutes. Doesn't look like I can report by 15 minute intervals with
>this data. The second field is the length of the sample period so
>x'3C' is 60. This may be in seconds. The third field is from the
>same data but shows x'528' or 1,320. Possibly 22 seconds. Now I'll
>call IBM and ask then about the intervals which I have found the
>duration of.
In my admittedly limited experience (and I don't use VM at all), I
have never seen a product intended for the mainframe express time in
floating point. Are you sure you have the right fields and formats?
Remove del for email
| |
| Don Poitras 2007-06-28, 9:57 pm |
| Barry Schwarz <schwarzb@doezl.net> wrote:
> On Wed, 27 Jun 2007 08:27:03 -0700, Hansedl
> <david.l.hansen@co.hennepin.mn.us> wrote:
[color=darkred]
> In my admittedly limited experience (and I don't use VM at all), I
> have never seen a product intended for the mainframe express time in
> floating point. Are you sure you have the right fields and formats?
SAS/C defines time_t (used in many timing functions) as a double.
> Remove del for email
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
sasdtp@sas.com (919) 531-5637 Cary, NC 27513
| |
| Binyamin Dissen 2007-06-28, 9:57 pm |
| On Thu, 28 Jun 2007 01:55:05 +0000 (UTC) poitras@pobox.com (Don Poitras)
wrote:
:>Barry Schwarz <schwarzb@doezl.net> wrote:
:>> In my admittedly limited experience (and I don't use VM at all), I
:>> have never seen a product intended for the mainframe express time in
:>> floating point. Are you sure you have the right fields and formats?
:>SAS/C defines time_t (used in many timing functions) as a double.
A clock value is 64 bits (not all of them) but is not floating point.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
| |
| Michel Hack 2007-06-28, 9:57 pm |
| On Jun 27, 9:33 pm, Barry Schwarz <schwa...@doezl.net> wrote:
> In my admittedly limited experience (and I don't use VM at all), I
> have never seen a product intended for the mainframe express time in
> floating point.
IEEE double is well suited to hold time in seconds since 1900 (or
1970,
Unix-style) with microsecond resolution, and so is IBM Hex FP. With
at
least 53 bits of precision you can actually cover 300 years at that
resolution, and FP makes it easy to do interpolations on various
scales,
as is needed on non-S/370 machines (i.e. machines without STCK). (The
old POWER machines, up to PPC601 included, did have a real-time
clock.)
So it's true that FP times are perhaps less useful on S/370's
children.
Michel.
| |
|
|
|
|
|