For Programmers: Free Programming Magazines  


Home > Archive > Cobol > November 2004 > Internal sign encoding in DISPLAY and PACKED-DECIMAL usage









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Internal sign encoding in DISPLAY and PACKED-DECIMAL usage
Vincent Danion

2004-11-21, 3:55 am

Hello,

I have a question about internal sign encoding.

"IBM Enterprise COBOL for z/OS - Language Reference - V3R3" says (p.217):

"PACKED-DECIMAL [...] The sign representation uses the same bit
configuration as the 4-bit sign representation in zoned decimal fields."

But "IBM Websphere Studio COBOL for Windows V5.11" gives examples (p.37)
which shows that the 4-bit sign representation depends on usage mode:

My understanding is that:

- For (not separate) DISPLAY usage, it depends on the code:
EBCDIC: + is C, - is D and unsigned is F
ASCII: + and unsigned is 3, and - is 7.

- For PACKED-DECIMAL usage, it is fixed: + is C, - is D and unsigned is F.

Am I right ?

Thanks

--
Vincent Danion
Please, forgive my english !
William M. Klein

2004-11-22, 3:55 am

Vincent,
You have mixed "apples and oranges" - although you may well be correct that
there is an error in the documentation.

What the Enterprise COBOL LRM states *is* true for the Enterprise COBOL
compiler.

It is *NOT* (always) true for IBM's COBOL for Windows. The sign-nibble on the
PC (with the IBM compiler - and several others) is the same between
Packed-Decimal and Zoned Decimal when the compiler is in "EBCDIC" mode but IS
not the same when in ASCII mode.

Some compilers (for example Micro Focus) has an option for working in ASCII
mode - but using EBCDIC sign-nibbles (or vice versa - I can't remember off the
top of my head). However, this is NOT true for the IBM Windows compiler.

I don't see a separate web page for the "IBM Websphere Studio COBOL for Windows
V5.11" manuals, but the VisualAge COBOL (predecessor product) is at:
http://www-306.ibm.com/software/awd...bol/va/library/

and that seems to indicate that it uses the same LRM as the "mainframe" (older
version IBM COBOL for OS/390 & VM) LRM. If that is still the case with the
current Windows compiler, then what you have found is a "bug".

--
Bill Klein
wmklein <at> ix.netcom.com
"Vincent Danion" <vdaNOniSPAMon@scort.com> wrote in message
news:2vuenqF2p8il6U1@uni-berlin.de...
> Hello,
>
> I have a question about internal sign encoding.
>
> "IBM Enterprise COBOL for z/OS - Language Reference - V3R3" says (p.217):
>
> "PACKED-DECIMAL [...] The sign representation uses the same bit configuration
> as the 4-bit sign representation in zoned decimal fields."
>
> But "IBM Websphere Studio COBOL for Windows V5.11" gives examples (p.37) which
> shows that the 4-bit sign representation depends on usage mode:
>
> My understanding is that:
>
> - For (not separate) DISPLAY usage, it depends on the code:
> EBCDIC: + is C, - is D and unsigned is F
> ASCII: + and unsigned is 3, and - is 7.
>
> - For PACKED-DECIMAL usage, it is fixed: + is C, - is D and unsigned is F.
>
> Am I right ?
>
> Thanks
>
> --
> Vincent Danion
> Please, forgive my english !



Vincent Danion

2004-11-22, 8:55 am

William M. Klein wrote:

Hello,

> NOTE WELL:
> with current (currently supported) IBM mainframe COBOLs whether or not A, B,
> and E are (or are not) considered "valid" sign-nibbles is determined by an
> installation (not user) compiler option.


As far as I have understood, it seems that most compilers are accepting
different nibbles as valid, but use precise values when they are coding
the numbers.

> See:
> http://publibz.boulder.ibm.com/cgi-...S/IGY3C120/2.41


Thanks. Cobol compilers seems to be highly configurable ! Do you see any
reason (interoperability ?) why people would have configured a specific
sign encoding ?

For instance, OS/400 compilers generally use F for unsigned or
positives, except if CHGPOSSGN option is set (in this case, they use C).
Does anybody know if this option is often used on iSeries ?

