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

Author

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

Scott J. Chlebove

2004-11-23, 8:55 pm

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.

Tom Morrison

2004-11-23, 8:55 pm

"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

Lueko Willms

2004-11-23, 8:55 pm

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

Richard

2004-11-23, 8:55 pm

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 ?

JerryMouse

2004-11-23, 8:55 pm

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

Ian Dalziel

2004-11-23, 8:55 pm

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!'
;-)

Pete Dashwood

2004-11-23, 8:55 pm

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.

Walter Murray

2004-11-24, 3:55 am

"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 Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Pete Dashwood

2004-11-24, 8:55 am

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 Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000
Newsgroups
> ---= East/West-Coast Server Farms - Total Privacy via Encryption =---
>

JerryMouse

2004-11-24, 3:55 pm

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

Tom Morrison

2004-11-24, 3:55 pm

Several posters have missed a very crucial portion of the original problem
statement....

"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
[snip]
> 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.

The "not null & not blank" *require* a NUMERIC test before any attempt to
manipulate the numbers in any type of arithmetic (include numeric-to-numeric
MOVE, ADD, COMPUTE, or an IF comparison involving a numeric literal). Not
to do so is inviting program misbehavior, unpredictable results, or even
program termination.

Richard

2004-11-24, 8:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote

> IF IN-AMOUNT > 9,999,999.99

If you want to maintain your reputation of being a pendantic
fuddy-duddy ;-)
you should point out that JerryMouse's code fails to compile because
of the inappropriate commas.

Pete Dashwood

2004-11-24, 8:55 pm

"Tom Morrison" <t.morrison@liant.com> wrote in message
news:581pd.36749$Al3.14049@newssvr30.news.prodigy.com...
> Several posters have missed a very crucial portion of the original problem
> statement....
>
> "Scott J. Chlebove" <chlebsco@enter.net> wrote in message
> news:6a4d6da2.0411231141.2616f08f@posting.google.com...
> [snip]
You don't think the solution could take that as read, Tom?

I see editing and validation as separate from the the problem described
regarding the size of operands.

Scott has documented that he will check for null, blank, non-zero and
perform error handling.

It seems reasonable to me that by the time he decides to manipulate the data
it has passed these tests.

(Besides, that's the boring bit; the FUN bit is addressing the size
incompatibility... <G> )

[color=darkred]
> The "not null & not blank" *require* a NUMERIC test before any attempt to
> manipulate the numbers in any type of arithmetic (include
numeric-to-numeric
> MOVE, ADD, COMPUTE, or an IF comparison involving a numeric literal). Not
> to do so is inviting program misbehavior, unpredictable results, or even
> program termination.
>
Yes, quite right. I use a component for this so I DON'T do a NUMERIC test as
such (the component checks for numeric and a whole bunch of other things
besides...), but few here would disagree with the principle you describe.

Pete.

Pete Dashwood

2004-11-24, 8:55 pm

It's funny...

I did notice that. (Maybe I'm more pedantic than I thought <G> )

I didn't comment because I believe SOME compilers WILL allow a numeric
literal to be written with commas in it (something stirs in the dark
recesses of the Black Lagoon I call a memory...), and also because
JerryMouse has had quite enough for one w

... <G>

Pete.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0411241009.4557430f@posting.google.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote
>
>
> If you want to maintain your reputation of being a pendantic
> fuddy-duddy ;-)
> you should point out that JerryMouse's code fails to compile because
> of the inappropriate commas.
>

Joe Zitzelberger

2004-11-25, 3:55 am

