Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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 the current Unisys software for the line is derived
only from EXEC 8.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Lloyd Fuller]

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 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 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 complement arithmetic on most of its
> lines, Including the 1108 et al that Unisys inherited.
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2<http://patriot.net/~shmuel>
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Scott Ford]

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 <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 up the RCA
> Spectra 70, but that's a very different series.
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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 up the RCA
Spectra 70, but that's a very different series.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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 about the results of numeric operations. I
suspect that current Unisys COBOL compilers behave differently from
older ones.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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; not the 1103 or 1105.
I'm not sure whether you want to count the 1107 as part of
that line, but it was certainly the father of the 1108.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Scott Ford]

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 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 ? 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 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 complement arithmetic on most of its
>>> lines, Including the 1108 et al that Unisys inherited.
>>> 
>>> --
>>>Shmuel (Seymour J.) Metz, SysProg and JOAT
>>>Atid/2
>>> We don't care. We don't have to care, we're Congress.
>>> (S877: The Shut up and Eat Your spam act of 2003)
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Scott Ford]

gil,
 
Thats the reason I asked ..see my other post. Could say I have a vested 
interest. My late father

Scott J Ford
Software Engineer
http://www.identityforge.com/
 



From: Paul Gilmartin 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, July 21, 2012 11:08 AM
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's because UNIVAC used ones complement arithmetic on most of its
>lines, Including the 1108 et al that Unisys inherited.
> 
That's pretty vague.  Does the standard specify the behavior as
implementation defined, in which case a conforming program
intended to be portable should avoid relying on either vendor's
behavoir; or does one of the vendors deviate from the standard?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Scott Ford]

John,
Ty, i am more than aware of Unisys and Univac my father worked for them for 37+ 
yrs as a field engineer. 
I wasnt sure if the 1108 had come from RCA or Buroughsbtw my father worked 
on the 1108 hardware
 
Regards, 
Scott J Ford
Software Engineer
http://www.identityforge.com/
 



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 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 ? 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 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 complement arithmetic on most of its
>> lines, Including the 1108 et al that Unisys inherited.
>>
>> --
>>    Shmuel (Seymour J.) Metz, SysProg and JOAT
>>    Atid/2        <http://patriot.net/~shmuel>
>> We don't care. We don't have to care, we're Congress.
>> (S877: The Shut up and Eat Your spam act of 2003)
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Paul Gilmartin]

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, Including the 1108 et al that Unisys inherited.
> 
That's pretty vague.  Does the standard specify the behavior as
implementation defined, in which case a conforming program
intended to be portable should avoid relying on either vendor's
behavoir; or does one of the vendors deviate from the standard?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John Gilmore]

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 ? 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 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 complement arithmetic on most of its
>> lines, Including the 1108 et al that Unisys inherited.
>>
>> --
>> Shmuel (Seymour J.) Metz, SysProg and JOAT
>> Atid/2
>> We don't care. We don't have to care, we're Congress.
>> (S877: The Shut up and Eat Your spam act of 2003)
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Scott Ford]

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 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 complement arithmetic on most of its
> lines, Including the 1108 et al that Unisys inherited.
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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 complement arithmetic on most of its
lines, Including the 1108 et al that Unisys inherited.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Scott Ford]

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 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 conformance to the standard,
> or because IBM's implementation contains an extension to the
> standard?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Paul Gilmartin]

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 conformance to the standard,
or because IBM's implementation contains an extension to the
standard?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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 it.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Frank Swarbrick]

I realize it's not really new.  I was making a small poke at the concept in 
general.  As a COBOL programmer its not something I generally have to concern 
myself with.




>
> From: Shmuel Metz (Seymour J.) 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: 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? You had negative zero in the ones complement and sign-magnitude
>computers; the former still survive at Unisys.
>
>-- 
>     Shmuel (Seymour J.) Metz, SysProg and JOAT
>     Atid/2        <http://patriot.net/~shmuel>
>We don't care. We don't have to care, we're Congress.
>(S877: The Shut up and Eat Your spam act of 2003)
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Robert A. Rosenberg]

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 figure 8-1 on page 8-3,
it suggests that X'F' be used in zoned decimal formats for the high-order
nibble of all bytes save the rightmost, which should be encoded using one of
the recognized sign encodings.


Note that the UNPK will place X'F' as the high nibble of all the 
positions except the low order one (where the sign is the sign nibble 
of the source).


I would note that if the value is nonnegative, an encoding of X'F' 
is preferable to X'C' in that in the zoned decimal format, the 
resulting character string consists of all decimal digits.


It also displays correctly as opposed to the low byte being A-J or {. 
This is also why the names of Type 3/4 SVCs end in these letters 
since they are signed decimal (using a X'Cx' sign).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Robert A. Rosenberg]

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 --

X'B'
X'D' (Preferred)

The preferred encoding are always generated by packed decimal instructions,

The alternative encoding are accepted as input to packed decimal
instructions.


I have a vague memory that the A and B values had to do with the old 
S/360 ASCII mode which is where they were the defaults.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Ed Gould]

Robert:

A life time ago I used to work for a bank and they had bought an  
online system for savings.
What was really fun was that they did not save any signs for any of  
the numbers in the system. it was all assumed to be positive.

Likewise the dates and other fields were all packed unsigned.
We had one (that I can remember of) sacred programs and that did  
interest calculations. No one was allowed anywhere near the program  
(we could look but not touch even that was looked over with interest  
if you asked to look at it.
BTW all programs were assembler. I don't even think the name &  
address program was COBOL as it needed to massage the various numeric  
fields.
My memory is iffy here but we did run into an issue with sort (before  
it became DFSORT). The sort control cards said PD and it choked after  
we upgraded the sort and two months later the sort choked.
The alarms 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 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  
you need to do multiplication (such as computing interest). That  
involves shifting and rounding after the multiplication. IOW: To do  
6%, multiply by 6 and then shift 2 positions to get back to pennies  
(after adding 50 to round up/down).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John P. Baker]

Phil,

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 figure 8-1 on page 8-3,
it suggests that X'F' be used in zoned decimal formats for the high-order
nibble of all bytes save the rightmost, which should be encoded using one of
the recognized sign encodings.  I would note that if the value is
nonnegative, an encoding of X'F' is preferable to X'C' in that in the zoned
decimal format, the resulting character string consists of all decimal
digits.

It is worth noting that the PACK machine instruction does NO validation of
the sign nibble in any byte of the field being packed.  The sign nibble of
the rightmost byte of the source (zoned) field is copied to the rightmost
nibble of the target (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 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,

>The alternative encoding are accepted as input to packed decimal 
>instructions.

I've read elsewhere that x'F' meant "unsigned". Not true?
--
...phsiii

Phil Smith III
p...@voltage.com<mailto:p...@voltage.com>
Voltage Security, Inc.
www.voltage.com<http://www.voltage.com/>
(703) 476-4511 (home office)
(703) 568-6662 (cell)


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John Gilmore]

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 result. If
you want identical results on all systems, you have to be very careful
with rounding modes. (Even if you know its DFP, you might not be able
to set the rounding mode.)


