In , on 07/22/2012
at 11:29 AM, Scott Ford said:
>I was aware of the hardware on the machines, since my late father was
>a FE on them. Didn't really know anything about the opsys or
>programming languages.
There were two OS's; EXEC 2 derived from the OS on the 1107 and EXEC 8
was new. AFAIK t
The original 1108 was Univac, not Unisys. Hence Unisys inherited it when the
merger was done to create Unisys.
Lloyd
- Original Message
From: Scott Ford
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, July 20, 2012 8:08:18 PM
Subject: Re: COBOL packed decimal
Shmuel,
Who did the inherit
I was aware of the hardware on the machines, since my late father was a FE on
them. Didn't really know anything about the opsys or programming languages. So
the history is very interesting
Scott ford
www.identityforge.com
On Jul 22, 2012, at 8:37 AM, "Shmuel Metz (Seymour J.)"
wrote:
> In <1
In <1342898015.24312.yahoomail...@web164504.mail.gq1.yahoo.com>, on
07/21/2012
at 12:13 PM, Scott Ford said:
>I wasnt sure if the 1108 had come from RCA or Buroughs
The 1108 dates back to the old Remington-Rand or Sperry Rand, not to
the RCA EDP acquisition. It's possible that Unisys picked u
In <5139351871042018.wa.paulgboulderaim@listserv.ua.edu>, on
07/21/2012
at 10:08 AM, Paul Gilmartin said:
>That's pretty vague. Does the standard specify the behavior as
>implementation defined,
Which standard? COBOL has had many over the years. The more recent
standards are stricter abo
In , on 07/20/2012
at 08:08 PM, Scott Ford said:
>Who did the inherit the 1108 from ? My dad worked for Unisys on the
>1108sdude
Unisys was a merger of Burroughs and UNIVAC; They kept the B6500 line
from Burroughs and the 1100[1] line from UNIVAC.
[1] The 1108, 1110, 1106 and successors;
My dad worked on the 1108 II, I think at Ft. Harrison in Indy
Scott ford
www.identityforge.com
On Jul 21, 2012, at 9:26 AM, John Gilmore wrote:
> The Unisys 1108, a (36-bit) word machine, was originally the UNIVAC
> 1108 I (circa 1965) and the UNIVAC 1108 II (circa 1968); and UNIVAC
> was at th
Subject: Re: COBOL packed decimal
On Fri, 20 Jul 2012 11:43:45 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>Is this because Unisys is deficient in conformance to the standard,
>>or because IBM's implementation contains an extension to the
>>standard?
>
>No, it'
/
From: John Gilmore
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 21, 2012 9:26 AM
Subject: Re: COBOL packed decimal
The Unisys 1108, a (36-bit) word machine, was originally the UNIVAC
1108 I (circa 1965) and the UNIVAC 1108 II (circa 1968); and UNIVAC
was at that
On Fri, 20 Jul 2012 11:43:45 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>Is this because Unisys is deficient in conformance to the standard,
>>or because IBM's implementation contains an extension to the
>>standard?
>
>No, it's because UNIVAC used ones complement arithmetic on most of its
>lines, In
The Unisys 1108, a (36-bit) word machine, was originally the UNIVAC
1108 I (circa 1965) and the UNIVAC 1108 II (circa 1968); and UNIVAC
was at that time a division of Sperry Rand.
John Gilmore, Ashland, MA, 01721 - USA
On 7/20/12, Scott Ford wrote:
> Shmuel,
>
> Who did the inherit the 1108 from
Shmuel,
Who did the inherit the 1108 from ? My dad worked for Unisys on the
1108sdude
Scott ford
www.identityforge.com
On Jul 20, 2012, at 11:43 AM, "Shmuel Metz (Seymour J.)"
wrote:
> In <9307538697441482.wa.paulgboulderaim@listserv.ua.edu>, on
> 07/19/2012
> at 09:22 AM, Paul Gil
In <9307538697441482.wa.paulgboulderaim@listserv.ua.edu>, on
07/19/2012
at 09:22 AM, Paul Gilmartin said:
>Is this because Unisys is deficient in conformance to the standard,
>or because IBM's implementation contains an extension to the
>standard?
No, it's because UNIVAC used ones complem
I am also curious about why ?
Scott ford
www.identityforge.com
On Jul 19, 2012, at 10:22 AM, Paul Gilmartin wrote:
> On Thu, 19 Jul 2012 08:30:44 -0400, Shmuel Metz (Seymour J.) wrote:
>>
>>> As a COBOL programmer its not something I generally have to concern
>>> myself with.
>>
>> Not on an
On Thu, 19 Jul 2012 08:30:44 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>As a COBOL programmer its not something I generally have to concern
>>myself with.
>
>Not on an IBM platform, but if you were doing COBOL on a Unisys 2200
>you'd need to worry about it.
>
Is this because Unisys is deficient in
In <1342461997.35207.yahoomail...@web122104.mail.ne1.yahoo.com>, on
07/16/2012
at 11:06 AM, Frank Swarbrick said:
>As a COBOL programmer its not something I generally have to concern
>myself with.
Not on an IBM platform, but if you were doing COBOL on a Unisys 2200
you'd need to worry about i
Saturday, July 14, 2012 7:41 PM
>Subject: Re: COBOL packed decimal
>
>In <1342217201.53198.yahoomail...@web122104.mail.ne1.yahoo.com>, on
>07/13/2012
> at 03:06 PM, Frank Swarbrick said:
>
>>Negative zero, huh? Must be that new math, thing. :-)
>
>New?
At 14:49 -0400 on 07/15/2012, John P. Baker wrote about Re: COBOL
packed decimal:
In the IBM z/Architecture Principles of Operation, publication number
SA22-7832-08, on page 8-2 it states that X'F' is an alternate encoding for a
positive sign. However, in the programming note to fig
At 00:06 -0400 on 07/15/2012, John P. Baker wrote about Re: COBOL
packed decimal:
A positive value is identified by a sign encoded as --
X'A'
X'C' (Preferred)
X'E'
X'F'
A negative value is identified by a sign encoded as --
arms went off and only one time since have I seen more VP's in
the computer room.
The fix was (if memory serves me) change the sort control card to BI.
Ed
On Jul 15, 2012, at 12:12 AM, Robert A. Rosenberg wrote:
At 10:22 -0600 on 07/14/2012, Steve Comstock wrote about Re: COBOL
packed
packed) field.
John P. Baker
NGSSA, LLC
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith
Sent: Sunday, July 15, 2012 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL packed decimal
John P. Baker wrote:
>A positi
Mr Hermannsfeldt writes:
Now, it is true that DFP helps with some of those problems, but when
programming in a high-level language one generally doesn't know what
kind of floating point will be used. Some, like HFP, give a truncated
quotient on divide (except on the 360/91), others a rounded resu
I had a similar story. On a 370/138 at an auto insurance company, the rating
program (vendor supplied) would immediately "eat the machine".
In those days, there was an actual CPU meter on the console. Whenever this job
would run the meter "pegged" for the duration.
Basic logic was input pre-proc
John P. Baker wrote:
>A positive value is identified by a sign encoded as --
>X'A'
>X'C' (Preferred)
>X'E'
>X'F'
>A negative value is identified by a sign encoded as --
>X'B'
>X'D' (Preferred)
>The preferred encoding are always generated by packed decimal instructions,
In <1342217201.53198.yahoomail...@web122104.mail.ne1.yahoo.com>, on
07/13/2012
at 03:06 PM, Frank Swarbrick said:
>Negative zero, huh? Must be that new math, thing. :-)
New? You had negative zero in the ones complement and sign-magnitude
computers; the former still survive at Unisys.
--
In
,
on 07/14/2012
at 08:08 AM, John Gilmore said:
>Integer arithmetic should never be done with anything but binary
>integers.
Your reasoning is correct for two's complement machines, e.g., z, but
is incorrect in general.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
In <5001ef16.8000...@t-online.de>, on 07/15/2012
at 12:13 AM, Bernd Oppolzer said:
>I don't think that there is any cultural or philosophical
>difference between mainframe or distributed/workstation
>developers, given the same number of years of experience and
>skill etc. - I know hundreds
(John Gilmore wrote)
> A little presumptuously perhaps, I shall reply for 'someone' He or
> she would appear to be a soul mate.
> The remark about floating-point that Mr Hermannsfeldt attributes to
> Knuth are relevant to HFP and, perhaps, BFP. Their timing moots any
> relevance to Cowlishaw'
At 10:22 -0600 on 07/14/2012, Steve Comstock wrote about Re: COBOL
packed decimal:
I think he's saying keep amounts in pennies as binary fields.
Convert to dollars + decimal point + cents when you display
these fields.
That works for addition and subtraction. It gets more complex when
y packed decimal instructions,
The alternative encoding are accepted as input to packed decimal
instructions.
John P. Baker
NGSSA, LLC
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of zMan
Sent: Saturday, July 14, 2012 11:12 PM
To: IB
On Sat, Jul 14, 2012 at 5:46 PM, John P. Baker wrote:
> By the way, a 5-byte field capable of containing a 9-digit packed decimal
> value has a 0.55% probability of containing a valid packed decimal value
> (taking into consideration all six (6) valid sign representations) and a
> 0.18% probabili
Ceretain of Bernd Oppolzer's concerns are addressed in the designs of
both ANSI BFP and ANSI DFP and in their zArchitecture implementations.
Ad hoc schemes are in fact replaced by hardware implemented ones.
One of their most interesting features is the support they provide for
non-standard values
On Sat, 14 Jul 2012 14:39:04 -0400, John Gilmore wrote:
>
>Some years ago this situation changed dramatically. Mike
>Cowlishaw---he who designed REXX---devised what is now ANSI decimal
>floating point (DFP). DFP behaves consistently in ways that do not
>surprise accountants. (All three floating
On 7/14/12, John Gilmore wrote:
> A little presumptuously perhaps, I shall reply for 'someone' He or
> she would appear to be a soul mate.
>
> The remark about floating-point that Mr Hermannsfeldt attributes to
> Knuth are relevant to HFP and, perhaps, BFP. Their timing moots any
> relevance to
A little presumptuously perhaps, I shall reply for 'someone' He or
she would appear to be a soul mate.
The remark about floating-point that Mr Hermannsfeldt attributes to
Knuth are relevant to HFP and, perhaps, BFP. Their timing moots any
relevance to Cowlishaw's DFP.
Moreover, they arev not re
g into
consideration only the two (2) preferred sign representations).
John P. Baker
NGSSA, LLC
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Saturday, July 14, 2012 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subje
frame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Saturday, July 14, 2012 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL packed decimal
There is one thing I like very much about packed decimal data, that is its
redundancy.
With packed decimal data
There is one thing I like very much about packed decimal data,
that is its redundancy.
With packed decimal data, the probability that the use of an
un-initialized variable will lead to a run time error (0C7 abend)
is very high. Take a nine digit decimal variable - the probability
that it contains
What I was saying was simply that integer values, those in the sequence
. . . -5, -4, -3, -2, -1, 0, +1, +2, +3, +4, +5, . . .
should always be binary. Bean counters, perform indices, and the like
obviously fall in this category. If you are counting something,
beans, iterations, days
Tom Ross's Share presentation on COBOL performance is excellent.
Scott ford
www.identityforge.com
On Jul 14, 2012, at 12:34 PM, Chris Mason wrote:
> John
>
>> Integer arithmetic should never be done with anything but binary integers.
>
> "What never?"
>
> One excuse might be when the only a
find/fix was a COBOL (VS?)
>>>> routine intended to distribute the rounding difference to a set of records.
>>>> Perform until zero left to distribute. It looped at negative zero. I didn't
>>>> write it, I don't remember my precise fix.
>>
John
> Integer arithmetic should never be done with anything but binary integers.
"What never?"
One excuse might be when the only arithmetic to be performed is to add up "a
column" of numbers and present the result. Converting to packed decimal, adding
using the packed decimal instruction and
idn't
write it, I don't remember my precise fix.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Frank Swarbrick
Sent: Friday, July 13, 2012 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL packed decimal
Excellent!
ft to distribute. It looped at negative zero. I didn't
>> write it, I don't remember my precise fix.
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Frank Swarbrick
>>
.EDU]
>> On Behalf Of Frank Swarbrick
>> Sent: Friday, July 13, 2012 3:07 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL packed decimal
>>
>> Excellent! Thank you very much!
>> Subtle is right! :-)
>> Negative zero, huh? Must be that new mat
ginal Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Frank Swarbrick
> Sent: Friday, July 13, 2012 3:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL packed decimal
>
> Excellent! Thank you very much!
> Subtle is ri
Excellent! Thank you very much!
Subtle is right! :-)
Negative zero, huh? Must be that new math, thing. :-)
Frank
>
> From: "Dan Skomsky @ Home"
>To: IBM-MAIN@LISTSERV.UA.EDU
>Sent: Friday, July 13, 2012 3:24 PM
>Subject: Re: COBO
decimal values '0F' and '0C' equal, while the CLC
> will not."
>
> The same instructions are generated in Enterprise COBOL as were for
> COBOL/370.
>
> HTH
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MA
lto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Itschak Mugzach
Sent: Friday, July 13, 2012 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL packed decimal
Zero and add pack.
ITschak
On Sat, Jul 14, 2012 at 12:05 AM, Frank Swarbrick wrote:
> COBOL code
> 77 ws-num-packed
Zero and add pack.
ITschak
On Sat, Jul 14, 2012 at 12:05 AM, Frank Swarbrick wrote:
> COBOL code
> 77 ws-num-packed pic S9(9) packed-decimal.
>
> add 2 to ws-num-packed
>
>
> Generated assembler:
>
>
> 14
> ADD
>00036A GN=16EQU
> *
>00036A FA40
On Fri, Jul 13, 2012 at 2:05 PM, Frank Swarbrick
wrote:
> COBOL code
> 77 ws-num-packed pic S9(9) packed-decimal.
>
> add 2 to ws-num-packed
>
>
> Generated assembler:
>
>
> 14 ADD
>00036A GN=16EQU *
>00036A FA40 8008 A02C AP8(5,8)
COBOL code
77 ws-num-packed pic S9(9) packed-decimal.
add 2 to ws-num-packed
Generated assembler:
14
ADD
00036A GN=16 EQU
*
52 matches
Mail list logo