In article <30khlvF315qomU4@uni-berlin.de>,
"Pete Dashwood" <dashwood@enternet.co.nz> wrote:
[color=darkred]
> It's funny...
>
> I did notice that. (Maybe I'm more pedantic than I thought <G> )
>
> I didn't comment because I believe SOME compilers WILL allow a numeric
> literal to be written with commas in it (something stirs in the dark
> recesses of the Black Lagoon I call a memory...), and also because
> JerryMouse has had quite enough for one w

... <G>
>
> Pete.
>
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:217e491a.0411241009.4557430f@posting.google.com...

I don't think NUMERIC will pass it, but IMB will accept commas in the
NUMVAL function...

Lueko Willms

2004-11-25, 8:55 am

.. On 25.11.04
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 30khlrF315qomU2@uni-berlin.de
about Re: Need help with REDEFINES (I think)....

PD> (Besides, that's the boring bit; the FUN bit is addressing the size
PD> incompatibility... <G> )

and in COBOL, there is this ON SIZE ERROR phrase, which is the
appropriate thing to use in this case.

Maybe preceded by a IF NUMERIC check, so:

IF source-variable NUMERIC
THEN
COMPUTE destination-variable = source-variable
ON SIZE ERROR
*> do the appropriate thing, e.g.
DISPLAY
"Hey - the source-variable " source-variable " doesn't fit!"
NOT SIZE ERROR
*> rejoice the happy end
CONTINUE
END-COMPUTE
ELSE
DISPLAY "The source-variable " source-variable " is not numeric!"
END-IF

and let the compiler chose the optimumt for checking the size error
instead of inventing the wheel anew.

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

Er urteilt nach dem jedesmaligen Aggregatzustand seiner Empfindungen. -G.C.Lichtenberg

Pete Dashwood

2004-11-25, 3:55 pm

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9LXUmMNeflB@jpberlin-l.willms.jpberlin.de...
> . On 25.11.04
> wrote dashwood@enternet.co.nz (Pete Dashwood)
> on /COMP/LANG/COBOL
> in 30khlrF315qomU2@uni-berlin.de
> about Re: Need help with REDEFINES (I think)....
>
>
> PD> (Besides, that's the boring bit; the FUN bit is addressing the size
> PD> incompatibility... <G> )
>
> and in COBOL, there is this ON SIZE ERROR phrase, which is the
> appropriate thing to use in this case.
>
Hmmm... that is your opinion, Lueko.

I disagree.

Here's my opinion... <G>

> Maybe preceded by a IF NUMERIC check, so:
>
> IF source-variable NUMERIC
> THEN
> COMPUTE destination-variable = source-variable
> ON SIZE ERROR
> *> do the appropriate thing, e.g.
> DISPLAY
> "Hey - the source-variable " source-variable " doesn't fit!"
> NOT SIZE ERROR
> *> rejoice the happy end
> CONTINUE
> END-COMPUTE
> ELSE
> DISPLAY "The source-variable " source-variable " is not numeric!"
> END-IF
>
I see the numeric validation as separate from the size issue and IF NUMERIC
is a very poor way to check numeric input data. (certain alphas, that just
happen to be in the right position and have the right value, may be
considered signs and let through... A plus, minus, or decimal point may all
invalidate the field). If you make the numeric check device dependent (by
setting numeric attributes on a 3270 for example) your code is locked in to
a device that will do the check for you. If you then transport the code to a
different system you may find an alarming increase in the number of input
data errors.

I use a component that expects a standard device independent string and
checks each character of it to decide whether it represents a number or not,
recognising that the string may contain leading or trailing signs and a
single decimal point. It then sets properties that give me the number in
various internal and external formats. Plus a whole lot more besides.

Editing and validation of formats should occur in the presentation layer of
the system, not in the business logic.

>
>
>
> and let the compiler chose the optimumt for checking the size error
> instead of inventing the wheel anew.
>

The solution which Walter posted is simple and imaginative and it does not
preclude the compiler optimizing it. Neither does it reinvent the wheel. It
is also much more efficient (if you are bothered about that) than IF NUMERIC
( a compiler generated subroutine) or ON SIZE ERROR (another compiler
generated subroutine) because it uses a simple compare (or series of
character compares) and branch on condition. (Obviously the generated code
will vary on different platforms; I am basing the above on my experience of
IBM mainframe and the Intel platform.) I believe that the general outline
would be fairly consistent across platforms, but even if I'm wrong and there
is one (or more) platforms where IF NUMERIC and ON SIZE ERROR are INCREDIBLY
efficient, I still like Walter's solution better...<G>

The efficiency of it, while a positive factor, is not what sways me here...
it is the simple elegance of it.

The other solutions are clumsy and unwieldy in comparison.

(It is so

, I wish I'd thought of it!)

Pete.

Lueko Willms

2004-11-25, 8:55 pm

.. On 26.11.04
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 30m2m3F2vmrnvU1@uni-berlin.de
about Re: Need help with REDEFINES (I think)....

PD> I see the numeric validation as separate from the size issue and IF
PD> NUMERIC is a very poor way to check numeric input data. (certain
PD> alphas, that just happen to be in the right position and have the
PD> right value,

etc

Sure, depending on the source of the data, a more detailed check
might be required. But we hardly don't use punched cards any more, do
we? And a good form does check by itself is input data is numeric.

BTW, the source variable was declared as PIC 9(8)V99, so if a comma
or point or anything but a digit would be in there, it would be wrong,
so the NUMERIC class test is fully appropriate.

LW>> and let the compiler chose the optimum for checking the size error
LW>> instead of inventing the wheel anew.

PD> The solution which Walter posted is simple and imaginative and it
PD> does not preclude the compiler optimizing it.

But there is no guarantee that the compiler _does_ optimize it. The
normal way would be to convert the string into a number and to a
numerical compare.

And on reading that construct, the reason for it is not so clear as
if the ON SIZE ERROR exception is explicitly used.

PD> It is also much more efficient (if you are
PD> bothered about that) than IF NUMERIC ( a compiler generated
PD> subroutine) or ON SIZE ERROR (another compiler generated subroutine)

Well, I think the compiler can organize a more efficient ckeck than
optimizing something with some sort of second guess. It could e.g.
generate code to just check the most significant digits which would
not fit in the destination field.

You advance very contradictory statements: the full numeric
comparison is supposedly more efficient, because "it does not
_preclude_ the compiler optimizing it", but telling the compiler
directly, what the whole thing is about is less efficient?

Well, I leave aside my generalization of attitudes of COBOL
programmers ...

COBOL is a _compiled_ language, and is not assembler. Why not use
BASIC if all those special features of COBOL are being avoided?

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

Das Buch muß erst ausgedroschen werden. -G.C.Lichtenberg

Ian Dalziel

2004-11-25, 8:55 pm

On 25 Nov 2004 15:06:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

> BTW, the source variable was declared as PIC 9(8)V99, so if a comma
>or point or anything but a digit would be in there, it would be wrong,
>so the NUMERIC class test is fully appropriate.

Can you do a NUMERIC test on a numeric field? I thought it had to be
alphanumeric.

Ian

Lueko Willms

2004-11-25, 8:55 pm

.. On 25.11.04
wrote iandalziel@lineone.net (Ian Dalziel)
on /COMP/LANG/COBOL
in ij4cq0l829tsn3ortp6o2qkpj0lrva8koj@4ax.com
about Re: Need help with REDEFINES (I think)....

[color=darkred]

ID> Can you do a NUMERIC test on a numeric field?

Yes.

ID> I thought it had to be alphanumeric.

Maybe you confuse this with the rule that the item had to be of
explicit or implicit USAGE DISPLAY, but that does not preclude it to
be of category numeric.

See COBOL-74, Nucleus, 6.2.1.2: Class Condition
COBOL-85, Nucleus, 6.3.1.2: Class Condition
COBOL-2002, 8.8.4.1.3: Class Condition (p. 131ff)

Excluded are items described as alphabetic or a group item where
elementary items under this group can have a sign (plus or minus).

Looking at the pertinent section of the 2002 standard, it is not
completely clear to me if that one requires USAGE DISPLAY. Syntax rule
2 requires an item "whose usage is display or national or whose
category is numeric".

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

Belehrung findet man öfter in der Welt als Trost. -G.C.Lichtenberg

Robert Wagner

2004-11-25, 8:55 pm

On 25 Nov 2004 15:06:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>PD> It is also much more efficient (if you are
>PD> bothered about that) than IF NUMERIC ( a compiler generated
>PD> subroutine) or ON SIZE ERROR (another compiler generated subroutine)

> You advance very contradictory statements: the full numeric
>comparison is supposedly more efficient, because "it does not
>_preclude_ the compiler optimizing it", but telling the compiler
>directly, what the whole thing is about is less efficient?

You're right. I've seen a good Cobol compiler do IF NUMERIC on an
unsigned field with one in-line machine instruction (TRT on s/390).

> COBOL is a _compiled_ language, and is not assembler. Why not use
>BASIC if all those special features of COBOL are being avoided?

Programmers were once paid to help the machine. Some haven't learned
that's now counter-productive.

Robert Wagner

2004-11-25, 8:55 pm

On Thu, 25 Nov 2004 17:13:14 +0000, Ian Dalziel
<iandalziel@lineone.net> wrote:

>On 25 Nov 2004 15:06:00 GMT, l.willms@jpberlin.de (Lueko Willms)
>wrote:
>
>
>Can you do a NUMERIC test on a numeric field? I thought it had to be
>alphanumeric.

You have it backwards. In the old old days, some compilers required
that it be numeric. There was a reason: so they knew what sign was
valid, and whether to test for display, packed or binary. Remember, IF
NUMERIC is very often used on packed decimal.

Others, when given alphanumeric, assumed a sign over the right digit
was valid. Thus X(1) with a value of 'A' passed the numeric test. One
had to say IF A IS NUMERIC AND A NOT ALPHABETIC.

The 2002 standard says:

b. If the usage of the data item referenced by identifier-1 is not
display or national, the condition is true if the content of the data
item referenced by identifier-1 consists entirely of a valid
representation for the usage and, if a PICTURE clause is specified,
its numeric value is within the range of values implied by the PICTURE
clause.

2. If the category of the data item referenced by identifier-1 is not
numeric, the condition is true if the content of the data item
referenced by identifier-1 consists entirely of the characters 0, 1,
2, 3, ..., 9.

Pete Dashwood

2004-11-25, 8:55 pm

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9LXZ4A1eflB@jpberlin-l.willms.jpberlin.de...
> . On 26.11.04
> wrote dashwood@enternet.co.nz (Pete Dashwood)
> on /COMP/LANG/COBOL
> in 30m2m3F2vmrnvU1@uni-berlin.de
> about Re: Need help with REDEFINES (I think)....
>
>
> PD> I see the numeric validation as separate from the size issue and IF
> PD> NUMERIC is a very poor way to check numeric input data. (certain
> PD> alphas, that just happen to be in the right position and have the
> PD> right value,
>
> etc
>
> Sure, depending on the source of the data, a more detailed check
> might be required. But we hardly don't use punched cards any more, do
> we? And a good form does check by itself is input data is numeric.

So, why include IF NUMERIC in your sample if you believe that?
>
> BTW, the source variable was declared as PIC 9(8)V99, so if a comma
> or point or anything but a digit would be in there, it would be wrong,
> so the NUMERIC class test is fully appropriate.
>
Not necessarily. And anyway, IMNSHO it should be in a separate tier...
>
> LW>> and let the compiler chose the optimum for checking the size error
> LW>> instead of inventing the wheel anew.
>
>
> PD> The solution which Walter posted is simple and imaginative and it
> PD> does not preclude the compiler optimizing it.
>
> But there is no guarantee that the compiler _does_ optimize it.
Why would an optimizing compiler ONLY optimize ON SIZE ERROR and not other
code? I don't think so...

(Certainly the one I worked on (B500 in 1969) tried to optimize
EVERYTHING... <G> )

>The
> normal way would be to convert the string into a number and to a
> numerical compare.
>

That is simply speculation and the optimization of it is not the issue. If
you read my response I said that even if it was INCREDIBLY efficient, I
still don't like it. Neither you nor Robert addressed that.

> And on reading that construct, the reason for it is not so clear as
> if the ON SIZE ERROR exception is explicitly used.
>

Again, simply opinion. It is perfectly clear to me what is happening. It MAY
not be clear to someone else or it MAY be clear... this comes down to what
is familiar being most easily recognizable. Ask Richard about that.

> PD> It is also much more efficient (if you are
> PD> bothered about that) than IF NUMERIC ( a compiler generated
> PD> subroutine) or ON SIZE ERROR (another compiler generated subroutine)
>
> Well, I think the compiler can organize a more efficient ckeck than
> optimizing something with some sort of second guess. It could e.g.
> generate code to just check the most significant digits which would
> not fit in the destination field.

Yes, but it doesn't... It COULD do ANYTHING... but it doesn't. Besides, the
elegance of this solution is not predicated on the machine efficiency. If it
were, there would be no argument; you'd simply lose.

How could ANY compiler generate MORE code for Walter's simple statement than
for your complex arithmetic with ON SIZE ERROR (even if we remove the IF
NUMERIC from the discussion)?

You like ON SIZE ERROR because you feel it describes what is happening here.
In fact, it isn't and that isn't what ON SIZE ERROR was for; it was to apply
to results in arithmetic, not in move statements. You have contrived a
solution to use arithmetic JUST so you can use ON SIZE ERROR!

I respect your right to do it however you like, but you should recognise
that your selection of a solution (just like anyone else's) is based on your
OPINION. It is NOT a matter of commandment.

Diversity, in life and in COBOL, is a wondrous thing...<G>

>
> You advance very contradictory statements: the full numeric
> comparison is supposedly more efficient, because "it does not
> _preclude_ the compiler optimizing it", but telling the compiler
> directly, what the whole thing is about is less efficient?

There is no contradiction there. It is in your mind <G>. Your "telling the
compiler what the whole thing is about" is simply contriving to use a COBOL
construct that is not necessary, and could be considered inappropriate in
this context, especially when a much simpler solution exists.

>
> Well, I leave aside my generalization of attitudes of COBOL
> programmers ...
>
Yes, that is wise. Each of us has a right to code how we see fit. I could
maintain your solution or Walter's, without difficulty. I prefer Walter's...

> COBOL is a _compiled_ language, and is not assembler. Why not use
> BASIC if all those special features of COBOL are being avoided?
>
Oh Dear, that is a bit petulant, isn't it? Do you seriously think I avoid
using COBOL constructs in my code so I can make it more "Assembler or BASIC"
like?

I'll let you off, because you don't know me very well... <G>

Pete.

Pete Dashwood

2004-11-25, 8:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:gnmcq0hrsu1l0802cs2ksas5hlf926781r@
4ax.com...
> On 25 Nov 2004 15:06:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
>
>
> You're right. I've seen a good Cobol compiler do IF NUMERIC on an
> unsigned field with one in-line machine instruction (TRT on s/390).#

I expect more from you, Robert... <G>

Translate and Test instructions are certainly useful, but their OVERHEADS
are high. Anyway, that doesn't make Lueko's claim that there is
contradiction in my response correct, or that his ON SIZE ERROR is telling
the compiler what "the whole thing is all about". (Your statement appears to
agree with this.) See my response to Lueko.

>
>
> Programmers were once paid to help the machine. Some haven't learned
> that's now counter-productive.

If you are aiming that at me, you are wrong. The "special feature" he is
referring to is ON SIZE ERROR.
(How "special" is that? So complex that I would resort to Assembler-like
code in order to avoid it? Yep, my limited intellect really has trouble
grasping THAT concept...<G>. )

I like Walter's solution because:
1. There is less of it.
2. It is imaginative, and has not fallen into the obvious "COBOL think" idea
that this is about a SIZE ERROR.
3. It does not require contrived arithmetic, just so the ON SIZE ERROR
clause can be utilised.
4. It required some lateral thought to arrive at. I always admire that...

I have never suggested that my preference is based on anything other than
opinion, or that other solutions presented were "wrong".

However, it IS my opinion. I have seen nothing that would change it here
(certainly petulant statements about writing Assembler in COBOL so as to
avoid "special features", or ponderous announcements that "Some (presumably
including me <G> ) haven't learned " would not encourage me to change it...

This particular topic has used all the time I have allocated to it so I
won't be posting further on it. (Just in case you were hoping for an another
"infinite loops" thread... <G> )

Pete.

Lueko Willms

2004-11-26, 3:55 pm

.. On 26.11.04
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 30nb2cF326aveU1@uni-berlin.de
about Re: Need help with REDEFINES (I think)....

[color=darkred]

PD> So, why include IF NUMERIC in your sample if you believe that?

Because the original poster asked for it, and because Tom Morrison
explicitly said that it would be necessary.

[color=darkred]
PD> Not necessarily. And anyway, IMNSHO it should be in a separate
PD> tier...

Maybe. But the only little piece of the whole problem was the one
question on how to assign one value to another and how to cope with a
possible size error. I did not try to imagine a whole program around
it.

PD> How could ANY compiler generate MORE code for Walter's simple
PD> statement

i.e. this complex sequence:

*> SOLUTION A
MOVE source-field TO destination-field
IF NOT source-field = destination-field
THEN
*> do what one wants to happen on size error
*> among this, undo the value assignement
END-IF

PD> than for your complex arithmetic with ON SIZE ERROR (even
PD> if we remove the IF NUMERIC from the discussion)?

A simple assignment is not complex, especially not a "complex
arithmetic".

*> SOLUTION B
COMPUTE destination-field = source-field
ON SIZE ERROR
*> do what one wants to happen on size error
END-COMPUTE

PD> You like ON SIZE ERROR because you feel it describes what is
PD> happening here.

Exactly. And because my "feelings" fit the reality.

PD> In fact, it isn't and that isn't what ON SIZE ERROR
PD> was for; it was to apply to results in arithmetic,

Well, the problem being presented to this forum was an arithmetic
one: There was a value assignment of a numeric to be done, with the
possibilty that the value might be to large for the variable to be
assigned the new value.

PD> not in move statements.

Is the assignment of numeric variables free of any arithmetic? Is a
MOVE ZERO TO X
not an arithmetic value assignment?

PD> You have contrived a solution to use arithmetic

A simple value assignment, which is only performed, when it can be
done successfully (NOT ON SIZE ERROR), otherwise "destination-field"
remains unchanged.

PD> JUST so you can use ON SIZE ERROR!

Exactly, because the MOVE statement does not provide the ON SIZE
ERROR exception handling.

Solution A involves at least two arithmetic operations:
a) assignment of the value of "source-field" to "destination-field"
b) arithmetic comparison of both variables
c) any additional numerical operations in the case of a SIZE ERROR
(e.g. re-assigning a sensible value to "destination-field")

In addition, this needs to be explained in the source code, because
the purpose of this complex sequence is not obvious to everybody

PD> I respect your right to do it however you like, but you should
PD> recognise that your selection of a solution (just like anyone else's)
PD> is based on your OPINION.

Sure, and it is an informed opinion.

PD> It is NOT a matter of commandment.

Sure, anybody may write his or her programs as good or bad,
according to the individual capabilites and tastes. I just happen to
state what is best. OK, in my opinion. As long it doesn't affect me,
anybody may go any detour as pleases her or him. And I feel free to
indicate the shortest path.

PD> Diversity, in life and in COBOL, is a wondrous thing...<G>

Even in other programming languages ---

[color=darkred]

PD> There is no contradiction there. It is in your mind <G>. Your
PD> "telling the compiler what the whole thing is about" is simply
PD> contriving to use a COBOL construct that is not necessary, and could
PD> be considered inappropriate in this context, especially when a much
PD> simpler solution exists.

You do not seriously want to explain that it is simpler to wander
around by first assigning the value, even if the assignment may fail;
second do a numeric (arithmetic, if you prefer) comparison of the two
variables, and then possibly correct the assignment, instead of
instructing the compiler to do the assignment under condition that it
can be done successfully?

It makes me shake my head in disbelief.

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

Hinlänglicher Stoff zum Stillschweigen. -G.C.Lichtenberg

Robert Wagner

2004-11-26, 3:55 pm

On 26 Nov 2004 11:28:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

> *> SOLUTION B
> COMPUTE destination-field = source-field
> ON SIZE ERROR
> *> do what one wants to happen on size error
> END-COMPUTE
>
>
>PD> You like ON SIZE ERROR because you feel it describes what is
>PD> happening here.
>
> Exactly. And because my "feelings" fit the reality.
>
>PD> In fact, it isn't and that isn't what ON SIZE ERROR
>PD> was for; it was to apply to results in arithmetic,

>PD> JUST so you can use ON SIZE ERROR!
>
>
> Exactly, because the MOVE statement does not provide the ON SIZE
>ERROR exception handling.

We have the same situation with ROUNDED. One cannot say MOVE A TO
A-EDITED ROUNDED, he must say COMPUTE A-ROUNDED ROUNDED = A.
The COMPUTE is not doing arithmetic. We use COMPUTE "just so we can
use" ROUNDED.

What's the 'simple' alternative?

docdwarf@panix.com

2004-11-26, 3:55 pm

In article <4lfeq0t6s6kf701qap034a42lo3kbdg08c@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:

[snip]

>We have the same situation with ROUNDED. One cannot say MOVE A TO
>A-EDITED ROUNDED, he must say COMPUTE A-ROUNDED ROUNDED = A.
>The COMPUTE is not doing arithmetic.

Mr Wagner, if 'rounding' is an arithmetic function then the COMPUTE most
certainly would appear to be 'doing arithmetic'.

DD

Walter Murray

2004-11-27, 3:55 am

"Lueko Willms" <l.willms@jpberlin.de> wrote:

> In addition, this needs to be explained in the source code, because
> the purpose of this complex sequence is not obvious to everybody

This was in response to my suggested solution to the question of how to
detect truncation when the domain of a receiving item is a subset of that of
the sending item.

My suggestion was: MOVE A TO B, IF A NOT = B <error code here>

I suggested it because I thought it was novel, was perfectly legal COBOL,
and had a certain elegance that some might appreciate. From the dialog it
stimulated, I was right. (May I modestly suggest that if this becomes a
common COBOL idiom, it should thereafter be known as "Murray's device." :-)

When I wrote it, however, I was not at all sure that I would use it in the
real world. I just didn't like any of the obvious solutions, so I was
thinking "outside the box," I guess.

Trying to do it with redefinition of the data items wasn't the right
approach, as I think everyone agreed.

Using an ADD of 0, in order to use a SIZE ERROR phrase, seems contrived.

Using COMPUTE to do a move never seemed right to me, probably because I have
a longstanding dislike for COMPUTE statements.

I suppose I'd most likely go with IF A > 9999999.99 <error code here> ELSE
MOVE A TO B. The intent is absolutely clear to everyone. It just irks me
seeing that literal in the Procedure Division, and giving it a name and
putting it in Working-Storage would be even worse. Furthermore, if the
description of B changes, there is a risk that the literal might not be
updated.

So I don't know what I would do. I certainly don't make it a practice to
write code that has to be explained with comments because the typical
programmer is likely to be puzzled by it. On the other hand, I do
occasionally write code that might push the limits of some programmers'
knowledge or experience. Just as I enjoy reading essayists who sometimes
use words I have to stop and look up, I think a professional programmer
shouldn't mind occasionally seeing a new technique. One reader thinks,
"That's neat! I wish I had written it." And another thinks, "How ugly!
What, is he trying to prove how clever he is?" You just can't please
everybody.

Walter

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Lueko Willms

2004-11-27, 8:55 am

.. On 26.11.04
wrote wmurray@midtown.net (Walter Murray)
on /COMP/LANG/COBOL
in 41a7f691_4@127.0.0.1
about Re: Need help with REDEFINES (I think)....

WM> This was in response to my suggested solution to the question of how
WM> to detect truncation when the domain of a receiving item is a subset
WM> of that of the sending item.
WM>
WM> My suggestion was: MOVE A TO B, IF A NOT = B <error code here>

Your solution is certainly the second best after using the
facilities provided by COBOL itself for such purposes

WM> I suggested it because I thought it was novel, was perfectly legal
WM> COBOL, and had a certain elegance that some might appreciate.

Sure, it is certainly legal COBOL, but I don't see it neither as
"elegant" nor "novel", when one has to add a comment "I do this to
avoid COBOL's own ON SIZE ERROR handling".

Besides, depending on the specifications of the larger problem of
which we have seen only a little detail, one might have to store the
original value of the destination-variable in a temporary place to
restore it, should the SIZE ERROR exception hit. This is not the case
with COBOL's own facility for this problem, i.e. the ON SIZE ERROR
exception: the value of the destination-variable remains unchanged,
provided that the compiler is standard-compliant.

WM> Using COMPUTE to do a move never seemed right to me, probably
WM> because I have a longstanding dislike for COMPUTE statements.

But you should not let your personal emotions get in your way,
preventing you to use the COBOL language to its full potential.

COBOL as such is certainly quite verbose, but many COBOL programmers
add a lot of unnecessesary verbosity to it. "Just to confuse the
Russians", as my colleagues of those good ole dayse liked to joke
(DocDwarf, your cue!).

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

Wir wohnen in Göttingen in Scheiterhaufen, die mit Türen und Fenstern versehen sind. -G.C.Lichtenberg

docdwarf@panix.com

2004-11-27, 3:55 pm

In article <41a7f691_4@127.0.0.1>, Walter Murray <wmurray@midtown.net> wrote:
>"Lueko Willms" <l.willms@jpberlin.de> wrote:
>

[snip]
[color=darkred]
>I suggested it because I thought it was novel, was perfectly legal COBOL,
>and had a certain elegance that some might appreciate.

[snip]

>Using COMPUTE to do a move never seemed right to me, probably because I have
>a longstanding dislike for COMPUTE statements.
>
>I suppose I'd most likely go with IF A > 9999999.99 <error code here> ELSE
>MOVE A TO B. The intent is absolutely clear to everyone. It just irks me
>seeing that literal in the Procedure Division, and giving it a name and
>putting it in Working-Storage would be even worse. Furthermore, if the
>description of B changes, there is a risk that the literal might not be
>updated.

[snip]

>I certainly don't make it a practice to
>write code that has to be explained with comments because the typical
>programmer is likely to be puzzled by it. On the other hand, I do
>occasionally write code that might push the limits of some programmers'
>knowledge or experience.

[snip]

>One reader thinks,
>"That's neat! I wish I had written it." And another thinks, "How ugly!
>What, is he trying to prove how clever he is?" You just can't please
>everybody.

Been doing this for a few years, eh, Mr Murray?

DD

docdwarf@panix.com

2004-11-27, 3:55 pm

In article <9Lek8squflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:

[snip]

> COBOL as such is certainly quite verbose, but many COBOL programmers
>add a lot of unnecessesary verbosity to it. "Just to confuse the
>Russians", as my colleagues of those good ole dayse liked to joke
>(DocDwarf, your cue!).

zzzzZZZZZzzzz... zzzaaaAAWWWWWwwwwww.... huh? whuh? Oh, I'm sorry, I was
just... resting my eyes, yes, did you want something?

DD

Pete Dashwood

2004-11-27, 3:55 pm

Jeez Jerry,

you're having a bad w

Pete Dashwood

2004-11-27, 3:55 pm

Robert Wagner

2004-11-29, 3:55 pm

On Fri, 26 Nov 2004 19:36:36 -0800, "Walter Murray"
<wmurray@midtown.net> wrote:

>I suppose I'd most likely go with IF A > 9999999.99 <error code here> ELSE
>MOVE A TO B. The intent is absolutely clear to everyone. It just irks me
>seeing that literal in the Procedure Division, and giving it a name and
>putting it in Working-Storage would be even worse. Furthermore, if the
>description of B changes, there is a risk that the literal might not be
>updated.

The limiting factor is 10**(length(B)-2).
In this case: 10**7 = 10,000,000.
For some stupid reason, Cobol exponentiation is limited to 1-4, but we
can do exponentiation with the LOG and EXP functions like so:
A**B = EXP(LOG(A) * B)
Cobol also has base-10 versions. Knowing that LOG10(10) = 1, we can
dispense with the inner LOG. My solution is:

if A less than EXP10(LENGTH(B)-2)
move A to B
else
display 'A out of range: ' A
end-if

Pete Dashwood

2004-11-29, 3:55 pm

Positively last post on this from me, so I'll make sure I say everything I
want to here <G>

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:4lfeq0t6s6kf701qap034a42lo3kbdg08c@
4ax.com...
> On 26 Nov 2004 11:28:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
>

It doesn't need to. The rules of MOVE are carefully defined. If you do a
MOVE you CANNOT get a SIZE ERROR. That is WHY there is no SIZE ERROR
provided for MOVE. What you get is truncation or space/zero fill. It is a
known, documented phenomenon that works according to clear rules. If you are
a COBOL programmer you should understand it.

There is no ROUNDED provided for MOVE, for exactly the same reason.

MOVE ing data is different from doing ARITHMETIC on data. (Did I really need
to say that? <G> )

Another way to state this is:

"COBOL accommodates both data manipulation and arithmetic, with VERBS and
CLAUSES that are appropriate to each."
[color=darkred]
>
> We have the same situation with ROUNDED. One cannot say MOVE A TO
> A-EDITED ROUNDED, he must say COMPUTE A-ROUNDED ROUNDED = A.
> The COMPUTE is not doing arithmetic. We use COMPUTE "just so we can
> use" ROUNDED.
>
Yes, and I respect your right to do that. But don't pretend it is a MOVE
statement. The COMPUTE above is CERTAINLY doing arithmetic, even though you
say it isn't.

Neither the ROUNDED nor ON SIZE ERROR clauses are necessary in COBOL arithme
tic. But that doesn't mean you shouldn't use them. The trick is to
understand where they are appropriate, then choose to use them if you want.

If you set the size of arithmetic operands correctly, it is impossible to
get a size error.

You can easily (and efficiently) round any COBOL arithmetic field that
contains a decimal, by adding .5 to it. (And I have worked on one site where
this was the standard and ROUNDED was banned.)
OK, here's the code snippets:

01 field-to-be-rounded.
12 integer-part pic 9(5).
12 decimal-part pic 99.
01 arithmetic-field REDEFINES field-to-be-rounded pic 9(5)v99.

sample 1: Compute rounded-output ROUNDED = arithmetic-field.

sample 2: add .5 to arithmetic-field
move integer-part to rounded-output.

The results will be the same. The only difference is in the generated code
and many people don't care about that these days. (I'm one...)

Sample1 is easy to write and it states what is happening quite elegantly. It
makes the whole exercise part of arithmetic.

Sample 2 separates the arithmetic from the data manipulation and for some
people this is "purer". (On most platforms it probably generates simpler
code, too.)

So the choice will depend on your particular philosophy to COBOL. I find
both of the above quite acceptable, on different grounds.

In the particular case we have been arguing, the real issue is regarding
data manipulation. (It just happens to be a numeric field.)

I therefore favour a data manipulation solution to it, rather than an
arithmetic one. That is why I believe the introduction of ON SIZE ERROR is
simply inappropriate. There is no SIZE ERROR involved. It is a truncation.
But that, (and I have been careful to say so throughout the discussion) is
simply MY opinion. There is nothing wrong with any of the solutions that
were presented, provided they work.

COBOL programmers often use ROUNDED because it is easier to write one
arithmetic statement with ROUNDED in it, than it is to do a separate add for
rounding. I see nothing wrong with that, but let's realize that it is an
accommodation to the programmer and NOT a necessity in the language because
there is "no other way" of doing it.

Personally, I don't use ON SIZE ERROR (I DO use ROUNDED...) because I have
never needed to. (However, I do fully understand its use, and have no
difficulty maintaining code that DOES use it.)

> What's the 'simple' alternative?
>
>
Add .5 for rounding.

Be aware of the difference between arithmetic and data manipulation.

Pete.

William M. Klein

2004-11-29, 3:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:3cohq0thqd7gfn5v7ped8qpqoid45dj44q@
4ax.com...
> On Fri, 26 Nov 2004 19:36:36 -0800, "Walter Murray"
> <wmurray@midtown.net> wrote:
>
<snip>
> For some stupid reason, Cobol exponentiation is limited to 1-4, but ...
....

Robert,
Are you confusing "portable results" when ('02 Standard) ARITHMETIC IS
STANDARD is specified with what is allowed and supported? To be best of my
knowledge no previous or current (or propssed) Standard has limited
eponentiation in any way. It *is* true that the results (when STANDARD
ARITHMETIC is specified) are only predictable with 1-4 - but that just means
with larger eponents, the results are the same as if NATIVE ARITHMETIC were
in effect.

docdwarf@panix.com

2004-11-29, 3:55 pm

In article <3cohq0thqd7gfn5v7ped8qpqoid45dj44q@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:

[snip]

>if A less than EXP10(LENGTH(B)-2)
> move A to B
>else
> display 'A out of range: ' A
>end-if

Mr Wagner, you might want to compare this bit of what appears to be 'Look,
Ma, I'm a *programmer*!' code to Mr Murray's original suggestion of:

MOVE A TO B, IF A NOT = B <error code here>

.... on second thought... you might not want to.

DD

Robert Wagner

2004-11-29, 3:55 pm

Pete Dashwood

2004-11-29, 3:55 pm

Joe Zitzelberger

2004-11-29, 3:55 pm

Robert Wagner

2004-11-29, 3:55 pm

James J. Gavan

2004-11-29, 3:55 pm

Walter Murray wrote:

>This was in response to my suggested solution to the question of how to
>detect truncation when the domain of a receiving item is a subset of that of
>the sending item.
>
>My suggestion was: MOVE A TO B, IF A NOT = B <error code here>
>
>I suggested it because I thought it was novel, was perfectly legal COBOL,
>and had a certain elegance that some might appreciate. From the dialog it
>stimulated, I was right. (May I modestly suggest that if this becomes a
>common COBOL idiom, it should thereafter be known as "Murray's device." :-)
>
>
>
Actually I'm in the throes of writing about Exception Handling, and as
well as file-status, was looking for an obvious like 'Non numeric data
error'. Be assured if I use your above example to get the Exception I
will duly acknowledge "Murray's device" :-)

Jimmy

Robert Wagner

2004-11-29, 3:55 pm

On Sat, 27 Nov 2004 22:42:20 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:3cohq0thqd7gfn5v7ped8qpqoid45dj44q@
4ax.com...
><snip>
>...
>
>Robert,
> Are you confusing "portable results" when ('02 Standard) ARITHMETIC IS
>STANDARD is specified with what is allowed and supported? To be best of my
>knowledge no previous or current (or propssed) Standard has limited
>eponentiation in any way. It *is* true that the results (when STANDARD
>ARITHMETIC is specified) are only predictable with 1-4 - but that just means
>with larger exponents, the results are the same as if NATIVE ARITHMETIC were
>in effect.

Whoops. The standard goes on and on giving the result for 1, 2, 3 and
4 in elaborate detail. Then one sentence says results for other values
are implementor defined. I missed that sentence. Sorry.

Pete Dashwood

2004-11-29, 3:55 pm

, I wish I'd thought of it!)

Pete.

Robert Wagner

2004-11-29, 3:55 pm

On 27 Nov 2004 20:49:35 -0500, docdwarf@panix.com wrote:

>In article <3cohq0thqd7gfn5v7ped8qpqoid45dj44q@4ax.com>,
>Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>[snip]
>
>
>Mr Wagner, you might want to compare this bit of what appears to be 'Look,
>Ma, I'm a *programmer*!' code to Mr Murray's original suggestion of:
>
>MOVE A TO B, IF A NOT = B <error code here>
>
>... on second thought... you might not want to.

You didn't object to Mr. Murray's:

if A not greater than 9999999.99

My code says the same thing .. without the hidden linkage between
picture and literal. With a decent compiler, it will run as fast too.
The optimizer will recognize that length(B) is a constant and do the
EXP10 function at compile time rather than execution time. The result
will be:

if A less than 10000000

If I'd written it that way, you wouldn't have objected. Ya got
something against mathematical abstraction? If so, spit it out.

Robert Wagner

2004-11-29, 3:55 pm

On Sun, 28 Nov 2004 01:55:22 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>You can easily (and efficiently) round any COBOL arithmetic field that
>contains a decimal, by adding .5 to it. (And I have worked on one site where
>this was the standard and ROUNDED was banned.)
>OK, here's the code snippets:
>
>01 field-to-be-rounded.
> 12 integer-part pic 9(5).
> 12 decimal-part pic 99.
>01 arithmetic-field REDEFINES field-to-be-rounded pic 9(5)v99.
>
>sample 1: Compute rounded-output ROUNDED = arithmetic-field.
>
>sample 2: add .5 to arithmetic-field
> move integer-part to rounded-output.
>
>The results will be the same.

Only for positive numbers rounded to an integer. In that case, you
don't need the redefinition. You can do the same with:

add .5 arithmetic-field giving rounded-output
-or-
compute rounded-output = arithmeteic-field + .5

If the number is negative, rounded-output will show the wrong answer.

If someone changes the receiving field, say from units to thousands,
and forgets to change the rounding factor, the result will be wrong.

>In the particular case we have been arguing, the real issue is regarding
>data manipulation. (It just happens to be a numeric field.)

The phrase "data manipulation" does not appear in the Cobol standard.

[color=darkred]
>Add .5 for rounding.

Which is simpler?

1. compute rounded-output =
arithmeteic-field + (.5 * sign(arithmetic-field))

2. compute rounded-output = arithmetic-field rounded

Robert Wagner

2004-11-29, 3:55 pm

On Sun, 28 Nov 2004 03:05:40 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Actually I'm in the throes of writing about Exception Handling, and as
>well as file-status, was looking for an obvious like 'Non numeric data
>error'. Be assured if I use your above example to get the Exception I
>will duly acknowledge "Murray's device" :-)

Here's one for your consideration (and I don't ask for credit).
Suppose you read this record from a file:

01 input-record.
05 A binary pic s9(05).
05 B packed-decimal pic s9(06).
05 C pic s9(07).

Suppose all three data fields contained 1234567. The program tests:

if A not numeric
display 'A out of range'
end-if
if B not numeric
display 'B out of range'
end-if
if C not numeric
display 'C out of range'
end-if

Which displays would appear?

1. None. The data are all numeric.
2. All three. They don't have signs.
3. A and B. They're out of range.
4. B. Everything's valid in binary.

Pete Dashwood

2004-11-29, 3:55 pm

Richard

2004-11-29, 3:55 pm

Robert Wagner <spamblocker-robert@wagner.net> wrote

> The limiting factor is 10**(length(B)-2).

"""The LENGTH function returns an integer equal to the length of the
argument in alphanumeric character positions"""

The result of your calculation is dependent on there being exactly 2
decimal places and the numeric digits occupying exactly the same space
as alphanumeric character positions.

It doesn't seem particularly general.

Robert Wagner

2004-11-29, 3:55 pm

On 27 Nov 2004 21:12:43 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>
>"""The LENGTH function returns an integer equal to the length of the
>argument in alphanumeric character positions"""
>
>The result of your calculation is dependent on there being exactly 2
>decimal places and the numeric digits occupying exactly the same space
>as alphanumeric character positions.
>
>It doesn't seem particularly general.

