accept from date 
Author Message
 accept from date

Hello:
I was coding a program today using accept ws-date from date,
and I noticed that it seems there isn't a century field yet,
For example the year 1999 March 1 will be:

990301

YYMMDD.

Is there an ACCEPT in the works for COBOL standard that will add a century?

Otherwise the year 2000 March 1 will be
000301 which can cause unintended results in date range comparisons....

Chris Mason
"The Unknown COBOL Programmer"
The opinions expressed are mine, not my Employers.

LMSC5:  Tons of Beautiful Big Blue Iron...



Tue, 18 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

>Hello:
>I was coding a program today using accept ws-date from date,
>and I noticed that it seems there isn't a century field yet,
>For example the year 1999 March 1 will be:

>990301

>YYMMDD.

>Is there an ACCEPT in the works for COBOL standard that will add a
century?

>Otherwise the year 2000 March 1 will be
>000301 which can cause unintended results in date range comparisons....

No.  Use the intrinsic function CURRENT-DATE.  ACCEPT will
not be changed because of compatibility problems and it is
the wrong way to do such things anyhow.

Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
Project Editor, 1997 ISO COBOL Standard
Moderator, COBOL Conference, Bix


No clever quotes here



Tue, 18 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

>Hello:
>I was coding a program today using accept ws-date from date,
>and I noticed that it seems there isn't a century field yet,
>For example the year 1999 March 1 will be:
>990301
>YYMMDD.
>Is there an ACCEPT in the works for COBOL standard that will add a century?
>Otherwise the year 2000 March 1 will be
>000301 which can cause unintended results in date range comparisons....

When I first started writing COBOL (in high school, about 16 or 17 years
ago, no less), I realized that century wasn't provided and just added a
century field and preloaded it with "19" but made it such that it could
easily be removed in the future.

--
---------------------
"If a man appears out of step with those about him, then perhaps it is
because he marches to the beat of a different drummer." -Thoreau
---------------------



Wed, 19 Nov 1997 03:00:00 GMT  
 accept from date
Acucobol already has this capability.  You implement with a
compile time option, -Zy.  All you have to do to accomodate
this is to make your ws-date field a pic 9(8).  


Mon, 24 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

>Acucobol already has this capability.  You implement with a
>compile time option, -Zy.  All you have to do to accomodate
>this is to make your ws-date field a pic 9(8).  

This is exactly the wrong way to do it.  Acucobol also has the
intrinsic functions.  Use the CURRENT-DATE function and reference
modification to pick off the date.  Like the following:

    MOVE FUNCTION CURRENT-DATE (1:8) TO ws-date

The ACCEPT solution is a kludge, not-portable, non-standard, and so on.  
The fundtion is not a kludge, is portable, and is standard.

Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
Project Editor, 1997 ISO COBOL Standard
Moderator, COBOL Conference, Bix


No clever quotes here



Tue, 25 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

>Acucobol already has this capability.  You implement with a
>compile time option, -Zy.  All you have to do to accomodate
>this is to make your ws-date field a pic 9(8).  

This is exactly the wrong way to do it.  Acucobol also has the
intrinsic functions.  Use the CURRENT-DATE function and reference
modification to pick off the date.  Like the following:

    MOVE FUNCTION CURRENT-DATE (1:8) TO ws-date

The ACCEPT solution is a kludge, not-portable, non-standard, and so on.  
The fundtion is not a kludge, is portable, and is standard.

Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
Project Editor, 1997 ISO COBOL Standard
Moderator, COBOL Conference, Bix


No clever quotes here



Tue, 25 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

>intrinsic functions.  Use the CURRENT-DATE function and reference
>modification to pick off the date.  Like the following:

>    MOVE FUNCTION CURRENT-DATE (1:8) TO ws-date

Well, does IBM COBOL II contain these "portable" functions?
I don't see it in my IBM COBOL II release 3 manual...

How about Tandem?

How many companies are going to supply this with their compiler?

