Who cares about the ANSI/ISO Standard? 
Author Message
 Who cares about the ANSI/ISO Standard?

I couldn't help but put in my $0.02 after reading the entire thread
about Fujitsu COBOL, and the difficulty they have in telling users
whether a COBOL program conforms to the standard.

One reply from an employee of a vendor of hardware and COBOL that runs
on the hardware says that customers seem to be interested and expect
Unisys to participate in setting the standard and to conform to it.

One "user" pointed out that, having done many ports of COBOL
applications between different hardware platforms, the reason this
activity was usually so easy was -- the standard.

I submit that one reason several others said the standard is of no
concern to them was precisely because it _has_ existed for a long time
(at least, long in terms of the computer industry), and it _has_ been
followed by so many compiler creators.  If Unisys COBOL, IBM COBOL, MF
COBOL, Fujitsu COBOL, and many others didn't all treat a MOVE statement
exactly the same, as defined by the standard, it seems very likely to me
that there wouldn't BE so many COBOL compilers.  There wouldn't be more
COBOL programs in existence than any other language (or is it all others
combined?).  And there very likely WOULD be a Microsoft COBOL, and it
would be different from all the others!

We don't always have to think about, or even know, a standard for it to
be of value to us.

There is a standard named ISO 8601, titled "Data elements and
interchange formats - Information interchange - Representation of date
and times", which, if we'd all paid attention to it, might have saved
hundreds of billions of dollars in Y2K repair costs.  The "repairs" my
organization did for our customers still do not conform to that
standard.



Tue, 20 Sep 2005 05:44:38 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:

>There is a standard named ISO 8601, titled "Data elements and
>interchange formats - Information interchange - Representation of date
>and times", which, if we'd all paid attention to it, might have saved
>hundreds of billions of dollars in Y2K repair costs.  The "repairs" my
>organization did for our customers still do not conform to that
>standard.

Most Y2K fixes I've seen in production code are incredibly short-sighted.  They
are good for 10 years. As we approach 2010, we'll have another date crisis.

Some go out 30 or 50 years. They should use a 'sliding window' which would work
indefinitely.



Tue, 20 Sep 2005 09:59:17 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:

> Most Y2K fixes I've seen in production code are incredibly short-sighted.
> They are good for 10 years. As we approach 2010, we'll have another date
> crisis.

No. _YOU_ will have another date crisis.

_I_ will not have another date crisis.

Many others will not have another date crisis.



Tue, 20 Sep 2005 11:23:30 GMT  
 Who cares about the ANSI/ISO Standard?
On Fri, 04 Apr 2003 15:23:30 +1200, Richard Plinston

Quote:

>> Most Y2K fixes I've seen in production code are incredibly short-sighted.
>> They are good for 10 years. As we approach 2010, we'll have another date
>> crisis.

>No. _YOU_ will have another date crisis.

>_I_ will not have another date crisis.

>Many others will not have another date crisis.

I know I wont because I know how to add 1 to a packed date field and
get a valid date.

Regards,

          ////
         (o o)
-oOO--(_)--OOo-

Micro$oft Haiku Error Message #111

The Tao that is seen
Is not the true Tao - until
You bring fresh toner.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve



Wed, 21 Sep 2005 03:11:09 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:

>Date: 4/3/03 8:59 PM Eastern Standard Time

>Some go out 30 or 50 years. They should use a 'sliding window' which would
>work
>indefinitely.

If they are still running in 30 or 50 years the SHOULD go out.  Seem to
remember hearing/reading someplace the average system life is 10-15 years.
These would have definately outlived their usefulness.


Wed, 21 Sep 2005 11:42:16 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:


>> Most Y2K fixes I've seen in production code are incredibly short-sighted.
>> They
>> are good for 10 years. As we approach 2010, we'll have another date crisis.

>2010?   What kind of fix was that?

>> Some go out 30 or 50 years. They should use a 'sliding window' which would
>> work indefinitely.

>They should use 4 digit years.

The vast majority do NOT use 4 digit years. They simulate it by:

if  year-3-4 greater than '10'
    move '19' to year-1-2
else
    move '20' to year-1-2
end-if

I'm not making this up. I'm looking at hundreds of programs 'fixed' with this
kind of logic, at a major Wall Street company.

