Prev: Cobol history question -- lawsuit against standards committee
Next: Dumb "figurative constant" rules
From: Chuck Stevens on 24 May 2005 15:10
Sorry, I got that backward. Last paragraph, for

<<In the MCP COBOL85 implementation, comparison of FUNCTION INTEGER-OF-DATE
(FUNCTION DATE-OF-INTEGER (A-DATE)) against A-DATE will fail if A-DATE is
nonzero and not a valid date.>>

please read

> In the MCP COBOL85 implementation, comparison of FUNCTION DATE-OF-INTEGER
(FUNCTION INTEGER-OF-DATE (A-DATE)) against A-DATE will fail if A-DATE is
nonzero and not a valid date.

-Chuck Stevens


From: Howard Brazee on 24 May 2005 15:22

On 24-May-2005, "Chuck Stevens" <charles.stevens(a)unisys.com> wrote:

> Note that Unisys MCP COBOL85 gives a zero response to an INTEGER-OF-DATE
> call in which any part of the argument is incorrect -- for example, 20050532
> and 20051324 will both return zero.

IMHO, the biggest weakness in the CoBOL language is that it was not designed for
easy standard error handling. This particular solution is easy, but doesn't
work for all function calls. ON ERROR would have been a better design - as
a standard.
From: Chuck Stevens on 24 May 2005 15:54
I'm not convinced ON ERROR is necessarily the best approach here, or for
that matter in general, particularly given the ability to "nest" function
calls.

The '02 standard includes exception handling (for this and in general) in a
way that, in my opinion, doesn't invalidate existing programs and allows
their enhancement to catch such problems. Lobby your vendors!

-Chuck Stevens

"Howard Brazee" <howard(a)brazee.net> wrote in message
news:d6vutt$3fp$1(a)peabody.colorado.edu...
>
> On 24-May-2005, "Chuck Stevens" <charles.stevens(a)unisys.com> wrote:
>
> > Note that Unisys MCP COBOL85 gives a zero response to an INTEGER-OF-DATE
> > call in which any part of the argument is incorrect -- for example,
20050532
> > and 20051324 will both return zero.
>
> IMHO, the biggest weakness in the CoBOL language is that it was not
designed for
> easy standard error handling. This particular solution is easy, but
doesn't
> work for all function calls. ON ERROR would have been a better
design - as
> a standard.


From: Howard Brazee on 24 May 2005 16:15

On 24-May-2005, "Chuck Stevens" <charles.stevens(a)unisys.com> wrote:

> I'm not convinced ON ERROR is necessarily the best approach here, or for
> that matter in general, particularly given the ability to "nest" function
> calls.
>
> The '02 standard includes exception handling (for this and in general) in a
> way that, in my opinion, doesn't invalidate existing programs and allows
> their enhancement to catch such problems. Lobby your vendors!

I didn't say "best", I said "better". It would have worked with the original
design, but would have had to have been enhanced over time.
From: HeyBub on 24 May 2005 21:23
Walter Murray wrote:
> What happens in COBOL if you reference the INTEGER-OF-DATE function
> and
> specify an invalid date for the argument?
>
> The 1985 COBOL standard says that anything can happen ("the result of
> such a reference is undefined").
>
> I would be interested to know the results for various compilers. The
> question came up during a migration.
>
> Thanks.
>
> Walter

You should test it in your world. You may have to:

If MYDATE-YYYY NUMERIC
If MYDATE-YYYY > 1800 And < 2100
...
COMPUTE MYDATE-INT = FUNCTION INTEGER-OF-DATE(MYDATE)

Our compiler (Fujitsu) goes nuts when an invalid field is passed to FUNCTION
NUMVAL. For those instances where we can't guarantee the integrity of the
field, we're oblidged to test each character before we hand the field to
NUMVAL.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Cobol history question -- lawsuit against standards committee
Next: Dumb "figurative constant" rules