Cobol - Conversion Problem

Author

Conversion Problem

Houman Ghahremanlou

2004-08-12, 3:55 am

Hello Everyone,

I have a Cobol program which input comes from a file consisting of
records of each PIC X(7), representing a signed number in character format.

example of input record: -000007.

I need to convert this to a PIC S9(8) USAGE COMP-3.
But when I move the record to the above field I lose the sign! how can I
move without losing the sign?

Thank you,

Chuck Stevens

2004-08-13, 3:55 am

"Walter Murray" <wmurray@midtown.net> wrote in message
news:10hnlqdshfsgl59@corp.supernews.com...

> While we're on the subject, I have a question.
>
> In this format, if the value of the item is positive, the sign is the
> character '+'. If the value of the item is negative, the sign is the
> character '-'. If the value of the item is zero, what is the sign
> character? The standard doesn't seem to say, perhaps making this format
> somewhat less than completely portable. Or am I missing something?

The editing rules for signs produce one value for positive *or zero* values,
another for negative values. Floating-point values are positive if they're
zero (as are their exponents).

I'd conclude that standard COBOL is *inclined* to produce positive signs for
zero in the general case, but I don't think it's required to do so. That
which the standard fails to define is undefined.

Note also that POSITIVE, NEGATIVE and ZERO seem to be mutually-exclusive
*sign conditions* in COBOL.

> Maybe instead of "PIC S9(6) SIGN LEADING SEPARATE", one might use "PIC
> +9(6)". Then there would be no ambiguity about how zero would be
> represented. Thanks to de-editing, you could still use it as the sending
> operand in a MOVE statement.

True for compilers compliant with '85 and later standards, but not
applicable to earlier compilers.

-Chuck Stevens

Jeff York

2004-08-13, 8:55 am

"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Walter Murray" <wmurray@midtown.net> wrote in message
>news:10hnlqdshfsgl59@corp.supernews.com...
>
>
>
>The editing rules for signs produce one value for positive *or zero* values,
>another for negative values. Floating-point values are positive if they're
>zero (as are their exponents).
>
>I'd conclude that standard COBOL is *inclined* to produce positive signs for
>zero in the general case, but I don't think it's required to do so. That
>which the standard fails to define is undefined.

I reckon that the norm is that zero is positive. I remember Microfocus
having a problem with one of their early compilers which would
sometimes give the result of a computation as a negative zero, which
would then fail when tested = zero.. (It didn't take them long to fix
it either!).. :-)

--
Jeff. Ironbridge, Shrops, U.K.
jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)

.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."

Henry James, (1843 - 1916).

docdwarf@panix.com

2004-08-13, 8:55 am

In article <s33ph05j4nv238u1vppnm0pv35gr6ihmnm@4ax.com>,
Jeff York <ralf4@btinternet.com> wrote:
>"Chuck Stevens" <charles.stevens@unisys.com> wrote:

[snip]

>
>I reckon that the norm is that zero is positive.

Speaking only from my experience I'd have to agree. I was taught - along
with the READ INTO and WRITE FROM mentioned in another thread - that if
one wishes to initialise a signed numeric field of any sort one should
code a MOVE +0 TO... and that WORKING-STORAGE initialisation should be

05 NUMFLD PIC S9(9)V99 COMP-3 VALUE +0.

.... or something so similar as to be readily mistaken as identical. Other
folks seem to have been taught likewise; I cannot recall a single
experience of an MOVE or a VALUE for -0.

DD

docdwarf@panix.com

2004-08-13, 3:55 pm

In article <h1kph05sqrqitppat4orq1tle6v821d09u@4ax.com>,
Jeff York <ralf4@btinternet.com> wrote:
>docdwarf@panix.com wrote:
>
>
>Strewth Doc.!

Please, don't accuse me of Truth... I'm still sober!

>Who taught you COBOL? Grace Hopper - when she was
>still a Lieutenant (JG)?? :-)

