[9916] in Perl-Users-Digest
Perl-Users Digest, Issue: 3509 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 22 12:00:56 1998
Date: Sat, 22 Aug 98 09:00:17 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 22 Aug 1998 Volume: 8 Number: 3509
Today's topics:
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: COBOL and Perl <charles@hankel.mersinet.co.uk>
Re: Is Perl5.004 Year 2000 compilant? (Larry Rosler)
Re: Warnings when dereferencing hashes? <jdf@pobox.com>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 22 Aug 1998 01:58:06 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <35DE179E.10A3EB24@hankel.mersinet.co.uk>
Thane Hubbell wrote:
>
> On Mon, 17 Aug 1998 00:31:04, abigail@fnx.com (Abigail) wrote:
>
> > That is why Perl is Perl, and nowhere near close to COBOL. That's also
> > why COBOL isn't suitable for modern programming.
>
> What's the toll to cross the bridge?
First of all you have to believe that "modern" is best...
...then you have to believe that you cannot possibly write a modern
application in COBOL...
...and finally you need to believe that the sort of work that COBOL does
can be performed in that same environments more effectively and more
efficiently with Perl.
BTW are there any Perl compilers suitable to a robust commercial
environment?
--
Charles F Hankel Wirral UK
------------------------------
Ready, Willing and (avail)Able
------------------------------
Date: Sat, 22 Aug 1998 01:38:45 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <35DE1315.28B6CD31@hankel.mersinet.co.uk>
foochre@my-dejanews.com wrote:
>
> In article <3298230.76649.23593@kcbbs.gen.nz>,
> riplin@kcbbs.gen.nz (Richard Plinston) wrote:
> >
> > To develop a system that outlast the life of its creator(s),
> > that will be worked on by generations of programmers, that
> > will run the business and will grow with it, a far more
> > formalised approach is required.
>
> I see strange irony in this statement considering the amount of
> money that is being ploughed into fixing up old cobol programs
> at the moment.
So the myth lives on, does it?
The largest number of systems affected by the y2k scenario are
relatively modern systems. The problem is being more assiduously
addressed by larger corporations whose business systems are massive and
were, naturally, written largely in COBOL. The actual amount of
defective COBOL code is not so large though. Most large organisations
have the situation well in hand and many whose operations are century
cognisant (e.g. insurance companies) have no significant problems with
y2k.
The real difficulties lie with the Small to Medium-size Enterprise (SME)
that has neither the resources nor the expertise to tackle y2k mainly
because their systems run on smaller machines where the platform's
primary language of choice was not COBOL. They heard the myth about all
the problems being with only old mainframe COBOL programs, and thought
they were safe. Of course, many of them have business-critical systems
running on small systems, written in C and similar trendy languages.
One of our nuclear power stations here has just completed its y2k
project and found that their only real problems were with their security
system. On the roll-over to 1/1/2000, the security system locked all
access to the site and locked all access to itself. In a real-life
scenario, this would mean that nobody would be able to enter or leave
the site, except by helicopter and anyway the new arrivals wouldn't be
allowed to do their work.
Now that's not an old COBOL program, and I think you should take note of
that before you start slagging off this fine language. You should also
desist from perpetuating the myth.
--
Charles F Hankel Wirral UK
------------------------------
------------------------------
Date: Sat, 22 Aug 1998 01:58:06 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <6rmmi9$k1a$7@elle.eunet.no>
Thane Hubbell wrote:
>
> On Mon, 17 Aug 1998 00:31:04, abigail@fnx.com (Abigail) wrote:
>
> > That is why Perl is Perl, and nowhere near close to COBOL. That's also
> > why COBOL isn't suitable for modern programming.
>
> What's the toll to cross the bridge?
First of all you have to believe that "modern" is best...
...then you have to believe that you cannot possibly write a modern
application in COBOL...
...and finally you need to believe that the sort of work that COBOL does
can be performed in that same environments more effectively and more
efficiently with Perl.
BTW are there any Perl compilers suitable to a robust commercial
environment?
--
Charles F Hankel Wirral UK
------------------------------
Ready, Willing and (avail)Able
------------------------------
Date: Sat, 22 Aug 1998 01:38:45 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <6rmmi9$k1a$6@elle.eunet.no>
foochre@my-dejanews.com wrote:
>
> In article <3298230.76649.23593@kcbbs.gen.nz>,
> riplin@kcbbs.gen.nz (Richard Plinston) wrote:
> >
> > To develop a system that outlast the life of its creator(s),
> > that will be worked on by generations of programmers, that
> > will run the business and will grow with it, a far more
> > formalised approach is required.
>
> I see strange irony in this statement considering the amount of
> money that is being ploughed into fixing up old cobol programs
> at the moment.
So the myth lives on, does it?
The largest number of systems affected by the y2k scenario are
relatively modern systems. The problem is being more assiduously
addressed by larger corporations whose business systems are massive and
were, naturally, written largely in COBOL. The actual amount of
defective COBOL code is not so large though. Most large organisations
have the situation well in hand and many whose operations are century
cognisant (e.g. insurance companies) have no significant problems with
y2k.
The real difficulties lie with the Small to Medium-size Enterprise (SME)
that has neither the resources nor the expertise to tackle y2k mainly
because their systems run on smaller machines where the platform's
primary language of choice was not COBOL. They heard the myth about all
the problems being with only old mainframe COBOL programs, and thought
they were safe. Of course, many of them have business-critical systems
running on small systems, written in C and similar trendy languages.
One of our nuclear power stations here has just completed its y2k
project and found that their only real problems were with their security
system. On the roll-over to 1/1/2000, the security system locked all
access to the site and locked all access to itself. In a real-life
scenario, this would mean that nobody would be able to enter or leave
the site, except by helicopter and anyway the new arrivals wouldn't be
allowed to do their work.
Now that's not an old COBOL program, and I think you should take note of
that before you start slagging off this fine language. You should also
desist from perpetuating the myth.
--
Charles F Hankel Wirral UK
------------------------------
------------------------------
Date: Sat, 22 Aug 1998 01:38:45 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <6rmmqb$la3$5@elle.eunet.no>
foochre@my-dejanews.com wrote:
>
> In article <3298230.76649.23593@kcbbs.gen.nz>,
> riplin@kcbbs.gen.nz (Richard Plinston) wrote:
> >
> > To develop a system that outlast the life of its creator(s),
> > that will be worked on by generations of programmers, that
> > will run the business and will grow with it, a far more
> > formalised approach is required.
>
> I see strange irony in this statement considering the amount of
> money that is being ploughed into fixing up old cobol programs
> at the moment.
So the myth lives on, does it?
The largest number of systems affected by the y2k scenario are
relatively modern systems. The problem is being more assiduously
addressed by larger corporations whose business systems are massive and
were, naturally, written largely in COBOL. The actual amount of
defective COBOL code is not so large though. Most large organisations
have the situation well in hand and many whose operations are century
cognisant (e.g. insurance companies) have no significant problems with
y2k.
The real difficulties lie with the Small to Medium-size Enterprise (SME)
that has neither the resources nor the expertise to tackle y2k mainly
because their systems run on smaller machines where the platform's
primary language of choice was not COBOL. They heard the myth about all
the problems being with only old mainframe COBOL programs, and thought
they were safe. Of course, many of them have business-critical systems
running on small systems, written in C and similar trendy languages.
One of our nuclear power stations here has just completed its y2k
project and found that their only real problems were with their security
system. On the roll-over to 1/1/2000, the security system locked all
access to the site and locked all access to itself. In a real-life
scenario, this would mean that nobody would be able to enter or leave
the site, except by helicopter and anyway the new arrivals wouldn't be
allowed to do their work.
Now that's not an old COBOL program, and I think you should take note of
that before you start slagging off this fine language. You should also
desist from perpetuating the myth.
--
Charles F Hankel Wirral UK
------------------------------
------------------------------
Date: Sat, 22 Aug 1998 01:58:06 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <6rmmqc$la3$6@elle.eunet.no>
Thane Hubbell wrote:
>
> On Mon, 17 Aug 1998 00:31:04, abigail@fnx.com (Abigail) wrote:
>
> > That is why Perl is Perl, and nowhere near close to COBOL. That's also
> > why COBOL isn't suitable for modern programming.
>
> What's the toll to cross the bridge?
First of all you have to believe that "modern" is best...
...then you have to believe that you cannot possibly write a modern
application in COBOL...
...and finally you need to believe that the sort of work that COBOL does
can be performed in that same environments more effectively and more
efficiently with Perl.
BTW are there any Perl compilers suitable to a robust commercial
environment?
--
Charles F Hankel Wirral UK
------------------------------
Ready, Willing and (avail)Able
------------------------------
Date: Sat, 22 Aug 1998 01:38:45 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <6rmmtm$ljg$6@elle.eunet.no>
foochre@my-dejanews.com wrote:
>
> In article <3298230.76649.23593@kcbbs.gen.nz>,
> riplin@kcbbs.gen.nz (Richard Plinston) wrote:
> >
> > To develop a system that outlast the life of its creator(s),
> > that will be worked on by generations of programmers, that
> > will run the business and will grow with it, a far more
> > formalised approach is required.
>
> I see strange irony in this statement considering the amount of
> money that is being ploughed into fixing up old cobol programs
> at the moment.
So the myth lives on, does it?
The largest number of systems affected by the y2k scenario are
relatively modern systems. The problem is being more assiduously
addressed by larger corporations whose business systems are massive and
were, naturally, written largely in COBOL. The actual amount of
defective COBOL code is not so large though. Most large organisations
have the situation well in hand and many whose operations are century
cognisant (e.g. insurance companies) have no significant problems with
y2k.
The real difficulties lie with the Small to Medium-size Enterprise (SME)
that has neither the resources nor the expertise to tackle y2k mainly
because their systems run on smaller machines where the platform's
primary language of choice was not COBOL. They heard the myth about all
the problems being with only old mainframe COBOL programs, and thought
they were safe. Of course, many of them have business-critical systems
running on small systems, written in C and similar trendy languages.
One of our nuclear power stations here has just completed its y2k
project and found that their only real problems were with their security
system. On the roll-over to 1/1/2000, the security system locked all
access to the site and locked all access to itself. In a real-life
scenario, this would mean that nobody would be able to enter or leave
the site, except by helicopter and anyway the new arrivals wouldn't be
allowed to do their work.
Now that's not an old COBOL program, and I think you should take note of
that before you start slagging off this fine language. You should also
desist from perpetuating the myth.
--
Charles F Hankel Wirral UK
------------------------------
------------------------------
Date: Sat, 22 Aug 1998 01:58:06 +0100
From: Charles F Hankel <charles@hankel.mersinet.co.uk>
Subject: Re: COBOL and Perl
Message-Id: <6rmmtn$ljg$7@elle.eunet.no>
Thane Hubbell wrote:
>
> On Mon, 17 Aug 1998 00:31:04, abigail@fnx.com (Abigail) wrote:
>
> > That is why Perl is Perl, and nowhere near close to COBOL. That's also
> > why COBOL isn't suitable for modern programming.
>
> What's the toll to cross the bridge?
First of all you have to believe that "modern" is best...
...then you have to believe that you cannot possibly write a modern
application in COBOL...
...and finally you need to believe that the sort of work that COBOL does
can be performed in that same environments more effectively and more
efficiently with Perl.
BTW are there any Perl compilers suitable to a robust commercial
environment?
--
Charles F Hankel Wirral UK
------------------------------
Ready, Willing and (avail)Able
------------------------------
Date: Sat, 22 Aug 1998 08:11:10 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Is Perl5.004 Year 2000 compilant?
Message-Id: <MPG.10487f6d3251b2d29897dc@nntp.hpl.hp.com>
[Posted to comp.lang.perl.misc and copy mailed.]
In article <6rm5tg$9co$3@nz12.rz.uni-karlsruhe.de> on Sat, 22 Aug 1998
10:17:22 GMT, Marc Haber <Marc.Haber-usenet@gmx.de> says...
> lr@hpl.hp.com (Larry Rosler) wrote:
> >In article <6rk3qq$k1o$1@clarknet.clark.net> on 21 Aug 1998 15:30:34 GMT,
> >alexk@appliedtheory.com <alexk@appliedtheory.com> says...
> >> Jeff Gao <jeff_gao@bctel.net> wrote:
> >> : Does anybody know that whether perl 5.004 is y2k compilant?
> >>
> >> Yes, but it is not Y2.38K compliant.
> >
> >I wouldn't care much about that. But you meant Y2.038K, and that *is*
> >something to be concerned about.
>
> Actually, I believe that perl will be Y2.038K compliant as soon as the
> underlying OS is. Am I missing something?
Yes, you are missing the main point. As was discussed here recently, the
issue is not whether the OS and the internal data represent time in 32 or
64 bits. The issue is that all existing external data (in which time is
now represented exclusively in 32-bit integers) become ambiguous. Either
the programs that deal with such data must add logic to resolve the
ambiguities, or the data sets themselves must be redesigned and
rewritten.
This is the real reason behind the massive cost of the century bug --
external storage of the year in two decimal digits. Using six bytes to
store a date is wasteful, but preceded C and the Unix Epoch. So, just as
Cobol's data are facing Armageddon now, C[++] and Perl's data will face
it in 2038.
Do not expect enlightment to come before 2035 or so. Are *you*
allocating more than 32 bits to store time in external data?
Be afraid. Be very afraid. Or (as a colleague put it at the Perl
Conference), be doing the Big Sleep, as he and I will be by then. :-(
--
(Yet Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 22 Aug 1998 11:51:52 -0500
From: Jonathan Feinberg <jdf@pobox.com>
To: Jeffery Cann <jc_cann@ix.netcom.com>
Subject: Re: Warnings when dereferencing hashes?
Message-Id: <r9y96jtj.fsf@mailhost.panix.com>
Jeffery Cann <jc_cann@ix.netcom.com> writes:
> Use of uninitialized value at ./deref.pl line 12 (#1)
You didn't make clear which line in your program was generating that
error. However, it seems to be the case that you're using $jeff{NAME}
as if it were defined, and it's not. To check the existence of a hash
key, use exists(), like so:
if (exists $jeff{NAME}) {
# use $jeff{NAME} somehow
}
Or you can supply $jeff{NAME} with a default value:
$jeff{NAME} ||= 'default value';
--
Jonathan Feinberg jdf@pobox.com Sunny Brooklyn, NY
http://pobox.com/~jdf/
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 3509
**************************************