I am happy with his concession that "DFP helps with some of these
problems", but I find the rest of this passage  puzzling.  I cannot
imagine not knowing what kind of floating-point is used or selectable
by a statement-level procedural language (SLPL) implementation I am
using.

I use PL/I a lot, particularly for throwaway, investigational
routines; and for my purposes I most of the time choose to have it use
BFP.  Rounding modes I specify in trivial, macro-generated
assembly-language subroutines.

SLPLs are convenient, but they always represent someone else's (not
always congenial) world view.  When I can, I avoid C and its dialects
because I find their world view uncongenial, and in general I use
assembly language to modify the behavior of an SLPL when I find that
behavior unsatisfactory.

I have no objection to the teaching of a little programming to
demystify computing (in much the way that a little physics is taught
to secondary-school students).  That said, people who cannot tame an
SLPL, make it do their wills, are not professional programmers in any
meaningful sense.  It is not clear to me that they any longer have
useful work to do.  (There was a time when one needed to be able to
program a little in order to use computers at all, but that time is
long past.)

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Staller, Allan]

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-process call subroutine post-process output. I was 
asked to check into the performance of this program.
Very quickly, I noticed that *ALL* fields were "USAGE DISPLAY". 

Without changing a single line of logic, the DISPLAY fields were changed to the 
appropriate internal representation (COMP, COMP-3,...)

The program was no longer noticeable when it ran after the changes.

It turns out that the following sequence of instructions was used for binary 
fields in display prior to the change.

PACK 
CVB
Perform operation
CVD
UNPACK (to store the result).

Changing the fields to the correct internal representation reduce the sequence 
to:

Perform operation

The program logic caused the initial sequence to be executed 8 times for every 
numeric filed used in the program.
PACK, UNPACK, and CVB, CBD are (or at least were) some of the slowest 
instructions on the processor.



> 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 then converting the total to the 
printable form might be an example of where staying with packed decimal is the 
more efficient.

"Well, hardly ever!"

To all following this topic

Even before John Gilmore's assertion, I had in mind to tell a story concerning 
the relative efficiency of packed decimal.

Forty years ago in the north-west of England, an IBM salesman was faced with 
losing one of his customers. Competition had muscled in and proposed a machine 
potentially more suited to the demands made on the customer's business - and 
their pocket. The salesman's response was to propose replacing the 360/30 with 
a 360/25 which I believe had only recently - at the time - been added to the 
360 range, extending it "downwards" - ignoring - *obviously* - the 360/20!
.. remainder snipped



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Phil Smith]

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,

>The alternative encoding are accepted as input to packed decimal
>instructions.

I've read elsewhere that x'F' meant "unsigned". Not true?
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Shmuel Metz (Seymour J.)]

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 of them - both  species,
>and I myself am doing - and teaching - both.

You don't see a difference in attitude towards, e.g., code and design
reviews, regression testing? Are you including the attitudes of
management or only those of the worker bees?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[glen herrmannsfeldt]

(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's DFP.

Well, the remark, as far as I know, was intended to be general,
and at the time there were many different floating point systems
in use. 
 
> Moreover, they arev not relevant to it: it uses decimal digits, 
> sand Mr Hermamnnsfeldt's post does not petray any acquaintance 
> with it.

I have followed it since before 2008, a few times posted (maybe in
other groups) that I believe it is a good idea. It should reduce,
for example, the number if people who find that (1./3.)*3. is not 1.0,
and in fact truncates to zero.
 
> The rest of Mr Hermannsfeldt's is also less than confidence-inspiring.
> Consider,

> 
> The period of the earth's orbit is 365.256363004 days, or known to
> about 1 part in ten to the 11th.
> 
 
> Now there are many measurements and calendrical definitions of the
> period of the earth's orbit.  The measurements most widely used are
> those for the mean tropical year, the time between successive vernal
> equinoxes.  Its current value is 365.2421_9668, but its precision is
> an elusive notion because its value is known to be dropping.

That is true, but the point being that once one does define an
appropriate year it is possible to measure it with an amazing
degree of precision. Even so, smaller times, such as the period
of optical frequencies, can be measured with a much smaller absolute
uncertainty, though similar relative uncertainty.

There are many physical quantities that can be measured with
approximately the same relative uncertainty over a wide range
of magnitudes. For those quantities, floating point is especially
useful, as it allows for computations of quantities derived
from those, giving reasonable relative uncertainties.

For example, if one measures a length and time with 1e-8 
relative uncertainty, then one can compute a velocity with
about 1.4e-8 relative uncertainty. (That is, sqrt(2)*1e-8.)
That is true for nm to Mm scale, maybe fm to Em.

Actually, time can be measured with an absolute uncertainty
over a fairly wide range, but often only a relative uncertainty
is needed. 
 
> Now one of the major differences between the old Julian calendar,
> which has a mean year length during its four-year cycles of 365.25
> days, and the 'new' Gregorian calendar, which has a mean year length
> of 365.2425 days during its 400-year cycles, is just their very
> different leap-year rules, which give rise to these differences.
 
> Mr Hermannsfeldt's number suggests that the Julian calendar is better
> at handling precession than the Gregorian one, but this is not the
> professional consensus.

There was no such intention. It was meant as one example of a 
quantity that could be measured with an amazingly small relative
uncertainty.

Now, TeX does all its typesetting calculations in 32 bit with
16 bits after the binary point. (That is, the unit is 1/65536
of a US printers point, which is 1/72.27 of on inch.) 
That allows for resolution smaller than the wavelength of visible
light, up to about 37 feet or 11.5m. (If you need something bigger,
you can just scale it during printing.) Typesetting tends to have
an absolute error based on printing device resolution. Floating
point at 32 bits would not be so useful. One could go to 64 bit
float (in any base), but would still have to watch rounding.

More important, no rounding problems occur. Fixed point division
always truncates (at least for positive quantities) and a remainder
is supplied (when needed). 

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 result. If you want identical results on all systems,
you have to be very careful with rounding modes. (Even if you
know its DFP, you might not be able to set the rounding mode.)

Note also that one is not so likely to use typesetting at the fm
(femtometer) or EM (exameter) scale. (The atomic nucleus is about
one femtometer, also called the Fermi, in diameter.)

Others can comment on financial calculations better than I can.
 
> E. B. White said long ago that people who like the word 'personalize'
> should of course be free to use it but not perhaps to teach others to
> do so.  My view of Mr Hermannsfeldt's views on floating-point
> arithmetic is of a piece.

-- glen

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Robert A. Rosenberg]

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 
you need to do multiplication (such as computing interest). That 
involves shifting and rounding after the multiplication. IOW: To do 
6%, multiply by 6 and then shift 2 positions to get back to pennies 
(after adding 50 to round up/down).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John P. Baker]

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,

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: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL packed decimal

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% probability of containing a valid packed 
> decimal value (taking into consideration only the two (2) preferred sign
representations).