COBOL shares some of the blame. As Y2K approached, the standard for ACCEPT foo
FROM DATE should have been changed to an eight digit date. It never was in the
standard, only by a few 'vendors'. We were abandoned to fight Y2K on our own
rather than getting any support from COBOL, which is widely thought to have
caused the problem in the first place. Admittedly it's a bum rap, but that was
the perception. The standards committee should have done more ... anything ...
to solve the problem. It didn't.



Wed, 21 Sep 2005 17:13:34 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:


> >Date: 4/3/03 8:59 PM Eastern Standard Time

> >Some go out 30 or 50 years. They should use a 'sliding window' which would
> >work
> >indefinitely.

> If they are still running in 30 or 50 years the SHOULD go out.  Seem to
> remember hearing/reading someplace the average system life is 10-15 years.
> These would have definately outlived their usefulness.

Hmm.... I know a system I work on is not average, and I know that
"modern" language systems are often rewritten rather than maintained,
thus reducing the average lifespan, but I work on some code currently
that with programs that have a creation date of 1974.


Wed, 21 Sep 2005 20:03:45 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:

> >Date: 4/3/03 8:59 PM Eastern Standard Time

> >Some go out 30 or 50 years. They should use a 'sliding window' which
would
> >work>>indefinitely.

> If they are still running in 30 or 50 years the SHOULD go out.  Seem to
> remember hearing/reading someplace the average system life is 10-15 years.

Proper Design Life Span = (Anticipated retirement age) - (Current age of
designer)

MCM



Wed, 21 Sep 2005 21:38:37 GMT  
 Who cares about the ANSI/ISO Standard?


[snip]

Quote:
> COBOL shares some of the blame. As Y2K approached, the standard for ACCEPT
foo
> FROM DATE should have been changed to an eight digit date. It never was in
the
> standard, only by a few 'vendors'. We were abandoned to fight Y2K on our
own
> rather than getting any support from COBOL, which is widely thought to
have
> caused the problem in the first place. Admittedly it's a bum rap, but that
was
> the perception. The standards committee should have done more ... anything
...
> to solve the problem. It didn't.

Changing the standard for ACCEPT ... FROM DATE would
have broken some programs that would not have required
any changes. For example, a report program where the date
is shown on the report but not used otherwise.

Support for 8 digit dates was added in the "Intrinsic Functions"
amendment in 1989. For example,
    MOVE FUNCTION CURRENT-DATE (1:8) TO MyCCYYMMDD

I was able to do all Y2K remediation by using features provided
in that amendment. In other words, the "standards committee"
did *everything* I needed to solve the problem, except write the
code for me!



Wed, 21 Sep 2005 22:22:54 GMT  
 Who cares about the ANSI/ISO Standard?
The Y2K problem was anticipated by some in the 70s and 80s, but at that
time, we were assured that since the average system life span was 10-15
years, "Don't worry about it; use a two-digit year."  Look what happened.
:)

--

....Terry


Quote:

> >Date: 4/3/03 8:59 PM Eastern Standard Time

> >Some go out 30 or 50 years. They should use a 'sliding window' which
would
> >work
> >indefinitely.

> If they are still running in 30 or 50 years the SHOULD go out.  Seem to
> remember hearing/reading someplace the average system life is 10-15 years.
> These would have definately outlived their usefulness.



Wed, 21 Sep 2005 23:07:16 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:

>The Y2K problem was anticipated by some in the 70s and 80s, but at that
>time, we were assured that since the average system life span was 10-15
>years, "Don't worry about it; use a two-digit year."

'Anticipated'?  Mr Heinze, I would argue that 'anticipation' occurred
earlier; it might not be too far-fetched to conclude that someone in a
bank, somewhere, said 'Hey... how are we going to calculate thirty-year
mortgages?' in late 1969.

Quote:
>Look what happened.
>:)

There is nothing unusual in programmers making a living due to managerial
shortsightedness last I looked.

DD



Wed, 21 Sep 2005 23:41:06 GMT  
 Who cares about the ANSI/ISO Standard?


Quote:
>  There wouldn't be more
> COBOL programs in existence than any other language (or is it all others
> combined?).  And there very likely WOULD be a Microsoft COBOL, and it
> would be different from all the others!