Would that I were so fortunate; one of the advantages of this group is
that it allows me to read stuff by those who actually did work with the
Grand Old Lady and those whose work shape the language into its next form.

It should be obvious from the code that I post that I learned most of what
I know about coding from the backs of cereal-boxes... anyone got a box of
Autocoder Crunchies?

DD

Jeff York

2004-08-13, 3:55 pm

docdwarf@panix.com wrote:

>It should be obvious from the code that I post that I learned most of what
>I know about coding from the backs of cereal-boxes...

I'd suspected that, but didn't mention it out of respect for your
obvious dotage.

> anyone got a box of Autocoder Crunchies?

Sorry, no.. I do have a tin of Univac 1004 pin-lube if that's any
help.. :-)

--
Jeff. Ironbridge, Shrops, U.K.
jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)

.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."

Henry James, (1843 - 1916).

docdwarf@panix.com

2004-08-13, 3:55 pm

In article <3pqph05cg45ul12s2r1m96m4lhndsb8mqc@4ax.com>,
Jeff York <ralf4@btinternet.com> wrote:
>docdwarf@panix.com wrote:
>
>
>I'd suspected that, but didn't mention it out of respect for your
>obvious dotage.

Dotage? I'll show you dotage... durned kids... hey, someone help me hook
up a bottle of thin tea to my intravenous so i can work up the energy to
roll my wheelchair over there and whack 'im with my cane...zzzzzZZZzzzz.

>
>
>Sorry, no.. I do have a tin of Univac 1004 pin-lube if that's any
>help.. :-)

Been surfin' the porn sites again? Durned kids... zzzzzzzz.

DD

Robert Jones

2004-08-13, 3:55 pm

Bottom posting

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message news:<cfggff$2p34$1@si05.rsvl.unisys.com>...
> "Robert Jones" <rjones0@hotmail.com> wrote in message
> news:6dd8322.0408121055.69c8adc7@posting.google.com...
>
>
> Well, hm... The standards seem not only to permit this, but even to
> provide a description of what's supposed to happen when you do it.
>
> Gleaned from ANSI X3.23-1974, pages II-75 and II-76, MOVE statement general
> rule 4b and 4b3: "When a numeric or numeric edited item is the receiving
> item ... [and] a data item described as alphanumeric is the sending item,
> data is moved as if the sending item were described as an unsigned numeric
> integer." Exactly the same wording appears in ANSI X3.23-1985 on page
> VI-105 (same rule numbers, even). ISO/IEC 1989:2002 has something similar
> in general rule 4b and 4b3a on pages 479-480.
>
> I see strong evidence that this behavior was also mandated in ANSI-68 COBOL,
> but as I don't have a copy of ANSI X3.23-1968 I can't state this as an
> absolute certainty (the absence of any mention of this feature in the '74
> standard's substantive change list or in the History of COBOL section is
> telling, however).
>
> What's the vintage of the compiler you're referring to here?
>
> -Chuck Stevens

I must admit to not having checked the earlier standards. I started
on COBOL E, an early IBM compiler and was taught that it was good
practice to define fields for numeric data with numeric pictures. I
thought that was good advice, which I still follow and rarely
contravene, certainly not for the type of action Houman wanted to do.
I must admit that my knowledge of early standards was limited until
the mid 80s and that I am or have been an applications programmer
rather than a compiler designer or writer, so have had a rather
different approach.

Even so, the 2002 standard for the NUMERIC class test still indicates
that a usage DISPLAY field without a numeric picture can only contain
the characters 0..9, i.e. does not make provision for a sign.

Robert

Robert Jones

2004-08-14, 8:55 am

Houman Ghahremanlou <houmi1@gmail.com> wrote in message news:<742dnVVAVJpgfYfcRVn-ow@wideopenwest.com>...
> Hello Everyone,
>
> I have a Cobol program which input comes from a file consisting of
> records of each PIC X(7), representing a signed number in character format.
>
> example of input record: -000007.
>
> I need to convert this to a PIC S9(8) USAGE COMP-3.
> But when I move the record to the above field I lose the sign! how can I
> move without losing the sign?
>
> Thank you,