OK, I'll byte...what are the six? I know of three (C, D, F). Would love a
reference so I can understand this better.
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[zMan]

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% probability of containing a valid packed decimal value (taking into
> consideration only the two (2) preferred sign representations).


OK, I'll byte...what are the six? I know of three (C, D, F). Would love a
reference so I can understand this better.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John Gilmore]

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:

o min,

o max

o SNaN, Signaling Not a Number,

o QNaN, Quiet Not a Number,

each of which has a  distinct bit configuration different from that of
any supported numeric floating-point value.

I have used SNaN to address Bernd's uninitialized-variable problem in
both assembly language and PL/I.  (Current HLASM and PL/I
implementations support the use of these special values in effect by
name; and PL/I provides execution-time BIFs for manipulating them.)

There are [different] accessible chapters in the current PrOp that
describe both BFP and DFP.  Read them!

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Paul Gilmartin]

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-point formats are supported
>by zArchitecture hardware.)
>
I understand (I have very little firm knowledge of these things) that DFP
supports setting an absolute rather than relative rounding point, and
that is required by GAAP.  I don't know that Rexx has such support
(but I haven't sought it -- I'm a numeric rather than accounting kinda
guy.  And I notice you merely cited a common authorship without
asserting that Rexx has the facility).

Much of Rexx's numeric architecture was driven by Cowlishaw's
objective of supporting no data type other than string in Rexx.

Surely there must be GAAP conformance testing suites.  Have DFP,
Rexx, Cobol, PL/I, etc. been vetted against such?  The multiplicity
of choices for rounding and truncation provides a strong incentive
for OO design.  I could imagine different classes with methods for
the various rounding conventions.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John Gilmore]

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 Cowlishaw's DFP.
>
> Moreover, they arev not relevant to it: it uses decimal digits, sand
> Mr Hermamnnsfeldt's post does not petray any acquaintance with it.
>
> The rest of Mr Hermannsfeldt's is also less than confidence-inspiring.
>
> Consider,
>
> 
> The period of the earth's orbit is 365.256363004 days, or known to
> about 1 part in ten to the 11th.
> 
>
> Now there are many measurements and calendrical definitions of the
> period of the earth's orbit.  The measurements most widely used are
> those for the mean tropical year, the time between successive vernal
> equinoxes.  Its current value is 365.2421_9668, but its precision is
> an elusive notion because its value is known to be dropping.
>
> Now one of the major differences between the old Julian calendar,
> which has a mean year length during its four-year cycles of 365.25
> days, and the 'new' Gregorian calendar, which has a mean year length
> of 365.2425 days during its 400-year cycles, is just their very
> different leap-year rules, which give rise to these differences.
>
> Mr Hermannsfeldt's number suggests that the Julian calendar is better
> at handling precession than the Gregorian one, but this is not the
> professional consensus.
>
> E. B. White said long ago that people who like the word 'personalize'
> should of course be free to use it but not perhaps to teach others to
> do so.  My view of Mr Hermannsfeldt's views on floating-point
> arithmetic is of a piece.
>
> John Gilmore, Ashland, MA 01721 - USA
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John Gilmore]

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 relevant to it: it uses decimal digits, sand
Mr Hermamnnsfeldt's post does not petray any acquaintance with it.

The rest of Mr Hermannsfeldt's is also less than confidence-inspiring.

Consider,


The period of the earth's orbit is 365.256363004 days, or known to
about 1 part in ten to the 11th.


Now there are many measurements and calendrical definitions of the
period of the earth's orbit.  The measurements most widely used are
those for the mean tropical year, the time between successive vernal
equinoxes.  Its current value is 365.2421_9668, but its precision is
an elusive notion because its value is known to be dropping.

Now one of the major differences between the old Julian calendar,
which has a mean year length during its four-year cycles of 365.25
days, and the 'new' Gregorian calendar, which has a mean year length
of 365.2425 days during its 400-year cycles, is just their very
different leap-year rules, which give rise to these differences.

Mr Hermannsfeldt's number suggests that the Julian calendar is better
at handling precession than the Gregorian one, but this is not the
professional consensus.

E. B. White said long ago that people who like the word 'personalize'
should of course be free to use it but not perhaps to teach others to
do so.  My view of Mr Hermannsfeldt's views on floating-point
arithmetic is of a piece.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Bernd Oppolzer]

John,

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 of them - both 
species,

and I myself am doing - and teaching - both.

The difference must be at the technical side. If you are forced to fix some
errors to get your code into production, you will do it - so the errors 
that show
up during testing stage will be fixed in the one case and will not be 
fixed in the
other. Same story is about compiler warnings - if they prohibit a 
successfull

build, they will be respected by the coders, but if it's only a warning and
the object code is built anyway, the warnings will be ignored by most 
people -

at least that's what I see most of the time. So if you want some messages
during the development process to be respected, you must prohibit the
build process. Otherwise they will be ignored ...

Kind regards

Bernd



Am 14.07.2012 23:46, schrieb John P. Baker:

Bernd,

I can't agree that mainframe applications are more stable because of packed
decimal arithmetic.

Rather, I would argue that mainframe developers generally have a
philosophically different approach to software development than
distributed/workstation developers.  In particular, I would argue that they
generally take more time, both in the development process and in the code
review process, and that this additional time is what makes the difference.

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% probability of containing a valid packed decimal value (taking 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
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, 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 a valid decimal
representation if all bit patterns have the same probability is not very
high (0.1 percent).

With all binary data types, all bit patterns are valid, and you have no
chance to detect the use of an un-initialized variable (the german
Telefunken hardware had tag bits in storage which allowed for the detection
of such errors even in the binary case - the storage was initially tagged
with a "strange" data type, and so the hardware produced a so-called
"Typenkennungs-Alarm").

I believe that most of the rumour that mainframe applications are more
"stable" than applications on other platforms comes from this property of
the decimal data type, and from the fact, that most applications are written
in COBOL and use this data type, so that such errors are detected during
testing stage.

The more decimal data you have in your applications, the more stable are
your applications. This could also be one of the reasons for the programming
language C being not so stable (among others, like pointer arithmetic, no
control of subscripts etc): the absence of decimal arithmetic in C -
normally.

I'm not sure, if I told you already: in our shop, we run the PL/1
applications in production with SUBSCRIPTRANGE enabled since some years ago,
and we are very happy with this. The performance is acceptable.

Kind regards

Bernd

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John P. Baker]

Bernd,

I can't agree that mainframe applications are more stable because of packed
decimal arithmetic.