Surely you misstated.  Of course Microsoft COBOL would fully comply with
the standard, but none of the other vendors would.


Thu, 22 Sep 2005 00:19:33 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:


>>Date: 4/3/03 8:59 PM Eastern Standard Time

>>Some go out 30 or 50 years. They should use a 'sliding window' which would
>>work
>>indefinitely.

>If they are still running in 30 or 50 years the SHOULD go out.  Seem to
>remember hearing/reading someplace the average system life is 10-15 years.
>These would have definately outlived their usefulness.

Does that apply to languages too? If so, COBOL should have been replaced in the
70's.


Thu, 22 Sep 2005 02:46:08 GMT  
 Who cares about the ANSI/ISO Standard?

Quote:



>[snip]
>> COBOL shares some of the blame. As Y2K approached, the standard for ACCEPT
>foo
>> FROM DATE should have been changed to an eight digit date. It never was in
>the
>> standard, only by a few 'vendors'. We were abandoned to fight Y2K on our
>own
>> rather than getting any support from COBOL, which is widely thought to
>have
>> caused the problem in the first place. Admittedly it's a bum rap, but that
>was
>> the perception. The standards committee should have done more ... anything
>...
>> to solve the problem. It didn't.

>Changing the standard for ACCEPT ... FROM DATE would
>have broken some programs that would not have required
>any changes. For example, a report program where the date
>is shown on the report but not used otherwise.

They did it by looking at the size of the receiving field. If 6, function as
before; if 8, return an eight digit date. That wouldn't break existing code.

Quote:

>Support for 8 digit dates was added in the "Intrinsic Functions"
>amendment in 1989. For example,
>    MOVE FUNCTION CURRENT-DATE (1:8) TO MyCCYYMMDD

I never paid much attention to functions. To tell the truth, I was unaware they
were in the standard. I thought they were vendor extensions.

Quote:
>I was able to do all Y2K remediation by using features provided
>in that amendment. In other words, the "standards committee"
>did *everything* I needed to solve the problem, except write the
>code for me!

Big shops where I worked had languages in addition to COBOL. They went with a
language-independent solution -- a callable program.


Thu, 22 Sep 2005 02:46:14 GMT  
 Who cares about the ANSI/ISO Standard?
I worked on a system, written in 1991, which used a ONE digit year. Why? Because
programmers were told it was temporary and would be replaced within 2-3 years.
When we fixed it in 1998, it was still writing accounts payable checks.
Quote:

>The Y2K problem was anticipated by some in the 70s and 80s, but at that
>time, we were assured that since the average system life span was 10-15
>years, "Don't worry about it; use a two-digit year."  Look what happened.
>:)

>--

>....Terry




>> >Date: 4/3/03 8:59 PM Eastern Standard Time

>> >Some go out 30 or 50 years. They should use a 'sliding window' which
>would
>> >work
>> >indefinitely.

>> If they are still running in 30 or 50 years the SHOULD go out.  Seem to
>> remember hearing/reading someplace the average system life is 10-15 years.
>> These would have definately outlived their usefulness.



Thu, 22 Sep 2005 03:02:18 GMT  
 
 [ 71 post ]  Go to page: [1] [2] [3] [4] [5]

 Relevant Pages 

1. Static scoping in BCPL (was Re: Are nested functions legal in ANSI/ISO Standard C)

2. Reporting defects in the ANSI/ISO COBOL Standards

3. ABSOLUTELY last chance to comment on next COBOL ANSI/ISO Standard

4. SIZE ERROR, Truncation, and what the ANSI/ISO Standard says

5. ISO COBOL Standard available from ANSI online store

6. ANSI, ISO, IEEE STANDARD .. FORTRAN FAQ's

7. standards: ANSI LISP vs. ISO/IEC ISLISP

8. ANSI and ISO COBOL news

9. Fujitsu - asking for business case for ANSI/ISO conformance

10. ISO/IEC/NCITS/ANSI dinosaur. Was many threads

11. (ANSI/ISO) COBOL CD 1.10 Available

12. ANSI COBOL and ISO COBOL meetings this summer

 

 
Powered by phpBB® Forum Software