Hello Houman,

As an oldtimer less used to the more forgiving ways of new compilers,
I am surprised your program didn't just object to such a move.

However, if you define your PIC X(7) field as PIC S9(6)USAGE DISPLAY
LEADING SIGN IS SEPARATE instead, you should find that it works as
required.

As an aside, it would be a good idea to test whether it is numeric
before doing the MOVE/conversion and report any errors or assign a
useful default.

Regards

Robert

Houman Ghahremanlou

2004-08-15, 8:55 am

Thank you to both of you!

I was using a S9(7) SIGN IS LEADING SEPERATE and I'd get a SOC7
but by using S9(6) SIGN IS LEADING SEPERATE it worked just fine.

Thanks again for your help.

Houman

Donald Tees wrote:
> Houman Ghahremanlou wrote:
>
>
>
> Don't define them as X(7). Define them as S9(6), sign leading separate.
>
> Donald
>

Howard Brazee

2004-08-15, 8:55 am

On 11-Aug-2004, Houman Ghahremanlou <houmi1@gmail.com> wrote:

> I have a Cobol program which input comes from a file consisting of
> records of each PIC X(7), representing a signed number in character format.
>
> example of input record: -000007.
>
> I need to convert this to a PIC S9(8) USAGE COMP-3.
> But when I move the record to the above field I lose the sign! how can I
> move without losing the sign?

Either change your picture or use the NUMVAL function.

Chuck Stevens

2004-08-15, 8:55 am

"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:blNSc.18988$a65.860713@news20.bellglobal.com...
> Chuck Stevens wrote:
>
>
> when six characters in a S9(6) field (ie--- the sign is NOT separate)

In which case I would disagree with your characterization that it is a *bit*
that determines whether the datum is positive or negative. That's not
always the case. It is true that the implementor gets to decide what
constitutes a valid sign and how that sign is associated with the
leading/trailing digit of the datum.

In the Unisys MCP implementation, a four-bit sign in a field, whether that
field is USAGE DISPLAY or USAGE PACKED-DECIMAL, is treated *by the hardware*
as negative if, and only if, those four bits contain exactly 4"D" = 1"1101".
Any other value in the four-bit sign position is accepted as an indication
that the value is positive.

-Chuck Stevens

Donald Tees

2004-08-15, 3:55 pm

Chuck Stevens wrote:

>
>
> When *what* is six? The length of a character in DISPLAY form?

when six characters in a S9(6) field (ie--- the sign is NOT separate)

>
>
> Almost correct. Usage display sign *trailing* separate should be neither
> less nor more ambiguous than usage display sign *leading* separate.

True nuff.

Donald

docdwarf@panix.com

2004-08-16, 3:55 am

Jeff York

2004-08-16, 3:55 am

Jeff York

2004-08-16, 8:55 am

docdwarf@panix.com

2004-08-16, 8:55 am

Chuck Stevens

2004-08-17, 3:55 pm

"Robert Jones" <rjones0@hotmail.com> wrote in message
news:6dd8322.0408121055.69c8adc7@posting.google.com...

> As an oldtimer less used to the more forgiving ways of new compilers,
> I am surprised your program didn't just object to such a move.

Well, hm... The standards seem not only to permit this, but even to
provide a description of what's supposed to happen when you do it.

Gleaned from ANSI X3.23-1974, pages II-75 and II-76, MOVE statement general
rule 4b and 4b3: "When a numeric or numeric edited item is the receiving
item ... [and] a data item described as alphanumeric is the sending item,
data is moved as if the sending item were described as an unsigned numeric
integer." Exactly the same wording appears in ANSI X3.23-1985 on page
VI-105 (same rule numbers, even). ISO/IEC 1989:2002 has something similar
in general rule 4b and 4b3a on pages 479-480.