Rather, I would argue that mainframe developers generally have a
philosophically different approach to software development than
distributed/workstation developers.  In particular, I would argue that they
generally take more time, both in the development process and in the code
review process, and that this additional time is what makes the difference.

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% probability of containing a valid packed decimal value (taking 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
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, 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 a valid decimal
representation if all bit patterns have the same probability is not very
high (0.1 percent).

With all binary data types, all bit patterns are valid, and you have no
chance to detect the use of an un-initialized variable (the german
Telefunken hardware had tag bits in storage which allowed for the detection
of such errors even in the binary case - the storage was initially tagged
with a "strange" data type, and so the hardware produced a so-called
"Typenkennungs-Alarm").

I believe that most of the rumour that mainframe applications are more
"stable" than applications on other platforms comes from this property of
the decimal data type, and from the fact, that most applications are written
in COBOL and use this data type, so that such errors are detected during
testing stage.

The more decimal data you have in your applications, the more stable are
your applications. This could also be one of the reasons for the programming
language C being not so stable (among others, like pointer arithmetic, no
control of subscripts etc): the absence of decimal arithmetic in C -
normally.

I'm not sure, if I told you already: in our shop, we run the PL/1
applications in production with SUBSCRIPTRANGE enabled since some years ago,
and we are very happy with this. The performance is acceptable.

Kind regards

Bernd

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Bernd Oppolzer]

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 a valid decimal representation if all bit patterns
have the same probability is not very high (0.1 percent).

With all binary data types, all bit patterns are valid, and you have
no chance to detect the use of an un-initialized variable (the german
Telefunken hardware had tag bits in storage which allowed for the
detection of such errors even in the binary case - the storage was
initially tagged with a "strange" data type, and so the hardware produced
a so-called "Typenkennungs-Alarm").

I believe that most of the rumour that mainframe applications are
more "stable" than applications on other platforms comes from this
property of the decimal data type, and from the fact, that most
applications are written in COBOL and use this data type, so that
such errors are detected during testing stage.

The more decimal data you have in your applications, the more stable
are your applications. This could also be one of the reasons for
the programming language C being not so stable (among others,
like pointer arithmetic, no control of subscripts etc): the absence
of decimal arithmetic in C - normally.

I'm not sure, if I told you already: in our shop, we run the PL/1 
applications

in production with SUBSCRIPTRANGE enabled since some years ago,
and we are very happy with this. The performance is acceptable.

Kind regards

Bernd



Am 14.07.2012 20:39, schrieb John Gilmore:

Although there has been ample tIme to do so, IBM COBOL does not yet
support DFP.  It should.   When IBM COBOL does support DFP, it will be
possible to eliminate packed-decimal (except as a transitional data
type in certain conversion operations) from COBOL routines; and doing
so will confer large performance advantages.

John Gilmore, Ashland, MA 01721 - USA



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[John Gilmore]

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, jam jars, whatever, use binary.  In
particular, never use packed-decimal indices or subscripts.

The question how to use floating-point in COBOL is a vexed one.  It
is/would be possible to use both IBM hexadecimal floating point (HFP)
and ANSI binary floating point (BFP) in a COBOL routine, but it is
fair to admit that one needs to know both too much and kinds of things
that COBOL programmers seldom know to do so successfully.

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-point formats are supported
by zArchitecture hardware.)

Although there has been ample tIme to do so, IBM COBOL does not yet
support DFP.  It should.   When IBM COBOL does support DFP, it will be
possible to eliminate packed-decimal (except as a transitional data
type in certain conversion operations) from COBOL routines; and doing
so will confer large performance advantages.

John Gilmore, Ashland, MA 01721 - USA

> 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 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 then converting
>> the total to the printable form might be an example of where staying with
>> packed decimal is the more efficient.
>>
>> "Well, hardly ever!"
>>
>> -
>>
>> To all following this topic
>>
>> Even before John Gilmore's assertion, I had in mind to tell a story
>> concerning the relative efficiency of packed decimal.
>>
>> Forty years ago in the north-west of England, an IBM salesman was faced
>> with losing one of his customers. Competition had muscled in and proposed
>> a machine potentially more suited to the demands made on the customer's
>> business - and their pocket. The salesman's response was to propose
>> replacing the 360/30 with a 360/25 which I believe had only recently - at
>> the time - been added to the 360 range, extending it "downwards" -
>> ignoring - *obviously* - the 360/20!
>>
>> The customer - or perhaps the competition - proposed running a benchmark
>> and the customer supplied both contenders with the source of an assembler
>> program key to their operation.
>>
>> It's important to know that the 360/30 the customer already had was
>> literally "basic" in that disks were not a feature of the configuration
>> with all storage on tape. Thus the operating system was Basic Programming
>> System (BPS) Tape. There was a BPS-Tape assembler compiler of course but
>> there was no COBOL compiler. It may have been a bit of a disappointment -
>> maybe even a surprise - for the competition that they were not provided
>> with COBOL source.
>>
>> The customer was an organisation which set and evaluated examination
>> papers for secondary schools. The "benchmark" program had the
>> responsibility of sorting the sheep from the goats. It did so on the basis
>> of assuming the results formed a "bell curve" and then fenced the anxious
>> teenagers based on the standard deviation.[1]
>>
>> Obviously - or I wouldn't be telling this story! - all the arithmetic was
>> performed using packed decimal and the "heavy lifting" was in determining
>> the variance: the mean, the differences from the mean and the squares of
>> the latter.[2]
>>
>> I was one of a team of three assigned to win this benchmark to replace a
>> bigger machine with a smaller machine! The team leader initiated the
>> effort by simply writing the tape records as blocks. This reduced the
>> execution time by half from about 30 minutes to 15 minutes - and would
>> probably have been sufficient to win the contest. However I had my eye on
>> those unsavoury packed decimal instructions!
>>
>> Essentially I rewrote the whole program using binary arithmetic
>> instructions to replace the packed decimal instructions. I happened to
>> mention what I was doing - more strictly, had done - to one of my
>> colleagues - of an academic bent comparable to our own John Gilmore! He
>> responded by reminding me - or in case I didn't know - that use of base
>> registers was faster than using index registers. Of course, either I had
>> forgotten or just didn't know before.[3] Back to the 129 in order to rekey
>> a significant percentage of the source program cards with commas in front
>> of the register numbers where a storage reference was required - or
>> implied.
>>
>> Mi

Re: COBOL packed decimal

