Need help with REDEFINES (I think)....

I need to convert a PIC 9(8)V9(2) read from my input file to a PIC
9(7)V9(2) that I'll write to my output file, without losing anything
that is greater than  9,999,999.99 of course. I thought REDEFINE might
help me to accomplish this, with something like the following....

01  IN-AMOUNT    PIC 9(8)V9(2).
01  IN-AMOUNT-TXT REDEFINES IN-AMOUNT.
07 IN-AMOUNT-TXT-DOLLARS-10MM    PIC X.
07 IN-AMOUNT-TXT-DOLLARS-LT10MM  PIC X(7).
05 IN-AMOUNT-TXT-DECIMAL  PIC X.
05 IN-AMOUNT-TXT-CENTS    PIC X(2).
01 OUT-AMOUNT-TXT.
07 OUT-AMOUNT-TXT-DOLLARS-LT10MM    PIC X(7).
05 OUT-AMOUNT-TXT-DECIMAL  PIC X.
05 OUT-AMOUNT-TXT-CENTS    PIC X(2).
01  OUT-AMOUNT REDEFINES
OUT-AMOUNT-TXT             PIC 9(7)V9(2).

While processing, I intend to evaluate IN-AMOUNT-TXT-DOLLARS-10MM and
perform error handling if what contained is not null & not blank & not
0.

Can anyone offer me an educated opinion as to whether or not this will
work, or better still...is there a better way to do this. I already
tried to put the PIC 9(8)V9(2) into the PIC 9(7)V9(2), without
success. A number like 1833.69 wound up as 183.36 in the output field,
the remaining 9 wound up in a FILLER PIC X field that I'd defined to
make up for my missing byte on my output record (which I intend to do
again, btw).

Thanks in advance for your help.

"Scott J. Chlebove" <chlebsco@enter.net> wrote in message
news:6a4d6da2.0411231141.2616f08f@posting.google.com...
>I need to convert a PIC 9(8)V9(2) read from my input file to a PIC
> 9(7)V9(2) that I'll write to my output file, without losing anything
> that is greater than  9,999,999.99 of course. I thought REDEFINE might
> help me to accomplish this, with something like the following....
>
> 01  IN-AMOUNT    PIC 9(8)V9(2).
> 01  IN-AMOUNT-TXT REDEFINES IN-AMOUNT.
>        07 IN-AMOUNT-TXT-DOLLARS-10MM    PIC X.
>        07 IN-AMOUNT-TXT-DOLLARS-LT10MM  PIC X(7).
>    05 IN-AMOUNT-TXT-DECIMAL  PIC X.
^^^^^^  The V is an implied decimal point, and
does not consume a character
>    05 IN-AMOUNT-TXT-CENTS    PIC X(2).
> 01 OUT-AMOUNT-TXT.
>        07 OUT-AMOUNT-TXT-DOLLARS-LT10MM    PIC X(7).
>    05 OUT-AMOUNT-TXT-DECIMAL  PIC X.
>    05 OUT-AMOUNT-TXT-CENTS    PIC X(2).
> 01  OUT-AMOUNT REDEFINES
>    OUT-AMOUNT-TXT             PIC 9(7)V9(2).
>
> While processing, I intend to evaluate IN-AMOUNT-TXT-DOLLARS-10MM and
> perform error handling if what contained is not null & not blank & not
> 0.

Null?  Not a COBOL concept.

>
> Can anyone offer me an educated opinion as to whether or not this will
> work, or better still...is there a better way to do this. I already
> tried to put the PIC 9(8)V9(2) into the PIC 9(7)V9(2), without
> success. A number like 1833.69 wound up as 183.36 in the output field,
> the remaining 9 wound up in a FILLER PIC X field that I'd defined to
> make up for my missing byte on my output record (which I intend to do
> again, btw).
>
> Thanks in advance for your help.

Here's what I would do:

01  IN-AMOUNT    PIC 9(8)V9(2).
01  OUT-AMOUNT-TXT             PIC 9(7)V9(2).

...
if In-Amount numeric
Add 0 to In-Amount giving out-amount-txt
ON SIZE ERROR
<handle the 'too big' error case here>
end-add
else
<handle nonnumeric case here>
end-if

MOVE allows truncation without detection of size errors.  Adding zero does
not change the value, but does allow you to detect your error case.

There is also the sensible:

If In-Amount numeric and In-Amount > 9999999.99
<handle error case here>
end-if

(note: the order of the tests in the IF statement is important to avoid
testing a nonnumeric against a numeric value.)

No redefines to need help with...

Best regards,
Tom Morrison
Liant Software Corporation

..    On  23.11.04
wrote  chlebsco@enter.net (Scott J. Chlebove)
on  /COMP/LANG/COBOL
in  6a4d6da2.0411231141.2616f08f@posting.google.com
about  Need help with REDEFINES (I think)....


SJC> I need to convert a PIC 9(8)V9(2) read from my input file to a PIC
SJC> 9(7)V9(2) that I'll write to my output file, without losing anything
SJC> that is greater than  9,999,999.99 of course. I thought REDEFINE
SJC> might help me to accomplish this, with something like the
SJC> following....
SJC>
SJC> 01  IN-AMOUNT    PIC 9(8)V9(2).

SJC> 01  OUT-AMOUNT
SJC>                     PIC 9(7)V9(2).
SJC>
SJC> While processing, I intend to evaluate IN-AMOUNT-TXT-DOLLARS-10MM
SJC> and perform error handling if what contained is not null & not blank
SJC> & not 0.

Why not using COBOL's built in exception processing, like this:


COMPUTE Out-Amount = In-Amount
ON SIZE ERROR
DISPLAY 'In-Amount doesnt fit in Out-Amount'
NOT SIZE ERROR
DISPLAY 'Happy end!'
END-COMPUTE


or so.



Yours,
Lüko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Die Superklugheit ist eine der verächtlichsten Arten von Unklugheit. -G.C.Li
chtenberg

chlebsco@enter.net (Scott J. Chlebove) wrote

> I need to convert a PIC 9(8)V9(2) read from my input file to a PIC
> 9(7)V9(2) that I'll write to my output file, without losing anything
> that is greater than  9,999,999.99 of course.

How do you think that you can get 10,000,000.00 into a 9 digit 9(7)V99
field ?

> I thought REDEFINE might
> help me to accomplish this, with something like the following....
>
> 01  IN-AMOUNT    PIC 9(8)V9(2).
> 01  IN-AMOUNT-TXT REDEFINES IN-AMOUNT.
>         07 IN-AMOUNT-TXT-DOLLARS-10MM    PIC X.
>         07 IN-AMOUNT-TXT-DOLLARS-LT10MM  PIC X(7).
>     05 IN-AMOUNT-TXT-DECIMAL  PIC X.

A PIC 9(8)V99 DISPLAY is a 10 byte field and the is _no_ byte for the
V.  V is an _implied_ decimal point, not an actual one.

>     05 IN-AMOUNT-TXT-CENTS    PIC X(2).

> 01 OUT-AMOUNT-TXT.
>         07 OUT-AMOUNT-TXT-DOLLARS-LT10MM    PIC X(7).
>     05 OUT-AMOUNT-TXT-DECIMAL  PIC X.
>     05 OUT-AMOUNT-TXT-CENTS    PIC X(2).
> 01  OUT-AMOUNT REDEFINES
>     OUT-AMOUNT-TXT             PIC 9(7)V9(2).
>
> While processing, I intend to evaluate IN-AMOUNT-TXT-DOLLARS-10MM and
> perform error handling if what contained is not null & not blank & not
> 0.

