MOVE COMP-3 TO DISPLAY.
pottmi
This code is broken because the non-integer move to alphanumeric is
illegal.
--------------------
01 ACOMP3 PIC 9999v9 COMP-3.
01 ADISPLAY PIC X(6).
MOVE 1234.5 to ACOMP3.
MOVE ACOMP3 TO ADISPLAY.
DISPLAY ADISPLAY.
-------------------
What are some options for me to change this code such that the output
of the "DISPLAY ADISPLAY" statement is "1234.5" with the constraint
that ACOMP3 and ADISPLAY must remain defined as they are?
I could come up with some brute force way to do this, but I figure
one of you guys has to have a graceful way to do this.
--
Michael Potter
Pete Dashwood
"pottmi" <pot...@gmail.com> wrote in message
news:3417ff0f-baad-4cb9...@c33g2000hsd.googlegroups.com...
> COBOL Crew,
>
> This code is broken because the non-integer move to alphanumeric is
> illegal.
No it isn't. The code is not broken and the move is not illegal. You can
move non-integer to Alphanumeric with no problem.
Your understanding may be "broken" :-)
It currently shows 12345b ...where "b" is a blank, right?
> --------------------
> 01 ACOMP3 PIC 9999v9 COMP-3.
> 01 ADISPLAY PIC X(6).
>
> MOVE 1234.5 to ACOMP3.
> MOVE ACOMP3 TO ADISPLAY.
> DISPLAY ADISPLAY.
> -------------------
>
> What are some options for me to change this code such that the output
> of the "DISPLAY ADISPLAY" statement is "1234.5" with the constraint
> that ACOMP3 and ADISPLAY must remain defined as they are?
That seems to be a very unlikely thing to actually want to do (You could
simply move "1234.5" to ADISPLAY and display it to achieve what you stated
above...), so I have assumed that what you really want is a single decimal
place, preceded by a point, capable of handling various values:
01 ACOMP3 PIC 9999v9 COMP-3.
01 ADISPLAY PIC X(6).
... add two lines...
01 ADISPLAY-EDITED PIC z(4).9.
01 ADSTRING REDEFINES ADISPLAY-EDITED PIC X(6).
...
MOVE 1234.5 to ACOMP3.
MOVE ACOMP3 TO ADISPLAY-EDITED.
MOVE ADSTRING TO ADISPLAY.
DISPLAY ADISPLAY.
This will do what you require, within the constraints you specified.
REDEFINES is one of the most powerful features in COBOL.
Pete.
--
"I used to write COBOL...now I can do anything."
docd...@panix.com
pottmi <pot...@gmail.com> wrote:
>COBOL Crew,
>
>This code is broken because the non-integer move to alphanumeric is
>illegal.
Please do your own homework.
DD
pottmi
Your suggestion worked. thanks. I did not know about using a period
in the picture clause, that was the trick that makes the redefines
graceful.
For the benefit of others, here is a cut and paste ready scrap of
code:
01 CONSTANTS.
02 ACOMP3 PIC 9(4)v9 COMP-3.
02 ADISPLAY PIC X(6).
02 ANUMERIC PIC Z(4).9.
02 ASTRING REDEFINES ANUMERIC PIC X(6).
*
PROCEDURE DIVISION.
FIRST-PARA.
MOVE 1234.5 TO ACOMP3.
* MOVE ACOMP3 TO ADISPLAY.
* DISPLAY ADISPLAY.
MOVE ACOMP3 TO ANUMERIC.
DISPLAY "ASTRING = " ASTRING.
STOP RUN.
The commented out MOVE statement produces this error on the latest
version of microfocus compiler:
pottmi@mikesuse:~/cobtst/moverule> cob moverule.cbl
20 MOVE ACOMP3 TO ADISPLAY.
*1029-
E***************************
**
** A non-integer is being moved to an alphanumeric data item
Given that, can you clarify your statement that the MOVE is legal?
--
Michael Potter
On Mar 5, 6:48 pm, "Pete Dashwood"
Doug Miller
> 01 ACOMP3 PIC 9999v9 COMP-3.
> 01 ADISPLAY PIC X(6).
>
>.... add two lines...
> 01 ADISPLAY-EDITED PIC z(4).9.
> 01 ADSTRING REDEFINES ADISPLAY-EDITED PIC X(6).
>....
> MOVE 1234.5 to ACOMP3.
>MOVE ACOMP3 TO ADISPLAY-EDITED.
>MOVE ADSTRING TO ADISPLAY.
>DISPLAY ADISPLAY.
Even simpler:
01 ADISPLAY.
03 ADISPLAY-EDITED PIC Z(4).9.
..
MOVE 1234.5 TO ACOMP3.
MOVE ACOMP3 TO ADISPLAY-EDITED.
DISPLAY ADISPLAY.
To the OP: even though this may not look like it, it *does* satisfy your
constraint that the definition of ADISPLAY remain unchanged, as all group
items are PIC X(n) by default, where n is the aggregate length of the
elementary items comprising the group. Since there is only one elementary item
(ADISPLAY-EDITED), and it's six characters long, the default picture of the
group item ADISPLAY is PIC X(6).
--
Regards,
Doug Miller (alphageek at milmac dot com)
It's time to throw all their damned tea in the harbor again.
Arnold Trembley
> (snip)
> The commented out MOVE statement produces this error on the latest
> version of microfocus compiler:
>
> pottmi@mikesuse:~/cobtst/moverule> cob moverule.cbl
> 20 MOVE ACOMP3 TO ADISPLAY.
> *1029-
> E***************************
> **
> ** A non-integer is being moved to an alphanumeric data item
>
> Given that, can you clarify your statement that the MOVE is legal?
I really cannot speak for Pete Dashwood, but I am sure there are COBOL
compilers that allow the MOVE statement as written. I think the
Fujitsu COBOL compiler might be one. The question is, if a particular
COBOL compiler allows this kind of MOVE, what does it actually do?
There are versions of the IBM mainframe COBOL compiler that will
attempt a conversion from packed decimal to zoned decimal with this
kind of statement. I can't recall if that includes the current
Enterprise COBOL for z/OS, but I'm pretty sure VS COBOL II did that,
and I was surprised when I discovered it.
I don't think there is anything in the COBOL standard that would
prevent a COBOL compiler from treating this as a move of one string of
characters to another, with no conversion, but perhaps Bill Klein can
give a definitive answer.
In my opinion, it's always a bad idea to move packed-decimal data to a
PIC X field, and I would always prefer a more explicit data
conversion, such as Pete suggested. So I don't think there's anything
wrong with MicroFocus disallowing that MOVE statement.
Cheers,
Howard Brazee
wrote:
>COBOL Crew,
>
>This code is broken because the non-integer move to alphanumeric is
>illegal.
>--------------------
>01 ACOMP3 PIC 9999v9 COMP-3.
>01 ADISPLAY PIC X(6).
>
>MOVE 1234.5 to ACOMP3.
>MOVE ACOMP3 TO ADISPLAY.
>DISPLAY ADISPLAY.
>-------------------
Most compilers I've used allow simple displays of the packed data. I'm
trying to remember the syntax of the compiler that required a
conversion in the display. Something like DISPLAY ACOMP3 WITH
CONVERSION.
I routinely add some fields such as:
D01 DISPLAY-FIELDS.
D 05 DISPLAY-NDX PIC 9(05).
D 05 DISPLAY-SORT PIC Z(05).
D 05 DISPLAY-AMT1 PIC ++,+++,+++.99.
D 05 DISPLAY-AMT2 PIC ++,+++,+++.99.
Before I display most numbers, I move it here to see it better.
D MOVE AMOUNT-INDEX TO DISPLAY-NDX
D MOVE MY-AMOUNT (AMOUNT-INDEX) TO DISPLAY-AMT1
D DISPLAY 'DEBUG 01 - MY-AMOUNT (' DISPLAY-INDEX ')="'
D DISPLAY-AMT1 '"'.
Pete Dashwood
"pottmi" <pot...@gmail.com> wrote in message
news:2d29289d-7596-46fb...@c33g2000hsd.googlegroups.com...
> Pete,
>
> Your suggestion worked. thanks. I did not know about using a period
> in the picture clause, that was the trick that makes the redefines
> graceful.
>
No problem, glad to help.
This is called an "insertion" edit character. You can use a few other things
as well, depending on which compiler you are using.
It certainly looks like it ISN'T legal on MicroFocus. Sorry, I didn't know
that. I use Fujitsu, and, although I haven't tried it, I would expect it to
work. I would expect to be able to move ANYTHING to an AN receiving field
and find it left justifed in that field. (Maybe MY understanding is
broken... :-))
What the standard actually allows would be the domain of other posters here.
(I'm sure Bill Klein or Rick Smith can tell us what the current standard
allows and what the 2002 (yet to be implemented) standard proposes.)
I think Doug Miller's use of COBOL's implicit hierarchic structure is an
improvement over what I posted, and I think that what Arnold Trembley had to
say is worth noting.
You actually got pretty good value for your assistance request... :-)
Rick Smith
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:63b5e8F...@mid.individual.net...
1. The current standard is the 2002 standard. <g>
2. Behavior with COMP-3 is not defined in any COBOL standard.
3. Moving noninteger to alphanumeric is not a valid move in 2002
(MOVE statement SR8); nor was it valid, as nearly as I can tell,
in 85, 74, or 68.
Pete Dashwood
"Rick Smith" <rick...@mfi.net> wrote in message
news:13t13ek...@corp.supernews.com...
Thanks Rick. I stand corrected, and learned something... :-)