[Scott Ford]

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 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 then converting the total to 
> the printable form might be an example of where staying with packed decimal 
> is the more efficient.
> 
> "Well, hardly ever!"
> 
> -
> 
> To all following this topic
> 
> Even before John Gilmore's assertion, I had in mind to tell a story 
> concerning the relative efficiency of packed decimal.
> 
> Forty years ago in the north-west of England, an IBM salesman was faced with 
> losing one of his customers. Competition had muscled in and proposed a 
> machine potentially more suited to the demands made on the customer's 
> business - and their pocket. The salesman's response was to propose replacing 
> the 360/30 with a 360/25 which I believe had only recently - at the time - 
> been added to the 360 range, extending it "downwards" - ignoring - 
> *obviously* - the 360/20!
> 
> The customer - or perhaps the competition - proposed running a benchmark and 
> the customer supplied both contenders with the source of an assembler program 
> key to their operation.
> 
> It's important to know that the 360/30 the customer already had was literally 
> "basic" in that disks were not a feature of the configuration with all 
> storage on tape. Thus the operating system was Basic Programming System (BPS) 
> Tape. There was a BPS-Tape assembler compiler of course but there was no 
> COBOL compiler. It may have been a bit of a disappointment - maybe even a 
> surprise - for the competition that they were not provided with COBOL source.
> 
> The customer was an organisation which set and evaluated examination papers 
> for secondary schools. The "benchmark" program had the responsibility of 
> sorting the sheep from the goats. It did so on the basis of assuming the 
> results formed a "bell curve" and then fenced the anxious teenagers based on 
> the standard deviation.[1]
> 
> Obviously - or I wouldn't be telling this story! - all the arithmetic was 
> performed using packed decimal and the "heavy lifting" was in determining the 
> variance: the mean, the differences from the mean and the squares of the 
> latter.[2]
> 
> I was one of a team of three assigned to win this benchmark to replace a 
> bigger machine with a smaller machine! The team leader initiated the effort 
> by simply writing the tape records as blocks. This reduced the execution time 
> by half from about 30 minutes to 15 minutes - and would probably have been 
> sufficient to win the contest. However I had my eye on those unsavoury packed 
> decimal instructions!
> 
> Essentially I rewrote the whole program using binary arithmetic instructions 
> to replace the packed decimal instructions. I happened to mention what I was 
> doing - more strictly, had done - to one of my colleagues - of an academic 
> bent comparable to our own John Gilmore! He responded by reminding me - or in 
> case I didn't know - that use of base registers was faster than using index 
> registers. Of course, either I had forgotten or just didn't know before.[3] 
> Back to the 129 in order to rekey a significant percentage of the source 
> program cards with commas in front of the register numbers where a storage 
> reference was required - or implied.
> 
> Mistake! The BPS-Tape assembler can't handle "(,R)" like its more 
> sophisticated cousins can. The BPS-Tape assembler requires "(0,R)". Back to 
> the 129 again.
> 
> Did the fundamental change to the type of instruction performing the 
> arithmetic do any good? I seem to remember that a number of seconds were 
> "knocked" off the total time, trivial in comparison with the benefits of 
> improving the tape I/O.
> 
> Again by means of a massive rewrite, I introduced another improvement. I 
> can't recall why it was necessary to read the tape with the results records 
> multiple times, but this was the way the original program worked and so, 
> until this point, I had kept that basic logic. Taking into account the 
> proposed storage, I reduced the number of tape passes from - IMMSMC - 10 to 
> 2. Again an improvement to be measured in seconds since I had managed to 
> extinguish the "wait light" and the tape now limped along where previously it 
> had sprinted.[4]
> 
> -
> 
> [1] There's a lot of discussion these days in the British news media of a 
> creep to larger percentages of the higher grades in exam results, 
> particularly the exams leading to university entrance. This would not be 
> possible if the exam boards continued to use the methodology embedded in the 
> analysis of results used by this exam board 40 years ago.
> 
> [2]

Re: COBOL packed decimal

[Scott Ford]

I understand the difference , just trying to understand what John is saying

Scott ford
www.identityforge.com

On Jul 14, 2012, at 12:22 PM, Steve Comstock  wrote:

> On 7/14/2012 10:16 AM, Scott Ford wrote:
>> John,
>> 
>> So your saying in COBOL are you talking about Comp-3 binary ?
> 
> No such thing. A field is either comp-3 (or, nowadays, packed-decimal)
> or comp (nowadays, binary) - or floating point which few COBOL
> programs use.
> 
> I think he's saying keep amounts in pennies as binary fields.
> Convert to dollars + decimal point + cents when you display
> these fields.
> 
> 
>> 
>> Scott ford
>> www.identityforge.com
>> 
>> On Jul 14, 2012, at 8:08 AM, John Gilmore  wrote:
>> 
>>> Doing integer--as opposed to real fixed-point--arithmetic with
>>> packed-decimal values is the real culprit here.
>>> 
>>> Integer arithmetic should never be done with anything but binary
>>> integers.  Operations on them are register operations, which are much
>>> faster than storage-to-storage ones; and zero is always positive.
>>> Moreover, it is now possible to make them behave in COBOL exactly as
>>> they do in assembly language.
>>> 
>>> John Gilmore, Ashland, MA 01721 - USA
>>> 
>>> On 7/14/12, Gibney, Dave  wrote:
>>>> Back in 1981, one of the first bugs I had to 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.
>>>> 
>>>>> -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!  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: COBOL packed decimal
>>>>>> 
>>>>>> From an old discussion on the same subject from back in '05 over at
>>>>>> http://www.tek-tips.com :
>>>>>> 
>>>>>> Here's an explanation of what is happening.  When we were converting
>>>>>> from VS COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR
>>>>> VS
>>>>>> COBOL AND COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says
>>>>>> about your question
>>>>>> 
>>>>>> "One change from VS COBOL to COBOL/370 that may seem quite baffling
>>>>>> occurs when a constant or another COMP-3 data field is added or
>>>>>> subtracted to or from a signed COMP-3 data field.  The VS COBOL
>>>>>> compiler produced only an Add Packed (AP) or Subtract Packed (SP)
>>>>>> instruction.  COBOL/370 still produces the same instruction but then
>>>>>> issues a Zero and Add Packed (ZAP) of the resulting field into
>>>>> itself.  The ZAP is executed for a very subtle reason.
>>>>>> When two negative numbers are added together and an overflow occurs,
>>>>>> the overflow flag in the condition code is turned on while the
>>>>>> resulting sign is set as if overflow did not occur.  This means that
>>>>> if
>>>>>> two numbers each defined as PIC S9(03) COMP-3 were added together, and
>>>>>> they had values of -1 and -999 before the addition, the resulting
>>>>> field
>>>>>> would be zero (the digit that overflowed was truncated) with its sign
>>>>>> negative.  The ZAP will preserve the sign of all other computations
>>>>> but
>>>>>> will change a zero with a negative sign to a zero with a positive
>>>>> sign."
>>>>>> 
>>>>>> "Ensuring a positive sign in a zero result was not necessary in the VS
>>>>

Re: COBOL packed decimal

[Chris Mason]

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 then converting the total to the 
printable form might be an example of where staying with packed decimal is the 
more efficient.

"Well, hardly ever!"

-

To all following this topic

Even before John Gilmore's assertion, I had in mind to tell a story concerning 
the relative efficiency of packed decimal.

Forty years ago in the north-west of England, an IBM salesman was faced with 
losing one of his customers. Competition had muscled in and proposed a machine 
potentially more suited to the demands made on the customer's business - and 
their pocket. The salesman's response was to propose replacing the 360/30 with 
a 360/25 which I believe had only recently - at the time - been added to the 
360 range, extending it "downwards" - ignoring - *obviously* - the 360/20!

The customer - or perhaps the competition - proposed running a benchmark and 
the customer supplied both contenders with the source of an assembler program 
key to their operation.

It's important to know that the 360/30 the customer already had was literally 
"basic" in that disks were not a feature of the configuration with all storage 
on tape. Thus the operating system was Basic Programming System (BPS) Tape. 
There was a BPS-Tape assembler compiler of course but there was no COBOL 
compiler. It may have been a bit of a disappointment - maybe even a surprise - 
for the competition that they were not provided with COBOL source.