> Can anyone offer me an educated opinion as to whether or not this will
> work, or better still...is there a better way to do this. I already
> tried to put the PIC 9(8)V9(2) into the PIC 9(7)V9(2), without

01  In-Amount       PIC 9(8)V99.
01  Out-Amount      PIC 9(7)V99.

ADD ZERO In-Amount GIVING Out-Amount
ON SIZE ERROR
DISPLAY "Number > 9,999,999.99 found"
END-ADD


> success. A number like 1833.69 wound up as 183.36 in the output field,
> the remaining 9 wound up in a FILLER PIC X field that I'd defined to
> make up for my missing byte on my output record (which I intend to do
> again, btw).

What actual MOVEs did you do ?

Scott J. Chlebove wrote:
> I need to convert a PIC 9(8)V9(2) read from my input file to a PIC
> 9(7)V9(2) that I'll write to my output file, without losing anything
> that is greater than  9,999,999.99 of course. I thought REDEFINE might
> help me to accomplish this, with something like the following....
>
> 01  IN-AMOUNT    PIC 9(8)V9(2).
> 01  IN-AMOUNT-TXT REDEFINES IN-AMOUNT.
>        07 IN-AMOUNT-TXT-DOLLARS-10MM    PIC X.
>        07 IN-AMOUNT-TXT-DOLLARS-LT10MM  PIC X(7).
>    05 IN-AMOUNT-TXT-DECIMAL  PIC X.
>    05 IN-AMOUNT-TXT-CENTS    PIC X(2).
> 01 OUT-AMOUNT-TXT.
>        07 OUT-AMOUNT-TXT-DOLLARS-LT10MM    PIC X(7).
>    05 OUT-AMOUNT-TXT-DECIMAL  PIC X.
>    05 OUT-AMOUNT-TXT-CENTS    PIC X(2).
> 01  OUT-AMOUNT REDEFINES
>    OUT-AMOUNT-TXT             PIC 9(7)V9(2).
>
> While processing, I intend to evaluate IN-AMOUNT-TXT-DOLLARS-10MM and
> perform error handling if what contained is not null & not blank & not
> 0.
>
> Can anyone offer me an educated opinion as to whether or not this will
> work, or better still...is there a better way to do this. I already
> tried to put the PIC 9(8)V9(2) into the PIC 9(7)V9(2), without
> success. A number like 1833.69 wound up as 183.36 in the output field,
> the remaining 9 wound up in a FILLER PIC X field that I'd defined to
> make up for my missing byte on my output record (which I intend to do
> again, btw).
>
> Thanks in advance for your help.

You're making it too hard. Forget about all that PIC X(....) stuff and
testing here and there, redefining, renaming, etc.

01  IN-AMOUNT PIC 9(8)V99.
01  OUT-AMOUNT PIC 9(7)V99.

...
MOVE IN-AMOUNT TO OUT-AMOUNT.
IF IN-AMOUNT > 99,999,999.99
DISPLAY 'E! '. (or error processing to your liking)
....

On Tue, 23 Nov 2004 16:30:05 -0600, "JerryMouse" <nospam@bisusa.com>
wrote:

>01  IN-AMOUNT PIC 9(8)V99.
...
>IF IN-AMOUNT > 99,999,999.99
>   DISPLAY 'E! '. (or error processing to your liking)

DISPLAY 'Tardis storage alert!'
;-)

Jeez Jerry,

you're having a bad w... <G>

see below...

"JerryMouse" <nospam@bisusa.com> wrote in message
news:guWdnQIytZF7JD7cRVn-hg@giganews.com...
> Scott J. Chlebove wrote: 
>
> You're making it too hard. Forget about all that PIC X(....) stuff and
> testing here and there, redefining, renaming, etc.
>
> 01  IN-AMOUNT PIC 9(8)V99.
> 01  OUT-AMOUNT PIC 9(7)V99.
>
> ...
> MOVE IN-AMOUNT TO OUT-AMOUNT.
> IF IN-AMOUNT > 99,999,999.99
>    DISPLAY 'E! '. (or error processing to your liking)
> ....
>
I see two problems with this....