> This, of course, has nothing to do with what Assembler or machine instructions
> allow. There are also rules about how other compiler options impact sign
> handling for COBOL - and there used to be a "usermod" for older COBOL's to do
> similar things.


Yes, I understand.

Regarding my initial question, we have done the test (under VA Cobol for
a CICS on NT): the sign nibble is trailing as expected. Therefore, there
is a bug in "IBM Websphere Studio COBOL PGM for Windows V5.11" p.37:

<quote>
For "PIC S9999 DISPLAY", the value -1234 is encoded like this (NATIVE):
71 32 33 34
</quote>

should be read as:

<quote>
For "PIC S9999 DISPLAY", the value -1234 is encoded like this (NATIVE):
31 32 33 74
</quote>

Have a nice w

--
Vincent Danion.

Vincent Danion

2004-11-26, 8:55 am

William M. Klein wrote:

Hello,

> NOTE WELL:
> with current (currently supported) IBM mainframe COBOLs whether or not A, B,
> and E are (or are not) considered "valid" sign-nibbles is determined by an
> installation (not user) compiler option.


As far as I have understood, it seems that most compilers are accepting
different nibbles as valid, but use precise values when they are coding
the numbers.

> See:
> http://publibz.boulder.ibm.com/cgi-...S/IGY3C120/2.41


Thanks. Cobol compilers seems to be highly configurable ! Do you see any
reason (interoperability ?) why people would have configured a specific
sign encoding ?

For instance, OS/400 compilers generally use F for unsigned or
positives, except if CHGPOSSGN option is set (in this case, they use C).
Does anybody know if this option is often used on iSeries ?

> This, of course, has nothing to do with what Assembler or machine instructions
> allow. There are also rules about how other compiler options impact sign
> handling for COBOL - and there used to be a "usermod" for older COBOL's to do
> similar things.


Yes, I understand.

Regarding my initial question, we have done the test (under VA Cobol for
a CICS on NT): the sign nibble is trailing as expected. Therefore, there
is a bug in "IBM Websphere Studio COBOL PGM for Windows V5.11" p.37:

<quote>
For "PIC S9999 DISPLAY", the value -1234 is encoded like this (NATIVE):
71 32 33 34
</quote>

should be read as:

<quote>
For "PIC S9999 DISPLAY", the value -1234 is encoded like this (NATIVE):
31 32 33 74
</quote>

Have a nice w

--
Vincent Danion.

Vincent Danion

2004-11-29, 3:55 pm

William M. Klein wrote:

Hello,

> NOTE WELL:
> with current (currently supported) IBM mainframe COBOLs whether or not A, B,
> and E are (or are not) considered "valid" sign-nibbles is determined by an
> installation (not user) compiler option.


As far as I have understood, it seems that most compilers are accepting
different nibbles as valid, but use precise values when they are coding
the numbers.

> See:
> http://publibz.boulder.ibm.com/cgi-...S/IGY3C120/2.41


Thanks. Cobol compilers seems to be highly configurable ! Do you see any
reason (interoperability ?) why people would have configured a specific
sign encoding ?

For instance, OS/400 compilers generally use F for unsigned or
positives, except if CHGPOSSGN option is set (in this case, they use C).
Does anybody know if this option is often used on iSeries ?

> This, of course, has nothing to do with what Assembler or machine instructions
> allow. There are also rules about how other compiler options impact sign
> handling for COBOL - and there used to be a "usermod" for older COBOL's to do
> similar things.


Yes, I understand.

Regarding my initial question, we have done the test (under VA Cobol for
a CICS on NT): the sign nibble is trailing as expected. Therefore, there
is a bug in "IBM Websphere Studio COBOL PGM for Windows V5.11" p.37:

<quote>
For "PIC S9999 DISPLAY", the value -1234 is encoded like this (NATIVE):
71 32 33 34
</quote>

should be read as:

<quote>
For "PIC S9999 DISPLAY", the value -1234 is encoded like this (NATIVE):
31 32 33 74
</quote>

Have a nice w

--
Vincent Danion.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com