You're right. I'd prefer a function that returned the number of digits
left of decimal. Pragmatically, this is the best available.

JerryMouse

2004-11-29, 3:55 pm

Pete Dashwood wrote:
> Jeez Jerry,
>
> you're having a bad w

Tom Morrison

2004-11-29, 3:55 pm

Richard

2004-11-29, 3:55 pm

Pete Dashwood

2004-11-29, 3:55 pm

Lueko Willms

2004-11-29, 3:55 pm

Lueko Willms

2004-11-29, 3:55 pm

docdwarf@panix.com

2004-11-29, 3:55 pm

In article <8ijiq0helgmisqpu2389q88143ps8bloju@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 27 Nov 2004 20:49:35 -0500, docdwarf@panix.com wrote:
>
>
>You didn't object to Mr. Murray's:
>
>if A not greater than 9999999.99

That seems to be a bit... juvenile for a man of your years, Mr Wagner, and
right up there with the Brooklyn Bridge defenses you have so readily
wielded; Mr Murray supplied his own objection to that possibility by
stating -

--begin quoted text:

I suppose I'd most likely go with IF A > 9999999.99 <error code here> ELSE
MOVE A TO B. The intent is absolutely clear to everyone. It just irks me
seeing that literal in the Procedure Division, and giving it a name and
putting it in Working-Storage would be even worse.

