Conversion Problem

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,

"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

"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 fo
r
>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).

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

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

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

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

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 genera
l
> 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 simila
r
> in general rule 4b and 4b3a on pages 479-480.
>
> I see strong evidence that this behavior was also mandated in ANSI-68 COBO
L,
> 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

Houman Ghahremanlou <houmi1@gmail.com> wrote in message news:<742dnVVAVJpgfYfcRVn-ow@wideop
enwest.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

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.