I guess I'm missing something.  What was it OK to accept a date from
a register as in
ACCEPT ws-date from DATE
for the last twenty years, and now when a person asks if it is possible
to add another register with two more digits for century
it is "kludgy" and nonportable?

In my humble, no one cares opinion, the function concept would be
better served with a syntax such as:

CALL FUNCTION CURRENT-DATE USING WS-DATE-FIELD.

After all, subroutines like this are analogous to functions...

Chris Mason
"The Unknown COBOL Programmer"
The opinions expressed are mine, not my Employers.

LMSC5:  Tons of Beautiful Big Blue Iron...



Fri, 28 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

>You wrote in part:

>>The ACCEPT solution is a kludge, not-portable, non-standard, and so on.
>>The fundtion is not a kludge, is portable, and is standard.

>Since Acucobol is itself portable to over 750 different platforms, I
really
>think that part of
>it is a mute(sp?) point.  Acucobol also has ACCEPT DATE FROM CENTURY-DATE

It is not portable from one implementation to another.  Also, why fancy up
ACCEPT when the function is 10 times better (more flexible, is completely
standard and works on all conforming implementations, and so on).

Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
Project Editor, 1997 ISO COBOL Standard
Moderator, COBOL Conference, Bix


No clever quotes here



Sat, 29 Nov 1997 03:00:00 GMT  
 accept from date
You wrote in part:

Quote:
>The ACCEPT solution is a kludge, not-portable, non-standard, and so on.  
>The fundtion is not a kludge, is portable, and is standard.

Since Acucobol is itself portable to over 750 different platforms, I really think that part of
it is a mute(sp?) point.  Acucobol also has ACCEPT DATE FROM CENTURY-DATE


Sat, 29 Nov 1997 03:00:00 GMT  
 accept from date

Quote:



>>intrinsic functions.  Use the CURRENT-DATE function and reference
>>modification to pick off the date.  Like the following:

>>    MOVE FUNCTION CURRENT-DATE (1:8) TO ws-date

>Well, does IBM COBOL II contain these "portable" functions?
>I don't see it in my IBM COBOL II release 3 manual...

COBOL II does not.  They are not compatible with the standard.  COBOL
370 does, as does every other major compiler.

Quote:
>How about Tandem?

It does.

Quote:
>How many companies are going to supply this with their compiler?

Every one.  It is part of the standard.

Quote:
>I guess I'm missing something.  What was it OK to accept a date from
>a register as in
>ACCEPT ws-date from DATE
>for the last twenty years, and now when a person asks if it is possible
>to add another register with two more digits for century
>it is "kludgy" and nonportable?

Lots of programs expect ACCEPT FROM DATE to return six characters.  
All of these programs would fail if it was changed to use eight
characters.  And, there is no reason to modify ACCEPT because the
function does what you want.  Changing ACCEPT was unanimously
rejected by the standards guys.  Also, a function can be used as a
variable and ACCEPT cannot.

Quote:

>In my humble, no one cares opinion, the function concept would be
>better served with a syntax such as:

>CALL FUNCTION CURRENT-DATE USING WS-DATE-FIELD.

>After all, subroutines like this are analogous to functions...

Wrong.  You can use functions where you can use variables.  For
example, if you want an integer date you would use

  SUBTRACT FUNCTION INTEGER-OF-DATE (FUNCTION NUMVAL (FUNCTION
    CURRENT-DATE (1: 8))) FROM some-future-date GIVING days-until

This is a bit wordy, but functions are much more useful than
something one calls.

Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
Project Editor, 1997 ISO COBOL Standard
Moderator, COBOL Conference, Bix


No clever quotes here



Sat, 29 Nov 1997 03:00:00 GMT  
 accept from date

Quote:


>>intrinsic functions.  Use the CURRENT-DATE function and reference
>>modification to pick off the date.  Like the following:

>>    MOVE FUNCTION CURRENT-DATE (1:8) TO ws-date