--end quoted text

.... and I replied to that as part of my posting:

<http://groups.google.com/groups?sel...m&output=gplain>

>
>My code says the same thing .. without the hidden linkage between
>picture and literal.

Reaching around your head with your left hand to scratch your right ear
accomplishes the same task as reaching up directly with your right... and
saves wear and tear on what is (most often) the most-used hand, as well.

DD

William M. Klein

2004-11-29, 3:55 pm

(alll previous text deleted ... because this is a "new" approach)

The following is a technique available with the '02 Standard that does NOT
require exception handling to determine if a sending (numeric-fiedl) has a
value too larger for a receiving value. I think (but am not postive) that
at least some vendors have already implemented the HIGHEST-ALGEBRAIC and
LOWEST-ALBEBRAIC intrincis functions.

Given:
01 Sending-Field *> any numeric picture and/or usage
02 Receiving-Field *> any numeric piccture and/or usage

If Highest-Algebraic (Receving-Field) < Sending-Field
Display "truncation would occur"
Else
Move Sending-Field to Receiving-Field
End-IF

(This also uses the fact that the word "FUNCITON" is optional in the '02
Standard - if the repository is set correctly).

This code would continue to work - even if the PICTURE and/or USAGE of
either the sending or receiving field were changed during maintenance.. I
also beleive that it is fairly "self-documenting"

