Cobol - Passing an invalid date to INTEGER-OF-DATE

Author

Passing an invalid date to INTEGER-OF-DATE

Walter Murray

2005-05-24, 8:55 am

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

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

Chuck Stevens

2005-05-24, 3:55 pm

Good to see you participating, Walter!

Unisys MCP COBOL85 gives a zero result, the same as it would give for the
(out-of-bounds) date of 12/31/1600.

For an ISO/IEC 1989:2002-compliant compiler, the user can >>TURN EC-ALL
CHECKING ON, and in that instance, a bad argument value to INTEGER-OF-DATE
woud cause the EC-ARGUMENT-FUNCTION exception condition to be set to exist,
and if no actual handling (generic or specific to the exception) were
provided, the program would be discontinued.

Note that according to the ANSI X3.23-1985 glossary, "integer" values do not
include zero unless the rules for the particular construct so state, which
they don't for either INTEGER-OF-DATE or for DATE-OF-INTEGER.

-Chuck Stevens

"Walter Murray" <wmurray@midtown.net> wrote in message
news:4292ab55$1_2@spool9-west.superfeed.net...
> 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
>
>
>
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption
=----

William M. Klein

2005-05-24, 8:55 pm

Walter,
I haven't tried it recently, but I think that IBM mainframes give a run-time
error and terminate. I know that when you do "similar" things with their
callable services, you get something like the message at:

http://publibz.boulder.ibm.com/cgi-.../ceea9150/1.107

P.S. Usual "reminder" the Intrinsic Function module was OPTIONAL in the '89
(not '85) ANSI/ISO Standard (even at the high level) - but was REQUIRED by the
FIPS High-Level specification.

There was NO requirement in any of these as to what happened with invalid
arguments.

--
Bill Klein
wmklein <at> ix.netcom.com
"Walter Murray" <wmurray@midtown.net> wrote in message
news:4292ab55$1_2@spool9-west.superfeed.net...
> 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
>
>
>
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
> News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
> Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption =----

William M. Klein

2005-05-24, 8:55 pm

I just found the correct run-time message. See:

http://publibz.boulder.ibm.com/cgi-...S/ceea9150/7.87
and
http://publibz.boulder.ibm.com/cgi-...S/ceea9150/7.88

In "IBM-ese" there are a S-level messages and results in the programming
"ABENDing".

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:omKke.493207$QY2.208777@fe01.news.easynews.com...
> Walter,
> I haven't tried it recently, but I think that IBM mainframes give a run-time
> error and terminate. I know that when you do "similar" things with their
> callable services, you get something like the message at:
>
> http://publibz.boulder.ibm.com/cgi-.../ceea9150/1.107
>
> P.S. Usual "reminder" the Intrinsic Function module was OPTIONAL in the '89
> (not '85) ANSI/ISO Standard (even at the high level) - but was REQUIRED by the
> FIPS High-Level specification.
>
> There was NO requirement in any of these as to what happened with invalid
> arguments.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Walter Murray" <wmurray@midtown.net> wrote in message
> news:4292ab55$1_2@spool9-west.superfeed.net...
>
>

Chuck Stevens

2005-05-24, 8:55 pm

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.

It's not clear from these references whether IBM COBOL rejects invalid dates
larger than 16010101 and smaller than 99991231 as arguments to this
function.

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.

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:4pKke.165992$gX5.85376@fe04.news.easynews.com...
> I just found the correct run-time message. See:
>
> http://publibz.boulder.ibm.com/cgi-...S/ceea9150/7.87
> and
> http://publibz.boulder.ibm.com/cgi-...S/ceea9150/7.88
>
>
> In "IBM-ese" there are a S-level messages and results in the programming
> "ABENDing".
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:omKke.493207$QY2.208777@fe01.news.easynews.com...
run-time[color=darkred]
their[color=darkred]
http://publibz.boulder.ibm.com/cgi-.../ceea9150/1.107[color=darkred]
'89[color=darkred]
by the[color=darkred]
invalid[color=darkred]
such a[color=darkred]
120,000+[color=darkred]
=----[color=darkred]
>
>

Chuck Stevens

2005-05-24, 8:55 pm

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

Howard Brazee

2005-05-24, 8:55 pm

On 24-May-2005, "Chuck Stevens" <charles.stevens@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.

Chuck Stevens

2005-05-24, 8:55 pm

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@brazee.net> wrote in message
news:d6vutt$3fp$1@peabody.colorado.edu...
>
> On 24-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
20050532[color=darkred]
>
> 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.

Howard Brazee

2005-05-24, 8:55 pm

On 24-May-2005, "Chuck Stevens" <charles.stevens@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.

HeyBub

2005-05-25, 3:55 am

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.

Walter Murray

2005-05-25, 3:55 am

"HeyBub" wrote:
> Walter Murray wrote:
[color=darkred]
> You should test it in your world.

In my world (HP COBOL II/iX), you get a run-time abort, unless you specify
an ON SIZE ERROR phrase.

Walter

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

Chuck Stevens

2005-05-25, 3:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:1197krtk63752dd@news.supernews.com...

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

Perhaps that's one of the reasons the current standard includes the
functions TEST-NUMVAL and TEST-NUMVAL-C! ;-)

-Chuck Stevens

Howard Brazee

2005-05-28, 8:55 am

William M. Klein

2005-05-30, 3:55 am

Sponsored Links