1. Why would you do the MOVE, THEN test the source field? Seems illogical...
2. The condition can NEVER be true, as the literal is for the maximum amount
that can be held.

I THINK it needs...

01  IN-AMOUNT PIC 9(8)V99.
01  OUT-AMOUNT PIC 9(7)V99.

..
IF IN-AMOUNT > 9,999,999.99
DISPLAY 'E! '. (or error processing to your liking)
ELSE
MOVE IN-AMOUNT TO OUT-AMOUNT.

... but I prefer the ON SIZE ERROR offerings anyway...

(That is a style preference because I happen to like event oriented code...
let's not have a war about it <sigh> )

Pete.

"Scott J. Chlebove" <chlebsco@enter.net> wrote
> I need to convert a PIC 9(8)V9(2) read from my input file to a PIC
> 9(7)V9(2) that I'll write to my output file, without losing anything
> that is greater than  9,999,999.99 of course.

[snip]

The following has a certain appeal to me.

01  IN-AMOUNT    PIC 9(8)V9(2).
01  OUT-AMOUNT PIC 9(7)V9(2).

MOVE IN-AMOUNT TO OUT-AMOUNT
IF IN-AMOUNT NOT = OUT-AMOUNT
[error code here]

Walter





----== Posted via mcse.ms - Unlimited-Uncensored-Secure Usenet News==-
---
http://www.mcse.ms The #1 Newsgroup Service in the World! >100,000 New
sgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Well done, Walter!

This is an imaginative simple solution. I like it best of all the ones
posted.

Pete
(Top post, no more below).

"Walter Murray" <wmurray@midtown.net> wrote in message
news:41a40c5d$1_3@127.0.0.1...
> "Scott J. Chlebove" <chlebsco@enter.net> wrote 
>
> [snip]
>
> The following has a certain appeal to me.
>
> 01  IN-AMOUNT    PIC 9(8)V9(2).
> 01  OUT-AMOUNT PIC 9(7)V9(2).
>
> MOVE IN-AMOUNT TO OUT-AMOUNT
> IF IN-AMOUNT NOT = OUT-AMOUNT
>     [error code here]
>
> Walter
>
>
>
>
>
> ----== Posted via mcse.ms - Unlimited-Uncensored-Secure Usenet
News==----
> http://www.mcse.ms The #1 Newsgroup Service in the World! >100,000
Newsgroups
> ---= East/West-Coast Server Farms - Total Privacy via Encryption =---
>

Pete Dashwood wrote:
> Jeez Jerry,
>
> you're having a bad w... <G>
>
> see below... 
> I see two problems with this....
>
> 1. Why would you do the MOVE, THEN test the source field? Seems
> illogical...

You're right. Amend the first iteration to be:

IF IN-AMOUNT > 99,999,999.99
DISPLAY 'E!'.
MOVE IN-AMOUNT TO OUT-AMOUNT.

> 2. The condition can NEVER be true, as the literal is for the maximum
> amount that can be held.

Yep, you're right.

>
> I THINK it needs...
>
> 01  IN-AMOUNT PIC 9(8)V99.
> 01  OUT-AMOUNT PIC 9(7)V99.
>
> ...
>      IF IN-AMOUNT > 9,999,999.99
>          DISPLAY 'E! '. (or error processing to your liking)
>      ELSE
>          MOVE IN-AMOUNT TO OUT-AMOUNT.
>
> ... but I prefer the ON SIZE ERROR offerings anyway...

But then the output amount contains the value from the previous record, or
perhaps a fish. Of course, in that case, we're just discussing varying
degrees of wrong...

My aim was to derail the original poster's building of a very large Gordian
knot (which, according to a re-telling in the latest Oliver Stone movie,
Alexander solves by painting it mauve).