Robert Wagner

2004-11-29, 3:55 pm

On 28 Nov 2004 11:34:32 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>
>
>
>It may be the best that _you_ can think of, but it is trivial to see
>improvements, such as doing the calculation once into a max sized
>variable and saving all those recalculations.
>
>It is still a poor piece of code when you could iterate a max value:
>
> MOVE -1 TO Max-B
> PERFORM VARYING Exponent FROM ZERO BY 1
> UNTIL Max-B >= ZERO
>
> COMPUTE B = EXP10(Exponent)
> ON SIZE ERROR
> COMPUTE Max-B = EXP10(Exponent)
> END-COMPUTE
> END-PERFORM
>
>Then compare to Max-B.
>
>This has the advantage of being _actually_ decimal point independent
>and also is more independent of field type.
>
>Even better would be to forget the overly 'clever' use of EXP10 and
>just ADD 1 until SIZE ERROR and that copes with binary fields that
>allow use of all bits.

Bill Klein found the right answer in HIGHEST-ALGEBRAIC. Unfortunately,
neither Fujitsu nor Micro Focus have it.

I do like your solution better than mine. I'd improve it by making the
search divisional:

move 1 to max-b
move 1000000 to step
perform until step equal to 1
divide 2 into step
move max-b to b
perform until b equal to zero
add step to b
not on size error move b to max-b
on size error move zero to b
end-perform
end-perform