I see strong evidence that this behavior was also mandated in ANSI-68 COBOL,
but as I don't have a copy of ANSI X3.23-1968 I can't state this as an
absolute certainty (the absence of any mention of this feature in the '74
standard's substantive change list or in the History of COBOL section is
telling, however).

What's the vintage of the compiler you're referring to here?

-Chuck Stevens

Robert Jones

2004-08-17, 3:55 pm

To be a bit more gracious
[color=darkred]

Thanks for pointing this out, I had probably forgotten what can
sometimes be a useful feature, though it wasn't applicable in this
case and the concept of manipulating numeric data with numeric
definitions still has its benefits.

Robert

docdwarf@panix.com

2004-08-18, 3:55 am

Jeff York

2004-08-18, 3:55 am

Donald Tees

2004-08-18, 3:55 am

Houman Ghahremanlou wrote:
> Hello Everyone,
>
> I have a Cobol program which input comes from a file consisting of
> records of each PIC X(7), representing a signed number in character format.
>
> example of input record: -000007.
>
> I need to convert this to a PIC S9(8) USAGE COMP-3.
> But when I move the record to the above field I lose the sign! how can I
> move without losing the sign?
>
> Thank you,

Don't define them as X(7). Define them as S9(6), sign leading separate.

Donald

Houman Ghahremanlou

2004-08-18, 3:55 am

Donald Tees

2004-08-18, 3:55 am

Houman Ghahremanlou wrote:
> Thank you to both of you!
>
> I was using a S9(7) SIGN IS LEADING SEPERATE and I'd get a SOC7
> but by using S9(6) SIGN IS LEADING SEPERATE it worked just fine.
>
> Thanks again for your help.
>
> Houman
>

Signs in Cobol can be imbedded or separate. When the sign is separate
it counts as a character, so s9(7) sign leading separate is actually
eight characters long. That would make your record too big, as you
discovered. The sign leading separate is best for inter-program data
exchange, as it is standard ascii. The default is platform/compiler
dependent, so S9(6) may be six OR seven characters long, depending on
the compiler and platform. It may even default to nibbles, and not be
byte oriented at all. When it is six, the sign will be imbedded as a bit
within one of the digits, and again, which bit is somewhat
compiler/platform dependent.

The only absolute standard accross all platforms is usage display, sign
leading separate, and even then you have to take the character set into
consideration.

Donald

Chuck Stevens

2004-08-18, 3:55 am

"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:PkLSc.18917$a65.848430@news20.bellglobal.com...
> The default is platform/compiler
> dependent, so S9(6) may be six OR seven characters long, depending on
> the compiler and platform.

So far, so good ...

> It may even default to nibbles, and not be
> byte oriented at all.

If by "nibbles" you mean four-bit representation, I think it'd be tough for
PIC S9(6) to default to nibbles absent any USAGE clause specifying something
other than DISPLAY (which begs the question as to whether that situation
would really be a "default"), though there's no requirement that characters
in DISPLAY form be eight bits exactly.

> When it is six, the sign will be imbedded as a bit
> within one of the digits, and again, which bit is somewhat
> compiler/platform dependent.

When *what* is six? The length of a character in DISPLAY form?

I know of implementations that had *only* USAGE DISPLAY, *only* six-bit
characters and no packed-decimal, and *only* separate signs. There is no
requirement that the sign be embedded as a *single* bit; if the
implementation used multiple bits, it could detect an incorrectly-formed
value by the absence of an explicit sign in a signed field or the presence
of a sign in an unsigned field.

> The only absolute standard accross all platforms is usage display, sign
> leading separate, and even then you have to take the character set into
> consideration.

Almost correct. Usage display sign *trailing* separate should be neither
less nor more ambiguous than usage display sign *leading* separate.

-Chuck Stevens

Chuck Stevens

2004-08-18, 8:55 am

Robert Jones

2004-08-18, 8:55 am

Walter Murray

2004-08-18, 8:55 am