>Well, does IBM COBOL II contain these "portable" functions?
>I don't see it in my IBM COBOL II release 3 manual...

>How about Tandem?

>How many companies are going to supply this with their compiler?

>I guess I'm missing something.  What was it OK to accept a date from
>a register as in
>ACCEPT ws-date from DATE
>for the last twenty years, and now when a person asks if it is possible
>to add another register with two more digits for century
>it is "kludgy" and nonportable?

>In my humble, no one cares opinion, the function concept would be
>better served with a syntax such as:

>CALL FUNCTION CURRENT-DATE USING WS-DATE-FIELD.

>After all, subroutines like this are analogous to functions...

>Chris Mason
>"The Unknown COBOL Programmer"
>The opinions expressed are mine, not my Employers.

>LMSC5:  Tons of Beautiful Big Blue Iron...

HI,

Guess I'm missing something too.  I have always accepted the date from the
system using the "accept" command. I just set up the var. in WS and what not
and excepted the system date.  My compiler would not accept the function
current date.

Renee



Sat, 29 Nov 1997 03:00:00 GMT  
 accept from date

Quote:

> It is not portable from one implementation to another.  Also, why fancy up
> ACCEPT when the function is 10 times better (more flexible, is completely
> standard and works on all conforming implementations, and so on).

I don't know the history of the extended ACCEPT format, but presume
that it predated the function specification, and perhaps even the
85 standard.

It is through vendors creating extensions and enhancement to the
language that new standards are created.  In this case the
extension was pre-empted by the functions, in other cases the
extensions are accepted by the users and are formally embodied
by the standards.

I know that you sometimes rail against MicroFocus, but without
the extensions added by them, and others (usually incompatible
to each other however), Cobol would never have become usable on
PCs.

The most acceptable and usable extensions survive, those compilers
without particular features find their sales deminishing and so they
implement them and there is then a move towards a new standard.



Sun, 30 Nov 1997 03:00:00 GMT  
 accept from date

Quote:


>>intrinsic functions.  Use the CURRENT-DATE function and reference
>>modification to pick off the date.  Like the following:

>>    MOVE FUNCTION CURRENT-DATE (1:8) TO ws-date

>Well, does IBM COBOL II contain these "portable" functions?
>I don't see it in my IBM COBOL II release 3 manual...

No it doesn't.  But this is not the current IBM compiler.  COBOL/370
fully supports intrinsic functions.

Quote:
>How about Tandem?

Judging by Don's constant harping on this issue, one would have to guess
that Tandem does support them.

Quote:
>How many companies are going to supply this with their compiler?

All the companies that wish to provide a standard compliant COBOL
compiler.

Quote:
>I guess I'm missing something.  What was it OK to accept a date from
>a register as in
>ACCEPT ws-date from DATE
>for the last twenty years, and now when a person asks if it is possible
>to add another register with two more digits for century
>it is "kludgy" and nonportable?

>In my humble, no one cares opinion, the function concept would be
>better served with a syntax such as:

>CALL FUNCTION CURRENT-DATE USING WS-DATE-FIELD.

If you really prefer CALL to intrinsic functions, IBM's LE/370 allows
you  to call routines that are used for those functions.  Bear in mind
that this sort of code would only run on IBM mainframe machines, and
thus be non-portable.

--
//---------------------------------------------------------------

//---------------------------------------------------------------



Mon, 01 Dec 1997 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Problem "Accept from date"

2. ACCEPT FROM DATE & COBOL II

3. Y2K Bug found in ACCEPT FROM DATE

4. ACCEPT FROM DATE

5. accept from date

6. ACCEPT x FROM DATE issue

7. VS COBOL II - Accepting 9(08) date from system

8. ACCEPT x FROM DATE issue

9. ACCEPT x FROM DATE issue

10. Invalid dates - 215 using Btrieve/Clipper DATE format

11. how to convert clarion date to sql date

12. Create Time / date or Modified Time / date of a txt file

 

 
Powered by phpBB® Forum Software