Lueko Willms

2004-11-29, 3:55 pm

.. On 28.11.04
wrote wmklein@nospam.netcom.com (William M. Klein)
on /COMP/LANG/COBOL
in Klrqd.5279399$ic1.491584@news.easynews.com
about Re: Need help with REDEFINES (I think)....

WMK> The following is a technique available with the '02 Standard that
WMK> does NOT require exception handling to determine if a sending
WMK> (numeric-fiedl) has a value too larger for a receiving value.

WMK> Given:
WMK> 01 Sending-Field *> any numeric picture and/or usage
WMK> 02 Receiving-Field *> any numeric piccture and/or usage
WMK>
WMK> If Highest-Algebraic (Receving-Field) < Sending-Field
WMK> Display "truncation would occur"
WMK> Else
WMK> Move Sending-Field to Receiving-Field
WMK> End-IF

Sounds good. The advantage ist that such a condition can be
combined with any other condition to form a combined boolean
expression, while the old standard COBOL exceptional conditions had to
stand on their own.

So one could write, to use the above example:

If (Sending-Field NOT NUMERIC)
OR (Highest-Algebraic (Receiving-Field) < Sending-Field
Display "Is no good"
Else
Move Sending-Field to Receiving-Field
End-IF

whereas using the ON SIZE ERROR phrase would require to separate both
parts of the one boolean expression, like I wrote short time ago:

IF Sending-Field MUMERIC
COMPUTE Receiving-Filed = Sending-Field
ON SIZE ERROR
DISPLAY "Truncation would occur"
NOT SIZE ERROR
CONTINUE
END-COMPUTE
ELSE
DISPLAY "Is no good"
END-IF

Yours,
Lüko Willms