"Michael Mattias" <michael.mattias@gte.net> wrote:

> (FWIW, we know you haven't tried _real_ hard yet, because no compiler will
> accept a MOVE of an X(07) source to a numeric destination and you'd be
> asking about that error message).

Really? It works fine for me. In fact, I think the standard requires it.
It's just not the right approach in this situation, where the sending item
contains a separate sign.

IDENTIFICATION DIVISION.
PROGRAM-ID. MOVE-TEST.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A PIC X(7) VALUE "1234567".
01 B PIC S9(8) USAGE PACKED-DECIMAL.
PROCEDURE DIVISION.
BEGIN.
MOVE A TO B
DISPLAY B
STOP RUN.
END PROGRAM MOVE-TEST.

Walter

Walter Murray

2004-08-18, 8:55 am

"Houman Ghahremanlou" <houmi1@gmail.com> wrote:
> I have a Cobol program which input comes from a file consisting of
> records of each PIC X(7), representing a signed number in character
format.
> example of input record: -000007.
> I need to convert this to a PIC S9(8) USAGE COMP-3.
> But when I move the record to the above field I lose the sign! how can I
> move without losing the sign?

Several people have suggested describing the item as SIGN IS LEADING
SEPARATE, which is the logical solution.

While we're on the subject, I have a question.

In this format, if the value of the item is positive, the sign is the
character '+'. If the value of the item is negative, the sign is the
character '-'. If the value of the item is zero, what is the sign
character? The standard doesn't seem to say, perhaps making this format
somewhat less than completely portable. Or am I missing something?

Maybe instead of "PIC S9(6) SIGN LEADING SEPARATE", one might use "PIC
+9(6)". Then there would be no ambiguity about how zero would be
represented. Thanks to de-editing, you could still use it as the sending
operand in a MOVE statement.

Walter

Robert Jones

2004-08-18, 8:55 am

docdwarf@panix.com

2004-08-18, 8:55 pm

Michael Mattias

2004-08-19, 3:55 am

"Houman Ghahremanlou" <houmi1@gmail.com> wrote in message
news:742dnVVAVJpgfYfcRVn-ow@wideopenwest.com...
> Hello Everyone,
>
> I have a Cobol program which input comes from a file consisting of
> records of each PIC X(7), representing a signed number in character
format.
>
> example of input record: -000007.
>
> I need to convert this to a PIC S9(8) USAGE COMP-3.
> But when I move the record to the above field I lose the sign! how can I
> move without losing the sign?

You won't lose the sign if instead of PIC X(07) you define the input as PIC
S9(06) SIGN IS SEPARATE LEADING. THis assumes a "positive" value in the
input contains a "+" sign in the first position.

Or, you can use FUNCTION NUMVAL (see in your manual) on the X(07) input... I
think that will work, too.

