 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
70%-80% of UK business transactions are handled by COBOL programs.
I knew it was still big, but not that big.
http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> 70%-80% of UK business transactions are handled by COBOL programs.
> I knew it was still big, but not that big.
> http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming
Looking at COBOL example code, it looks like a mix between INTERCAL and
LOLCODE. Except that perhaps LOLCODE is easier to understand.
(Looking at Fortran examples, it doesn't look any better...)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Looking at COBOL example code, it looks like a mix between INTERCAL and
> LOLCODE.
Heh. A bit. It was supposed to be something you could read. Not unlike
LOLCODE a bit, but I don't see the connection to INTERCAL except that some
of the terms are spelled out in prose.
Even reading the COBOL for 99 bottles, I found it difficult to understand. I
guess COBOL has changed a lot in the last 40 years or so. For example, the
last COBOL I used you couldn't put the body of the loop near the loop
control - you had to say "go call that subroutine 99 times" and write the
subroutine somewhere else. As in the "Cobol typical mainframe" version.
Put it this way, tho. If you knew neither (say) C nor COBOL (to pick
languages vaguely in the same timeframe), which would be easier to read? If
you didn't know how to program at all, what would be easy to ready? That was
one of the design goals for COBOL.
> (Looking at Fortran examples, it doesn't look any better...)
The FORTRAN 90 looks pretty straightforward. Fortran IV was the last FORTRAN
I actually did any serious work in, and that looks pretty straightforward,
if you understand how printf() works in Fortran.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Put it this way, tho. If you knew neither (say) C nor COBOL (to pick
> languages vaguely in the same timeframe), which would be easier to read? If
> you didn't know how to program at all, what would be easy to ready? That was
> one of the design goals for COBOL.
I don't know if it's just that I have been exposed way too much to the
C family of languages (obviously C and C++, but also some PHP and Perl,
and to an extent the POV-Ray SDL) and to shell-scripting type of languages,
but it just feels like when a language like COBOL explicitly states out
with full words what you want to do, rather ironically, it seems to make
the code more obfuscated rather than easier to understand.
Maybe it's the lack of delimiters. It's difficult to see where logical
code blocks begin and end when there are no visually distinguishing delimiter
symbols. Not even indentation to make them stand out (such as eg. in Python).
Probably a question of getting accustomed to the syntax.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> The FORTRAN 90 looks pretty straightforward. Fortran IV was the last
> FORTRAN I actually did any serious work in, and that looks pretty
> straightforward, if you understand how printf() works in Fortran.
Yet it seems almost all Fortran code out there is still in 77, and is
still written in 77.
I don't know Fortran well - only coded it once. Had to modify someone's
code to add some numerical algorithm. So am not an expert. However, a
friend of mine who knows it much better, and is comfortable with it
(albeit while disliking it) told me the reason almost all (scientific)
Fortran code is still written in 77 is that 90 onwards performed poorly.
--
186,000 miles/sec: Not just a good idea, it's the LAW.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't know if it's just that I have been exposed way too much to the
> C family of languages
I think that's it. As I said, one of the original design goals was that
non-programmers could read it. It's pretty straightforward what each
individual sentence does. The overall structure is obscured in the way you
say, in part due to the verbosity making it spread much bigger, and in part
due to the lack of familiar control structures, indenting, etc.
> Maybe it's the lack of delimiters. It's difficult to see where logical
> code blocks begin and end when there are no visually distinguishing delimiter
> symbols. Not even indentation to make them stand out (such as eg. in Python).
Yeah. On the other hand, lots of COBOL programs tend to not have a whole lot
of deep structure in them, in my very limited experience. One tends to
structure 30 programs with bunches of intermediate files rather than one
program with 30 subroutines nesting 5 deep. Not unlike shell scripting, sorta.
Of course, it's from before structured programming, let alone before OO or
anything like that, so yeah, it's going to have funky control structures.
Altho I did see a book on object-oriented COBOL sitting on a shelf not too
long ago.
> Probably a question of getting accustomed to the syntax.
That too. The data declarations are pretty cool for a business language,
tho. Lots of the older machines had hardware support for COBOL data types,
back when doing things like printf() or decimal arithmetic in software was
prohibitively slow.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> It was supposed to be something you could read.
I don't think it makes any sense to write out mathematical formulae
as english expressions. It only makes the result confusing and very
hard to understand. I don't even understand why the thought it would
be a good idea. What businessman doesn't understand "x = a+b" equally
well as, if not even better than "ADD A TO B GIVING X"?
The latter form becomes ridiculous when the expression is any longer,
such as:
MULTIPLY B BY B GIVING B-SQUARED.
MULTIPLY 4 BY A GIVING FOUR-A.
MULTIPLY FOUR-A BY C GIVING FOUR-A-C.
SUBTRACT FOUR-A-C FROM B-SQUARED GIVING RESULT-1.
COMPUTE RESULT-2 = RESULT-1 ** .5.
SUBTRACT B FROM RESULT-2 GIVING NUMERATOR.
MULTIPLY 2 BY A GIVING DENOMINATOR.
DIVIDE NUMERATOR BY DENOMINATOR GIVING X.
Who ever thought that would be a good idea? Who understands that?
It seems that COBOL does support the more intuitive way too, ie:
COMPUTE X = (-B + SQRT(B ** 2 - (4 * A * C))) / (2 * A)
So what's the point in having both syntaxes?
Maybe because it was the 50's and computers were a brand new invention,
people thought that it's cool if you can write "plain English" and have
the computer understand it. Whether it's actually practical is secondary.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Who ever thought that would be a good idea? Who understands that?
Grace Hopper?
> So what's the point in having both syntaxes?
Because an awful lot of times, just the one addition or multiplication is
what you need.
MULTIPLY RETAIL-PRICE BY DISCOUNT-PERCENT GIVING DISCOUNTED-PRICE.
MULTIPLY DISCOUNTED-PRICE BY SALES-TAX-PERCENTAGE GIVING SALES-TAX.
ADD SALES-TAX TO DISCOUNTED-PRICE GIVING TOTAL-DISPLAYED-ON-REGISTER.
It makes it trivially easy to see that the sales tax is applied to the
discounted price, not the original price, for example.
In all the programs I wrote in 2 years of full time cobol programming, I
think I used COMPUTE maybe twice? You almost always need the intermediate
values anyway, in business calculations.
> people thought that it's cool if you can write "plain English" and have
> the computer understand it. Whether it's actually practical is secondary.
No. It's because the boss can understand stuff like what I wrote above. Just
like lots of the limitations of early FORTRAN[1] were there to make it
possible to compile into something as efficient as assembler.
Look at something like a US tax form. The math is all trivial, one operation
per line.
Scientific computing (a la fortran) didn't work this way for a reason: the
formulae aren't usually trivial in science, and you usually don't need the
intermediate values.
[1] Like the fact that there were only a handful of valid expression forms
you could use for a subscript, because that was the only way to ensure you
could use these new-fangled index registers.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
70-80%? I thought COBOL was pretty much dead after SQL. Do COBOL programs use
SQL databases?
BTW, recently Lisp turned 50 as well:
http://www.lisp50.org/50-years-of-lisp/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Because an awful lot of times, just the one addition or multiplication is
> what you need.
> MULTIPLY RETAIL-PRICE BY DISCOUNT-PERCENT GIVING DISCOUNTED-PRICE.
> MULTIPLY DISCOUNTED-PRICE BY SALES-TAX-PERCENTAGE GIVING SALES-TAX.
> ADD SALES-TAX TO DISCOUNTED-PRICE GIVING TOTAL-DISPLAYED-ON-REGISTER.
I still find this clearer:
DISCOUNTED-PRICE = RETAIL-PRICE * DISCOUNT-PERCENT.
GIVING SALES-TAX = DISCOUNTED-PRICE * SALES-TAX-PERCENTAGE.
TOTAL-DISPLAYED-ON-REGISTER = SALES-TAX + DISCOUNTED-PRICE.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> 70-80%? I thought COBOL was pretty much dead after SQL.
Is SQL even Turing-complete?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> 70-80%? I thought COBOL was pretty much dead after SQL. Do COBOL programs use
> SQL databases?
COBOL predates SQL, but COBOL has of course been updated to support SQL.
Indeed, I believe COBOL was the first language to get embedded SQL. It
already had some fairly sophisticated file operation stuff built into the
language (like looking up values in flat files, etc.)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > 70-80%? I thought COBOL was pretty much dead after SQL.
>
> Is SQL even Turing-complete?
No. But my point is that COBOL was the language to write your business in when
there was:
1) no standard databases
2) no easier language
Even Perl+SQL database via DBI offer a far more robust and easier solution than
COBOL. It's a language surviving on name. Common Business... :P
That said, I think it's truly hard to believe COBOL is more used than SQL in
business today. Every system these days accesses a SQL database in one way or
another, be it written in Java, C#, C++, Perl or, I believe, COBOL.
So, I believe that 70-80% figure sounds highly overrated unless it's counting
SQL out.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> nemesis <nam### [at] gmailcom> wrote:
>>> 70-80%? I thought COBOL was pretty much dead after SQL.
>> Is SQL even Turing-complete?
>
> No. But my point is that COBOL was the language to write your business in when
> there was:
> 1) no standard databases
You got it backwards, actually. The CODASYL database standard is what led to
needing a business language to access databases, a la COBOL. SQL replaced
CODASYL only some 10-15 years later (depending on how you define "replaced").
> 2) no easier language
No business-oriented language that was easier, yes. There was basically
assembler, fortran, cobol, LISP, maybe APL and/or BASIC. COBOL's definitely
the best of the bunch for business/database apps.
> Even Perl+SQL database via DBI offer a far more robust and easier solution than
> COBOL.
Disagreed. Perl has no decimal money type, for example. Plus, it's up to the
programmer to ensure that files are laid out correctly between different
applications, for example. The lack of a file section in the data division
of Perl means you can screw things up in common files. It might be "easier"
in some ways, but I don't think "more robust" is quite right, assuming you
mean "robust" the same way I do (namely, unlikely to screw up your data).
Plus, why in the world would you run an interpreted Perl program to do
things like (say) payroll, that you're going to compile once and run 100,000
times over the lifetime of the application?
> That said, I think it's truly hard to believe COBOL is more used than SQL in
> business today. Every system these days accesses a SQL database in one way or
> another, be it written in Java, C#, C++, Perl or, I believe, COBOL.
Likely.
> So, I believe that 70-80% figure sounds highly overrated unless it's counting
> SQL out.
I don't think SQL counts as a programming language you write programs in, at
least in the eyes of the author.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> Every system these days accesses a SQL database in one way or another
Btw, is it correct to say "SQL database"?
AFAIK SQL is a computer language standard, not really a database standard.
SQL is simply the interface (or one of the possible interfaces) which is
used to access the database. Perhaps a good comparison would be like a
Unix kernel and the file system (which would correspond to the database) and
SH scripting (which would correspond to SQL). Just because you can access the
file system using SH doesn't make it an "SH operating system".
Ok, maybe it wouldn't be too far-fetched to say that "SQL database" is
just short for "a database system which is mainly/exclusively interfaced
with using SQL".
Btw, do database systems (such as Oracle) support any other interfaces
than SQL? Are there any database systems which would use something else than
SQL as the user interface? (Can MS Access be considered a database system?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Ok, maybe it wouldn't be too far-fetched to say that "SQL database" is
> just short for "a database system which is mainly/exclusively interfaced
> with using SQL".
Or perhaps "A database compatible with access via SQL"? SQL can't really
search anything that doesn't fairly closely follow the relational model, is
what I'm trying to say.
> Btw, do database systems (such as Oracle) support any other interfaces
> than SQL?
Sure. There's QBE - Query By Example. There's all kinds of form inputs
(which eventually probably turn into SQL). There's what's called Relational
Algebra, where you write out selects, projects, and joins as such, altho I
don't know any databases that specifically expose that interface.
And of course there's a bunch of interfaces for things like making backups
or replicating data that access the database in a bulk-like way without
doing what you might call "queries".
> Are there any database systems which would use something else than
> SQL as the user interface?
Yes. CouchDB, Google's App Engine cloud database, Google's BigTable,
Amazon's SimpleDB, a bunch of stuff inside Amazon (like Dynamo), etc. All
pretty much targetted at spaces where speed or scale (or both) is more
important than consistency. (I.e., none of them are what you'd call ACID.)
> (Can MS Access be considered a database system?)
I would certainly say so. Not a very sophisticated one, mind. And there were
tons of such database systems (foxbase, dbase, etc) back before desktop
machines got powerful enough to effectively support fully relational databases.
http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
http://labs.google.com/papers/bigtable.html
http://en.wikipedia.org/wiki/Query_by_Example
http://couchdb.apache.org/
http://code.google.com/appengine/docs/java/datastore/overview.html
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > Warp <war### [at] tagpovrayorg> wrote:
> >> nemesis <nam### [at] gmailcom> wrote:
> >>> 70-80%? I thought COBOL was pretty much dead after SQL.
> >> Is SQL even Turing-complete?
> >
> > No. But my point is that COBOL was the language to write your business in when
> > there was:
> > 1) no standard databases
>
> You got it backwards, actually. The CODASYL database standard is what led to
> needing a business language to access databases, a la COBOL. SQL replaced
> CODASYL only some 10-15 years later (depending on how you define "replaced").
I vaguely remember about mentions to CODASYL.
> > 2) no easier language
>
> No business-oriented language that was easier, yes. There was basically
> assembler, fortran, cobol, LISP, maybe APL and/or BASIC. COBOL's definitely
> the best of the bunch for business/database apps.
I'd say Assembler and Fortran would be ruled out for business purposes right
away. LISP was too imature at the time (60s) and was a hog meant for research
on AI and language design. APL I don't really know, but BASIC is just that,
basic. So, yeah, right language for the job, *back then*.
> > Even Perl+SQL database via DBI offer a far more robust and easier solution than
> > COBOL.
>
> Disagreed. Perl has no decimal money type, for example.
It was just an extreme example, perhaps not quite accurate, but the point is
that even a scripting language coupled to a RDBMS could do the job today, let
alone performant scripting languages leveraging from fast, robust VMs, like
Scala on JVM.
anyway, is it much of a hassle to use double to represent monetary values?
> Plus, why in the world would you run an interpreted Perl program to do
> things like (say) payroll, that you're going to compile once and run 100,000
> times over the lifetime of the application?
Perl is a glue language: it's main purpose like should be all scripting is to
integrate different systems and route data between them. Perl "slowness"
doesn't really get into account when it is expecting data from the RDBMS to
feed the PDF generator.
At workplace, at least, SQL responds pretty much for about 80% of the code, the
rest being forms and reports in Delphi to either enter or extract data to/from
the RDBMS. Business rules validation on persistence is done by SQL stored
procedures.
> > So, I believe that 70-80% figure sounds highly overrated unless it's counting
> > SQL out.
>
> I don't think SQL counts as a programming language you write programs in, at
> least in the eyes of the author.
SQL alone, no. But stored procedures get you many new abilities.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > Every system these days accesses a SQL database in one way or another
>
> Btw, is it correct to say "SQL database"?
It may not be accurate, but the meaning is obvious, I guess: RDBMS employing SQL
as main interface.
> Btw, do database systems (such as Oracle) support any other interfaces
> than SQL?
I heard Oracle supports Java. PostgreSQL can have stored procedures written in
TCL, Python and Perl, all being used to *complement* SQL. I don't think there's
that much more convenient a language to fetch relational data than SQL, even C#
with Linq resembles SQL very much.
If only it had some macro processing, it should be much more handy. While views
can perform the same job, it's at cost of runtime performance.
I'm no fan of SQL. I wish I was playing with pointers all day.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> anyway, is it much of a hassle to use double to represent monetary values?
Yes. It's not correct. Add up a billion dollars in penny increments, and
tell me you can guarantee it's right.
> At workplace, at least, SQL responds pretty much for about 80% of the code, the
> rest being forms and reports in Delphi to either enter or extract data to/from
> the RDBMS. Business rules validation on persistence is done by SQL stored
> procedures.
Yeah, OK, if most of your actual code is in SQL, I'll grant you that. :-)
You still need something that supports the SQL data types, then.
> SQL alone, no. But stored procedures get you many new abilities.
Granted.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> I heard Oracle supports Java. PostgreSQL can have stored procedures written in
> TCL, Python and Perl, all being used to *complement* SQL. I don't think there's
> that much more convenient a language to fetch relational data than SQL, even C#
> with Linq resembles SQL very much.
They all eventually translate to SQL, tho, I think. Maybe some of the .NET
stuff is similar, but I don't know how the internals interface. Maybe
straight thru a COM-like interface without going thru SQL.
> I'm no fan of SQL. I wish I was playing with pointers all day.
So learn CODASYL. :-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Btw, do database systems (such as Oracle) support any other interfaces
> than SQL?
This is cool, btw:
http://www.businessintelligencelowdown.com/2007/02/top_10_largest_.html
I know the AT&T database runs SQL. When I was there 15 years ago, they had
100 million lines of SQL.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> http://www.businessintelligencelowdown.com/2007/02/top_10_largest_.html
I can only imagine how expensive it is to backup all that information
(and I have hard time believing they don't backup it). Not only is the
backup medium expensive (because of the sheer amount required), but
physically *storing* it somewhere must also be expensive (after all,
physical storage space is never free). I also imagine that they want to
store the backups in a secure location (from accidents, eg. fires, and
robberies/vandalism), which can only make the storage costs several times
larger.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> > http://www.businessintelligencelowdown.com/2007/02/top_10_largest_.html
>
> I can only imagine how expensive it is to backup all that information
> (and I have hard time believing they don't backup it). Not only is the
> backup medium expensive (because of the sheer amount required), but
> physically *storing* it somewhere must also be expensive (after all,
> physical storage space is never free). I also imagine that they want to
> store the backups in a secure location (from accidents, eg. fires, and
> robberies/vandalism), which can only make the storage costs several times
> larger.
>
> --
> - Warp
The company I work for is no where near as large as ATT. We have a small to
medium size mainframe operation, with about 15TB of online disk storage and
around 120TB of tape for backup and archival storage. We keep a minimum of
three backup copies of all critical data, one of those copies is always stored
offsite. For legal reasons some data we have to keep more copies for a longer
period of time. For non-critical data we normally keep only a couple of copies
locally. No it is not cheap, but it is a lot cheaper than losing the data,
facing lawsuits, fines, and going out of business.
Isaac.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I can only imagine how expensive it is to backup all that information
> (and I have hard time believing they don't backup it).
Back in 1992 or so, I spent about a week locked in with EDS's credit card
processing systems. (EDS handled at least the top four credit card banks at
the time, and of course a bunch of other stuff.) A room maybe 50 meters on a
side, two power feeds from two separate electric companies, full of
mainframes, printers, etc. There were at least three people at any given
time wheeling carts full of tapes between the tape changers and the back
room. Plus two people on "wheel fresh paper to the 1600LPM line printers"
duty. It was a pretty impressive sight.
As for AT&T, altho I never thought to ask about backup stuff, I do know they
had at least 400 people full-time coding SQL to maintain it.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> As for AT&T, altho I never thought to ask about backup stuff, I do know they
> had at least 400 people full-time coding SQL to maintain it.
Speaking of AT&T... 312 terabytes in one single database? That starts
requiring some efficiency from the part of the database software...
I think it could perhaps be safely assumed they use Oracle? (I have read
Oracle is about the only database system out there which scales up so much.
Or at least that's what the Oracle company wants us to believe in any case.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Speaking of AT&T... 312 terabytes in one single database? That starts
> requiring some efficiency from the part of the database software...
Indeed! Almost mind-boggling. And that's just one of the 9 large databases
they have. This one sounds like PREMIS, which is all the call data,
billing, etc. Basically, ever interaction with an end-user of the network.
The other giant one (which I thought used to be bigger, but might have
shrunk with more fiber while PREMIS continues to grow) is TURKS. The Trunk
Utilization and Resource Knowledge System tracks basically where all the
wires go, what streets they go under, what the connections between cables
are, each punch-down block, each manhole cover, the configurations of all
the phone switches, which wires connect to which line cards, and basically
everything that has ever been installed, who worked on it, what time, how
long it took, etc. Given that the local loops alone in the USA used 58
light-minutes of copper wire, you can imagine the kind of data you're
talking about.
I'm pretty sure they roll operational stuff out of the main databases after
six months or so, but I guess they still keep all the records somewhere.
> I think it could perhaps be safely assumed they use Oracle?
It's IBM mainframe DB2. Or was, 15 years ago. I don't imagine they changed
that, tho.
> I have read
> Oracle is about the only database system out there which scales up so much.
It probably has the best scale per dollar. I don't imagine it's going to
take advantage of mainframe features like IOPs and knowing which sectors are
on which cylinders of the hard disks and such. But mainframes still blow
away I/O driven applications by hundreds to one. Apparently, some people do
things like put dozens of Linux VMs on one mainframe,
> Or at least that's what the Oracle company wants us to believe in any case.)
I think IBM has the same sort of advertising. You just see it less because
it's not really targeted at minicomputer type installations.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > I think it could perhaps be safely assumed they use Oracle?
> It's IBM mainframe DB2. Or was, 15 years ago. I don't imagine they changed
> that, tho.
From the wikipedia page I get the impression that Oracle and IBM DB2 are
approximately the only two RDBMS systems which scale up well to the hundreds
of terabytes of data.
I wonder how eg. MySQL or PostgreSQL would handle such vast amounts of
data. Would they handle them ok, just maybe a bit slower, would they be
significantly less efficient, or would they simply fail? Or is it a question
of them not having such extensive support for the hardware required to
handle that amount of data efficiently?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> From the wikipedia page I get the impression that Oracle and IBM DB2 are
> approximately the only two RDBMS systems which scale up well to the hundreds
> of terabytes of data.
Cool.
> I wonder how eg. MySQL or PostgreSQL would handle such vast amounts of
> data. Would they handle them ok, just maybe a bit slower, would they be
> significantly less efficient, or would they simply fail?
"""InnoDB has a limit of 1023 concurrent transactions that have created undo
records by modifying data."""
I doubt you're going to get 70,000 transactions a second on a MySql
installation, altho I don't see anything about individual table sizes listed
in terms of number of rows.
The latest MySql seems to have a storage engine that talks to DB2 databases,
so I'm not sure if there's any significant difference there.
However, given that looking something up on an index on a 6-million-row
table took over a second on a 64-bit machine, I wouldn't want to put
billions of rows, let alone trillions, into a MySQL table.
> Or is it a question
> of them not having such extensive support for the hardware required to
> handle that amount of data efficiently?
I would imagine that since they're portable C et al, there isn't a whole lot
of support for (say) specialized hardware to run the disks. Mainframes have
chips for I/O just like desktop systems have custom chips for 3D graphics,
and if you don't take advantage of it, you get pretty average performance.
I don't know what kinds of things mainframes have nowadays, but I'd be
surprised if you didn't get serious performance enhancement by (for example)
coding up database tables to use raw I/O to the hardware. (Indeed, UNIX
database systems used to prefer to work on /dev raw disk type partitions,
rather than stuff in the file system.) Watch your performance die when one
of the top-level leaves in your busy B-tree winds up on a remapped sector on
the disk.
I think it's also the case that the number of places that need transactional
data that's actually that large is surprisingly small. I would guess that
most new businesses that need tens-of-terabytes databases don't need them to
be transactional. (As in, I expect you get very few race conditions trying
to update climate data in the multi-petabyte databases.)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > anyway, is it much of a hassle to use double to represent monetary values?
>
> Yes. It's not correct. Add up a billion dollars in penny increments, and
> tell me you can guarantee it's right.
To my knowledge that's not even the main issue:
Science cares about high precision.
Business doesn't give a damn about high precision, as long as rounding rules are
precisely followed.
Ever seen a "pocket" calculator for business use? They have extra switches to
set the rounding mode, e.g. fixed two digits, fixed five digits, or
what-have-you.
I once had to hack up some programs to run plausibility checks on records in an
insurance company "database" (well, individual files, but what the heck...
those were the database for the "worst case" contracts, that had been the last
to be ported to some newer software that hadn't been able to handle them
earlier, due to a lot of exceptional parameters in them).
I guess there wasn't a single record in the database where the plausibility
check did compute a perfect match for the values in the database. Not because
my program would have been imprecise - but because for simplicity I had left
out a huge number of rounding rules that I would have had to add otherwise.
In COBOL, the rounding rules are automatically enforced by the data format
description in the WORKING STORAGE SECTION.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Science cares about high precision.
And, actually, science usually doesn't care about high precicion for that
matter, either. Usually the accuracy is far less than the precision of a
single float, if you're talking about any sort of control application. Or,
in the words of one embedded control programmer I knew: "If you need more
than six digits of precision and you're not getting feedback to correct
errors, you've already blown up the wrong building."
Of course, there are *some* apps where having unlimited precision is a good
thing (POV-Ray springs to mind), but it's always going to be limited by your
input and output.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Business doesn't give a damn about high precision, as long as rounding rules are
> precisely followed.
That too. And you can't follow the rounding rules with floats. But if you
add up ten dimes, it better come out to a dollar. Whether you do that with
rounding or with decimal arithmetic, it doesn't matter much, but it's much
easier to know it works if you use decimal arithmetic.
One of the mainframes I first worked on has the "Scientific Computing Unit"
(floating point) and the "Business Computing Unit" (decimal arithmetic and
output formatting) as optional coprocessors.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"some 70% to 80% of UK plc business transactions are still based on Cobol"
What, exaclty, does that mean?
80% of transaction processing systems are COBOL?
80% of "UK plc businesses" use COBOL?
80% of business transactions "touch" at least one COBOL system somewhere
along the line?
This could be interpretted so many different ways...
http://www.99-bottles-of-beer.net/language-cobol-1820.html
It burns. IT BURNS!! >_<
What sick, sick person thought that
SUBTRACT 1 FROM Bottles GIVING Remaining-Bottles
is simpler than
let b' = b-1
?!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