The customer was an organisation which set and evaluated examination papers for 
secondary schools. The "benchmark" program had the responsibility of sorting 
the sheep from the goats. It did so on the basis of assuming the results formed 
a "bell curve" and then fenced the anxious teenagers based on the standard 
deviation.[1]

Obviously - or I wouldn't be telling this story! - all the arithmetic was 
performed using packed decimal and the "heavy lifting" was in determining the 
variance: the mean, the differences from the mean and the squares of the 
latter.[2]

I was one of a team of three assigned to win this benchmark to replace a bigger 
machine with a smaller machine! The team leader initiated the effort by simply 
writing the tape records as blocks. This reduced the execution time by half 
from about 30 minutes to 15 minutes - and would probably have been sufficient 
to win the contest. However I had my eye on those unsavoury packed decimal 
instructions!

Essentially I rewrote the whole program using binary arithmetic instructions to 
replace the packed decimal instructions. I happened to mention what I was doing 
- more strictly, had done - to one of my colleagues - of an academic bent 
comparable to our own John Gilmore! He responded by reminding me - or in case I 
didn't know - that use of base registers was faster than using index registers. 
Of course, either I had forgotten or just didn't know before.[3] Back to the 
129 in order to rekey a significant percentage of the source program cards with 
commas in front of the register numbers where a storage reference was required 
- or implied.

Mistake! The BPS-Tape assembler can't handle "(,R)" like its more sophisticated 
cousins can. The BPS-Tape assembler requires "(0,R)". Back to the 129 again.

Did the fundamental change to the type of instruction performing the arithmetic 
do any good? I seem to remember that a number of seconds were "knocked" off the 
total time, trivial in comparison with the benefits of improving the tape I/O.

Again by means of a massive rewrite, I introduced another improvement. I can't 
recall why it was necessary to read the tape with the results records multiple 
times, but this was the way the original program worked and so, until this 
point, I had kept that basic logic. Taking into account the proposed storage, I 
reduced the number of tape passes from - IMMSMC - 10 to 2. Again an improvement 
to be measured in seconds since I had managed to extinguish the "wait light" 
and the tape now limped along where previously it had sprinted.[4]

-

[1] There's a lot of discussion these days in the British news media of a creep 
to larger percentages of the higher grades in exam results, particularly the 
exams leading to university entrance. This would not be possible if the exam 
boards continued to use the methodology embedded in the analysis of results 
used by this exam board 40 years ago.

[2] The calculation of the standard deviation was rather clever. In a way this 
also promised to be "heavy lifting" since the determination of the square root 
of the variance depended on iteration. However it must have been considered 
that two iterations were always sufficient.[2.1] The refining logic was framed 
by an initial BALR R,0 and a fi

Re: COBOL packed decimal

[Steve Comstock]

On 7/14/2012 10:16 AM, Scott Ford wrote:

John,

So your saying in COBOL are you talking about Comp-3 binary ?


No such thing. A field is either comp-3 (or, nowadays, packed-decimal)
or comp (nowadays, binary) - or floating point which few COBOL
programs use.

I think he's saying keep amounts in pennies as binary fields.
Convert to dollars + decimal point + cents when you display
these fields.




Scott ford
www.identityforge.com

On Jul 14, 2012, at 8:08 AM, John Gilmore  wrote:


Doing integer--as opposed to real fixed-point--arithmetic with
packed-decimal values is the real culprit here.

Integer arithmetic should never be done with anything but binary
integers.  Operations on them are register operations, which are much
faster than storage-to-storage ones; and zero is always positive.
Moreover, it is now possible to make them behave in COBOL exactly as
they do in assembly language.

John Gilmore, Ashland, MA 01721 - USA

On 7/14/12, Gibney, Dave  wrote:

Back in 1981, one of the first bugs I had to 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.


-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!  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: COBOL packed decimal

 From an old discussion on the same subject from back in '05 over at
http://www.tek-tips.com :

Here's an explanation of what is happening.  When we were converting
from VS COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR

VS

COBOL AND COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says
about your question

"One change from VS COBOL to COBOL/370 that may seem quite baffling
occurs when a constant or another COMP-3 data field is added or
subtracted to or from a signed COMP-3 data field.  The VS COBOL
compiler produced only an Add Packed (AP) or Subtract Packed (SP)
instruction.  COBOL/370 still produces the same instruction but then
issues a Zero and Add Packed (ZAP) of the resulting field into

itself.  The ZAP is executed for a very subtle reason.

When two negative numbers are added together and an overflow occurs,
the overflow flag in the condition code is turned on while the
resulting sign is set as if overflow did not occur.  This means that

if

two numbers each defined as PIC S9(03) COMP-3 were added together, and
they had values of -1 and -999 before the addition, the resulting

field

would be zero (the digit that overflowed was truncated) with its sign
negative.  The ZAP will preserve the sign of all other computations

but

will change a zero with a negative sign to a zero with a positive

sign."


"Ensuring a positive sign in a zero result was not necessary in the VS
COBOL compiler.  This is because the VS COBOL compiler used a Compare
Packed (CP) instruction to compare numeric fields.  It is interesting
that COBOL/370 now often produces a Compare Logical (CLC) instruction
to compare numeric fields.  While this is a faster instruction than

CP,

it requires the same sign value for an equal condition to occur.  For
example, a CP instruction will find fields with hexadecimal 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-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  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),44(1,10)
WS-NUM-PACKED PGMLIT AT +40
 000370  F844 8008 8008  ZAP   8(5,8),8(5,8)  WS-NUM-

PACKED

WS-NUM-PACKED


What is the purpose of the ZAP?

Thanks,
Frank




-

- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN






--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by 

Re: COBOL packed decimal

[Scott Ford]

John,

So your saying in COBOL are you talking about Comp-3 binary ?

Scott ford
www.identityforge.com

On Jul 14, 2012, at 8:08 AM, John Gilmore  wrote:

> Doing integer--as opposed to real fixed-point--arithmetic with
> packed-decimal values is the real culprit here.
> 
> Integer arithmetic should never be done with anything but binary
> integers.  Operations on them are register operations, which are much
> faster than storage-to-storage ones; and zero is always positive.
> Moreover, it is now possible to make them behave in COBOL exactly as
> they do in assembly language.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> On 7/14/12, Gibney, Dave  wrote:
>> Back in 1981, one of the first bugs I had to 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.
>> 
>>> -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!  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: COBOL packed decimal
>>>> 
>>>> From an old discussion on the same subject from back in '05 over at
>>>> http://www.tek-tips.com :
>>>> 
>>>> Here's an explanation of what is happening.  When we were converting
>>>> from VS COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR
>>> VS
>>>> COBOL AND COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says
>>>> about your question
>>>> 
>>>> "One change from VS COBOL to COBOL/370 that may seem quite baffling
>>>> occurs when a constant or another COMP-3 data field is added or
>>>> subtracted to or from a signed COMP-3 data field.  The VS COBOL
>>>> compiler produced only an Add Packed (AP) or Subtract Packed (SP)
>>>> instruction.  COBOL/370 still produces the same instruction but then
>>>> issues a Zero and Add Packed (ZAP) of the resulting field into
>>> itself.  The ZAP is executed for a very subtle reason.
>>>> When two negative numbers are added together and an overflow occurs,
>>>> the overflow flag in the condition code is turned on while the
>>>> resulting sign is set as if overflow did not occur.  This means that
>>> if
>>>> two numbers each defined as PIC S9(03) COMP-3 were added together, and
>>>> they had values of -1 and -999 before the addition, the resulting
>>> field
>>>> would be zero (the digit that overflowed was truncated) with its sign
>>>> negative.  The ZAP will preserve the sign of all other computations
>>> but
>>>> will change a zero with a negative sign to a zero with a positive
>>> sign."
>>>> 
>>>> "Ensuring a positive sign in a zero result was not necessary in the VS
>>>> COBOL compiler.  This is because the VS COBOL compiler used a Compare
>>>> Packed (CP) instruction to compare numeric fields.  It is interesting
>>>> that COBOL/370 now often produces a Compare Logical (CLC) instruction
>>>> to compare numeric fields.  While this is a faster instruction than
>>> CP,
>>>> it requires the same sign value for an equal condition to occur.  For
>>>> example, a CP instruction will find fields with hexadecimal 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-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 packe

Re: COBOL packed decimal

[John Gilmore]

Doing integer--as opposed to real fixed-point--arithmetic with
packed-decimal values is the real culprit here.

Integer arithmetic should never be done with anything but binary
integers.  Operations on them are register operations, which are much
faster than storage-to-storage ones; and zero is always positive.
Moreover, it is now possible to make them behave in COBOL exactly as
they do in assembly language.

John Gilmore, Ashland, MA 01721 - USA

On 7/14/12, Gibney, Dave  wrote:
> Back in 1981, one of the first bugs I had to 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.
>
>> -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!  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: COBOL packed decimal
>> >
>> >From an old discussion on the same subject from back in '05 over at
>> >http://www.tek-tips.com :
>> >
>> >Here's an explanation of what is happening.  When we were converting
>> >from VS COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR
>> VS
>> >COBOL AND COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says
>> >about your question
>> >
>> >"One change from VS COBOL to COBOL/370 that may seem quite baffling
>> >occurs when a constant or another COMP-3 data field is added or
>> >subtracted to or from a signed COMP-3 data field.  The VS COBOL
>> >compiler produced only an Add Packed (AP) or Subtract Packed (SP)
>> >instruction.  COBOL/370 still produces the same instruction but then
>> >issues a Zero and Add Packed (ZAP) of the resulting field into
>> itself.  The ZAP is executed for a very subtle reason.
>> >When two negative numbers are added together and an overflow occurs,
>> >the overflow flag in the condition code is turned on while the
>> >resulting sign is set as if overflow did not occur.  This means that
>> if
>> >two numbers each defined as PIC S9(03) COMP-3 were added together, and
>> >they had values of -1 and -999 before the addition, the resulting
>> field
>> >would be zero (the digit that overflowed was truncated) with its sign
>> >negative.  The ZAP will preserve the sign of all other computations
>> but
>> >will change a zero with a negative sign to a zero with a positive
>> sign."
>> >
>> >"Ensuring a positive sign in a zero result was not necessary in the VS
>> >COBOL compiler.  This is because the VS COBOL compiler used a Compare
>> >Packed (CP) instruction to compare numeric fields.  It is interesting
>> >that COBOL/370 now often produces a Compare Logical (CLC) instruction
>> >to compare numeric fields.  While this is a faster instruction than
>> CP,
>> >it requires the same sign value for an equal condition to occur.  For
>> >example, a CP instruction will find fields with hexadecimal 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-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              pic S9(9) packed-decimal.
>> >>
>> >>     add 2 to ws-num-packed
>> >>
>> >>
>> >> Generated assembler:
>> >>
>> >>
>> >> 14
>> >> ADD
>> >>    00036A                 GN=16    EQU
&g

Re: COBOL packed decimal

[Gibney, Dave]

Back in 1981, one of the first bugs I had to 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. 

> -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!  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: COBOL packed decimal
> >
> >From an old discussion on the same subject from back in '05 over at
> >http://www.tek-tips.com :
> >
> >Here's an explanation of what is happening.  When we were converting
> >from VS COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR
> VS
> >COBOL AND COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says
> >about your question
> >
> >"One change from VS COBOL to COBOL/370 that may seem quite baffling
> >occurs when a constant or another COMP-3 data field is added or
> >subtracted to or from a signed COMP-3 data field.  The VS COBOL
> >compiler produced only an Add Packed (AP) or Subtract Packed (SP)
> >instruction.  COBOL/370 still produces the same instruction but then
> >issues a Zero and Add Packed (ZAP) of the resulting field into
> itself.  The ZAP is executed for a very subtle reason.
> >When two negative numbers are added together and an overflow occurs,
> >the overflow flag in the condition code is turned on while the
> >resulting sign is set as if overflow did not occur.  This means that
> if
> >two numbers each defined as PIC S9(03) COMP-3 were added together, and
> >they had values of -1 and -999 before the addition, the resulting
> field
> >would be zero (the digit that overflowed was truncated) with its sign
> >negative.  The ZAP will preserve the sign of all other computations
> but
> >will change a zero with a negative sign to a zero with a positive
> sign."
> >
> >"Ensuring a positive sign in a zero result was not necessary in the VS
> >COBOL compiler.  This is because the VS COBOL compiler used a Compare
> >Packed (CP) instruction to compare numeric fields.  It is interesting
> >that COBOL/370 now often produces a Compare Logical (CLC) instruction
> >to compare numeric fields.  While this is a faster instruction than
> CP,
> >it requires the same sign value for an equal condition to occur.  For
> >example, a CP instruction will find fields with hexadecimal 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-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              pic S9(9) packed-decimal.
> >>
> >>     add 2 to ws-num-packed
> >>
> >>
> >> Generated assembler:
> >>
> >>
> >> 14
> >> ADD
> >>    00036A                 GN=16    EQU
> >> *
> >>    00036A  FA40 8008 A02C          AP    8(5,8),44(1,10)
> >>WS-NUM-PACKED                     PGMLIT AT +40
> >>    000370  F844 8008 8008          ZAP   8(5,8),8(5,8)  WS-NUM-
> PACKED
> >>WS-NUM-PACKED
> >>
> >>
> >> What is the purpose of the ZAP?
> >>
> >> Thanks,
> >> Frank
> >>
> >>
> >> 
> -
> >> - For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO
> >> IBM-MAIN
> >>
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions, send
> >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions, send
> >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Frank Swarbrick]

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: COBOL packed decimal
> 
>From an old discussion on the same subject from back in '05 over at
>http://www.tek-tips.com :
>
>Here's an explanation of what is happening.  When we were converting from VS
>COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR VS COBOL AND
>COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says about your
>question
>
>"One change from VS COBOL to COBOL/370 that may seem quite baffling occurs
>when a constant or another COMP-3 data field is added or subtracted to or
>from a signed COMP-3 data field.  The VS COBOL compiler produced only an Add
>Packed (AP) or Subtract Packed (SP) instruction.  COBOL/370 still produces
>the same instruction but then issues a Zero and Add Packed (ZAP) of the
>resulting field into itself.  The ZAP is executed for a very subtle reason.
>When two negative numbers are added together and an overflow occurs, the
>overflow flag in the condition code is turned on while the resulting sign is
>set as if overflow did not occur.  This means that if two numbers each
>defined as PIC S9(03) COMP-3 were added together, and they had values of -1
>and -999 before the addition, the resulting field would be zero (the digit
>that overflowed was truncated) with its sign negative.  The ZAP will
>preserve the sign of all other computations but will change a zero with a
>negative sign to a zero with a positive sign."
>
>"Ensuring a positive sign in a zero result was not necessary in the VS COBOL
>compiler.  This is because the VS COBOL compiler used a Compare Packed (CP)
>instruction to compare numeric fields.  It is interesting that COBOL/370 now
>often produces a Compare Logical (CLC) instruction to compare numeric
>fields.  While this is a faster instruction than CP, it requires the same
>sign value for an equal condition to occur.  For example, a CP instruction
>will find fields with hexadecimal 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-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              pic S9(9) packed-decimal.
>>
>>     add 2 to ws-num-packed
>>
>>
>> Generated assembler:
>>
>>
>> 14
>> ADD
>>    00036A                 GN=16    EQU
>> *
>>    00036A  FA40 8008 A02C          AP    8(5,8),44(1,10)
>> WS-NUM-PACKED                     PGMLIT AT +40
>>    000370  F844 8008 8008          ZAP   8(5,8),8(5,8)
>> WS-NUM-PACKED                     WS-NUM-PACKED
>>
>>
>> What is the purpose of the ZAP?
>>
>> Thanks,
>> Frank
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Sam Siegel]