If the plus sign does not appear in the input (let's say it is space), then
if FUNCTION NUMVAL doesn't work, you'll have to redefine your input
something like...

01 INPUT-RECORD.
05 SIGN-CHAR PIC X(01)
05 DIGITS PIC 9(06).

EVALUATE SIGN-CHAR
WHEN '-'
COMPUTE OUTPUT-VALUE = -1 * DIGITS
WHEN '+'
WHEN ' ' << space
MOVE DIGITS TO OUTPUT-VALUE
END-EVALUATE

(FWIW, we know you haven't tried _real_ hard yet, because no compiler will
accept a MOVE of an X(07) source to a numeric destination and you'd be
asking about that error message).

(Been a while for me and I simply cannot recall... is there a PICTURE for
numerics meaning "leading minus sign if negative, leading space if zero or
positive?")

MCM

Jeff York

2004-08-19, 3:55 am

Robert Jones

2004-08-21, 8:55 am

William M. Klein

2004-08-26, 3:55 pm

Chuck,
Did you look at interpretation A-286 (of the '85 Standard) in CIB-26?

Although it is talking about a literal sending item, it is my understanding of
this interpretation that when you move an alphanumeric sending item to a numeric
(or numeric-edited) item and the sending item as a SIGN in it, that "results are
undefined". The MOVE rules *only* define what happens when the sending
(alphanumeric) item includes an unsigned integer.

Obviously, the compiler is NOT required to figure out "logic flow" and determine
if the sending item HAPPENS to have an unsigned value at the time of the MOVE.
However, (at least in the 2002 Standard) it is ALLOWED to not compile a program
if it can determine that the sending item always contains a signed value.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cfggff$2p34$1@si05.rsvl.unisys.com...
> "Robert Jones" <rjones0@hotmail.com> wrote in message
> news:6dd8322.0408121055.69c8adc7@posting.google.com...
>
>
> Well, hm... The standards seem not only to permit this, but even to
> provide a description of what's supposed to happen when you do it.
>
> Gleaned from ANSI X3.23-1974, pages II-75 and II-76, MOVE statement general
> rule 4b and 4b3: "When a numeric or numeric edited item is the receiving
> item ... [and] a data item described as alphanumeric is the sending item,
> data is moved as if the sending item were described as an unsigned numeric
> integer." Exactly the same wording appears in ANSI X3.23-1985 on page
> VI-105 (same rule numbers, even). ISO/IEC 1989:2002 has something similar
> in general rule 4b and 4b3a on pages 479-480.
>
> I see strong evidence that this behavior was also mandated in ANSI-68 COBOL,
> but as I don't have a copy of ANSI X3.23-1968 I can't state this as an
> absolute certainty (the absence of any mention of this feature in the '74
> standard's substantive change list or in the History of COBOL section is
> telling, however).
>
> What's the vintage of the compiler you're referring to here?
>
> -Chuck Stevens
>
>

William M. Klein

2004-08-26, 3:55 pm

From the '85 Standard (I don't know about earlier), Page VI-55

"6.3.1.1.1 Comparison of Numeric Operands
...
Zero is considered a unique value regardless of the sign."

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cfgp5o$2uu0$1@si05.rsvl.unisys.com...
>
> "Walter Murray" <wmurray@midtown.net> wrote in message
> news:10hnlqdshfsgl59@corp.supernews.com...
>
>
>
> The editing rules for signs produce one value for positive *or zero* values,
> another for negative values. Floating-point values are positive if they're
> zero (as are their exponents).
>
> I'd conclude that standard COBOL is *inclined* to produce positive signs for
> zero in the general case, but I don't think it's required to do so. That
> which the standard fails to define is undefined.
>
> Note also that POSITIVE, NEGATIVE and ZERO seem to be mutually-exclusive
> *sign conditions* in COBOL.
>
>
> True for compilers compliant with '85 and later standards, but not
> applicable to earlier compilers.
>
> -Chuck Stevens
>
>

Howard Brazee

2004-08-26, 3:55 pm

In 1980 I worked in a shop that had recently converted from mainframe IBM DOS to
mainframe IBM OS. When we compared data in old tapes with new data, we went
through a routine to move unsigned numbers to signed numbers and back again in
order to be depicted consistently.

Chuck Stevens

2004-08-26, 3:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:TKPWc.12188$3O3.6558@newsread2.news.pas.earthlink.net...
> Chuck,
> Did you look at interpretation A-286 (of the '85 Standard) in CIB-26?

No, I didn't look at the CIBs.

> Although it is talking about a literal sending item, it is my
understanding of
> this interpretation that when you move an alphanumeric sending item to a
numeric
> (or numeric-edited) item and the sending item as a SIGN in it, that
"results are
> undefined". The MOVE rules *only* define what happens when the sending
> (alphanumeric) item includes an unsigned integer.

Right. 2002 would cause the raising of EC-DATA-INCOMPATIBLE.

-Chuck Stevens

William M. Klein

2004-08-31, 3:55 pm

William M. Klein

2004-08-31, 3:55 pm

Sponsored Links