Yes, of course, that's how we do it today, using a include file (or COPY BOOK, as it's called at other places), but it would be much nicer, if it could be defined as PIC S9(x) COMP-3 UNSIGNED,
because that's what these fields are, after all.

In PL/1:

     DCL DATE8  DEC FIXED (8,0)  UNSIGNED;   /* should give 4 Bytes */

but that's not possible, too ...

Kind regards

Bernd



Am 30.04.2025 um 02:55 schrieb Mike Schwab:
Unpack an extra byte and ignore the extra digit and sign.

On Tue, Apr 29, 2025 at 6:19 PM Bernd Oppolzer <bernd.oppol...@t-online.de>
wrote:

Topic drift:

a really useful enhancemant for COBOL and other mainframe language IMO
would be:

the possibility to define DECIMAL variables, which are REALLY unsigned,
that is, they don't have a sign nibble.

x'00123456' as an example (8 decimal digits, unsigned).

Because that's what we have all the time in legacy VSAM based systems,
where clever architects of the past put
numeric keys in packed decimal format WITHOUT SIGN in legacy datasets.
Such fields (in key or non-key positions)
are defined as CHAR fields, like PIC X(4) in the case above, but in
reality they are something like PIC S9(8) COMP-3 "UNSIGNED".

But because it is impossible to define it like that (at least in "my"
version of COBOL - on VSE), we have to implement some
logic to convert such fields to, say, PIC 9(8) USAGE DISPLAY, so that
they can be shown on CICS screens or on the printer.

Kind regards

Bernd


Am 29.04.2025 um 16:16 schrieb Schmitt, Michael:
In COBOL "unsigned" really means "not signed", which means that the
number can only have a positive value or zero.
  From a practical point of view:

* An unsinged binary can hold larger numbers, depending on compile
options
* Unsigned is generally better for zoned decimal ("usage display"). 123
as a signed zoned decimal (PIC S999) would be stored as x'F1F2C3', while as
unsigned (PIC 999) it would be F1F2F3. The problem is when you print or
display it: the signed version would print as 12C. I hate that.
On the other hand, singed fields enable more efficient code.


Fun fact: CA Easytrieve also has signed and unsigned numbers, but
there's no obvious way to define it. The way it works is a number with
decimal positions is signed (aka "quantitative"), a number without is
unsinged:
Field 4 P   = 4 byte unsigned packed decimal
Field 4 P 2 = 4 byte signed packed decimal with 2 decimal positions

So how do you do a signed field with 0 decimals? Easy:

Field 4 P 0

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of Andrew Rowley
Sent: Monday, April 28, 2025 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Packed decimal sign nibbles

On 29/04/2025 9:32 am, Seymour J Metz wrote:
The decimal instructions treat F zones as positive.
That's always been my understanding. But I'm intrigued by the statement
that it means unsigned in COBOL. Is there a practical difference? Or is
it just a difference e.g. for formatting output?

--
Andrew Rowley
Black Hill Software

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

Reply via email to