Thanks ... extremely informative.

On Fri, Jul 13, 2012 at 2:24 PM, Dan Skomsky @ Home
 wrote:
> From an old discussion on the same subject from back in '05 over at
> http://www.tek-tips.com :
>
> Here's an explanation of what is happening.  When we were converting from VS
> COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR VS COBOL AND
> COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says about your
> question
>
> "One change from VS COBOL to COBOL/370 that may seem quite baffling occurs
> when a constant or another COMP-3 data field is added or subtracted to or
> from a signed COMP-3 data field.  The VS COBOL compiler produced only an Add
> Packed (AP) or Subtract Packed (SP) instruction.  COBOL/370 still produces
> the same instruction but then issues a Zero and Add Packed (ZAP) of the
> resulting field into itself.  The ZAP is executed for a very subtle reason.
> When two negative numbers are added together and an overflow occurs, the
> overflow flag in the condition code is turned on while the resulting sign is
> set as if overflow did not occur.  This means that if two numbers each
> defined as PIC S9(03) COMP-3 were added together, and they had values of -1
> and -999 before the addition, the resulting field would be zero (the digit
> that overflowed was truncated) with its sign negative.  The ZAP will
> preserve the sign of all other computations but will change a zero with a
> negative sign to a zero with a positive sign."
>
> "Ensuring a positive sign in a zero result was not necessary in the VS COBOL
> compiler.  This is because the VS COBOL compiler used a Compare Packed (CP)
> instruction to compare numeric fields.  It is interesting that COBOL/370 now
> often produces a Compare Logical (CLC) instruction to compare numeric
> fields.  While this is a faster instruction than CP, it requires the same
> sign value for an equal condition to occur.  For example, a CP instruction
> will find fields with hexadecimal 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-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  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),44(1,10)
>> WS-NUM-PACKED PGMLIT AT +40
>>000370  F844 8008 8008  ZAP   8(5,8),8(5,8)
>> WS-NUM-PACKED WS-NUM-PACKED
>>
>>
>> What is the purpose of the ZAP?
>>
>> Thanks,
>> Frank
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Dan Skomsky @ Home]

>From an old discussion on the same subject from back in '05 over at
http://www.tek-tips.com :

Here's an explanation of what is happening.  When we were converting from VS
COBOL to COBOL II/COBOL 370, I found the book "COBOL/370 FOR VS COBOL AND
COBOL II PROGRAMMERS by Harvey Bookman.  Here's what he says about your
question

"One change from VS COBOL to COBOL/370 that may seem quite baffling occurs
when a constant or another COMP-3 data field is added or subtracted to or
from a signed COMP-3 data field.  The VS COBOL compiler produced only an Add
Packed (AP) or Subtract Packed (SP) instruction.  COBOL/370 still produces
the same instruction but then issues a Zero and Add Packed (ZAP) of the
resulting field into itself.  The ZAP is executed for a very subtle reason.
When two negative numbers are added together and an overflow occurs, the
overflow flag in the condition code is turned on while the resulting sign is
set as if overflow did not occur.  This means that if two numbers each
defined as PIC S9(03) COMP-3 were added together, and they had values of -1
and -999 before the addition, the resulting field would be zero (the digit
that overflowed was truncated) with its sign negative.  The ZAP will
preserve the sign of all other computations but will change a zero with a
negative sign to a zero with a positive sign."

"Ensuring a positive sign in a zero result was not necessary in the VS COBOL
compiler.  This is because the VS COBOL compiler used a Compare Packed (CP)
instruction to compare numeric fields.  It is interesting that COBOL/370 now
often produces a Compare Logical (CLC) instruction to compare numeric
fields.  While this is a faster instruction than CP, it requires the same
sign value for an equal condition to occur.  For example, a CP instruction
will find fields with hexadecimal 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-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  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),44(1,10)
> WS-NUM-PACKED PGMLIT AT +40
>000370  F844 8008 8008  ZAP   8(5,8),8(5,8)
> WS-NUM-PACKED WS-NUM-PACKED
>
>
> What is the purpose of the ZAP?
>
> Thanks,
> Frank
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Itschak Mugzach]

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 8008 A02C  AP8(5,8),44(1,10)
> WS-NUM-PACKED PGMLIT AT +40
>000370  F844 8008 8008  ZAP   8(5,8),8(5,8)
> WS-NUM-PACKED WS-NUM-PACKED
>
>
> What is the purpose of the ZAP?
>
> Thanks,
> Frank
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL packed decimal

[Sam Siegel]

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),44(1,10) 
> WS-NUM-PACKED PGMLIT AT +40
>000370  F844 8008 8008  ZAP   8(5,8),8(5,8)   
> WS-NUM-PACKED WS-NUM-PACKED
>
>

What level of optimization is in use?

> What is the purpose of the ZAP?
>
> Thanks,
> Frank
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN