As for installing from the guides. I've done it many times, it does work. And they are extremely detailed. I often do look at websites for more information but the official oracle guide is my primary source.
I'm not young, I'm not a shill. Oracle's documentation is rather good. No one writes 100k+ pages of professional quality documentation per version and intentionally cripples it. Absolutely Oracle Press and other 3rd party writers do a good job in providing documentation, often because you have writers and not technical writers involved. And there is better up to the minute information in their various forums, no question.
But can you many products with better documentation?
That is kinda weird since DB2 has now used pricing as a strategy, "buy our hardware (Netezza) and get your DB2 licenses included". Which means AFAIK Oracle is now the most expensive product per CPU.
In terms of value... Oracle saves people a lot of money on hardware and telco at the high end. There just isn't any easy way to do a value computation because their just aren't the right kinds of competitors.
First off installing Oracle does not require guru knowledge. They write pretty good installation guides. Developers install Oracle for themselves all the time. I will agree it is much harder than SQLServer to install but that's a SQLServer strength.
Oracle is a professional product. It exists at the top end for people who want to be able to manually configure and tweak the database to get the most out of it. It also allows for complex configurations that the other systems don't. It the database server hardware cost is in 4 or 5 figures, and the configuration isn't extremely complex don't use Oracle. When you compare Oracle to SQLServer compare a setup of a database distributed over 4 continents involving $20m in server hardware because that's where all that complexity really shines.
I'm not sure what line you are talking about. There are a few references in the article to backup and recovery like, "In addition, you can back up and recover pluggable databases independently of the container database" which say nothing remotely like Oracle didn't have backup and recovery. The backup strategies that MySQL uses were developed by Oracle usually a decade or two before.
Sorry, you're looking from only one angle. It's not that they don't want to invest. It's that they don't want to make a complete change from the ground up all at once.
They don't have to do it all at once. There are a lot of good tools that help companies bridge over where they end up with a COBOL / Java hybrid for a time. A company with a system consisting of 3000 COBOL programs can be switching gradually. Refactoring is not reconstruction.
Look at the air traffic control system (NOT in Cobol!). It's old, it's outdated, it's straining under the load. Multiple projects have tried to replace it . . . and failed.
That's a different story. That is ground up recreation rather than refactoring. And the reason they fail is that old systems often involve institutional knowledge which the company (or government department) no longer posses. The 1960s air traffic control system was written by talking to air traffic controllers who ran the system by hand. Preforce they understood all the aspects of managing clusters of planes. Today's controllers are a subsystem that handles a particularly complex part of a mostly computerized system. Someone needs to look at that old code and work through what the 1960s air traffic controllers told the programmers of the 1960s.
If an old accounting system is still running, still doing its job, just like the pipes and wires in the walls, nobody wants to go change them just because they're not new.
Absolutely. But if an old accounting system is still doing its job then the company hasn't spent a lot on things like integrating ERP into their accounting system. Which means they aren's spending a lot on infrastructure.
I'm in a car. I use the same amount of energy to accelerate each second. Say acceleration is 5 mph/ sec^2 Time = 1, 1 energy used, 5 mph Time = 2, 2 energy used, 10 mph Time = 3, 3 energy used, 15 mph Time = 4, 4 energy used, 20 mph
etc.... Note that energy between 5 and 10 is a double and between 10 and 20 is a double not a quadruple. The energy required for instant acceleration is a square but that's not what's happening here.
and claimed it results in better service. ATT was known for many things but improving servcie was generally not one of them. You got what they offered and lived with it.
I think you can make a pretty good case that ATT offered excellent service. That list above. They didn't offer much choice.
The 5.25% came out of billings. But obviously: more investment -> more billable services -> more profit.
Call costs were very high, and ATT made it difficult for dial around providers such as MCI to serve customers because it threatened their lucrative long distance services.
Just to clarify that was societal policy to have long distance subsidize local. Again part of universality. It also strongly discouraged things like non-local telemarketing.
I don't claim that regulation does not benefit the public; just that the regulated gain a benefit that may be of great value to the regulated; despite their cries of "too much government interference."
No question. i've worked in a regulated industry. We get told pretty much what to do but had government guaranteed profits (more or less).
Cable is an interesting breed - once alternatives started to encroach on their territory they starting adding services and cutting prices
True but in that case the capital investment has already happened. The real question will be the 20 year record of areas with heavy competition relative to those without.
"It was character data. The compiler first packs the data to bcd, then uses decimal operations, then unpacks the result. Three instructions. Rollovers work just fine." http://slashdot.org/comments.pl?sid=3903963&cid=44106705
In any language where you platform independent file structures they are going to be portable. C is much lower level. But Java, Perl, Lisp are all equally or more portable than COBOL. I'd say COBOL is one of the least portable languages since so much of its use is tied to dictionaries which tend to be very machine (not just platform) dependent.
Do you really think that in this day and age an entire system is going to be nothing other than read from disk, process, write to disk? Yes, efficiency matters.
No efficiency on that level doesn't matter at all. Efficiency matters where CPUs can do something useful. A decimal conversion takes a few hundreds millionths of a second.
As for where I get the idea that cpus can do decimal arithematic, there are documents published by the cpu manufacturers. IBM calls theirs the Principles of Operation, Intel calls theirs Software Developer Manual. In these documents you will find the definition of the decimal instructions.
You are now claiming Intel does it to? You aren't reading whatever you are looking at carefully.
MOVE CORRESPONDING does not work consistently. Slight variants in the way the objects are defined can cause huge changes in what gets copied.
but if you're telling me that a language you make up on the fly by hiding the most important things is automatically better, I'll disagree bigtime.
I didn't say that. I said that accomplishing overloading of assignment is handled better in OO languages than COBOL. That there should be code for constructors.
I've seen things hidden in constructors that should have been in open code, with big flashing neon signs for comments, because they were so "clever" that nobody could ever fix them when they went wrong.
What does that even mean? A constructor is "open code" for someone debugging the library. For anyone else they shouldn't be fixing it.
In any case whatever is doing decimal operations can't be doing it on character data. If you mean that the data on disk is character data, that depends on the COBOL dictionary and the CPU. I've worked with uncompressing mainframe record data without using the OS conversion and the datatypes vary. Programmers on the system don't tend to notice this because the COBOL dictionaries take care of this for them. But if you pull it off as pure binary you get the underlying structures.
I'd like to see any disk what-so-ever that can read fast enough that a CPU can't do a translation like that faster than the system can read from disk. I've never seen any mention of this in things like the Hitachi emulators. So where are you getting this notion of CPUs doing decimal math and what's the point?
No if it was character data then the rollovers wouldn't have worked right. 1959 + 1 = 195(3*) where 3* is a superscripted 3 (remember this is EBCDIC so different stuff than in ASCII). It was numerical data. 0-99 is packed data on disk (generally 7 bits).
First off of course you are parsing it is just a built in decimal parser. CPU's don't do decimal math they do integer math so it has to be converted you are just doing it implicitly.
For example to read you (and really this is the library) write 1 time something like fun read2Digit (x) {
x =~/(D*)\.?(D*)/
if $2 return $1 * 100 + $2
else return $1; }
then you define that as the 2Digit's base reading type. So that when X 2Digit; X = read...
X will default to the read2Digit routine. similarly with output. And yes there are plenty of libraries that do this google "fixed precision math".
Move CORRESPONDING is fricking dangerous code. Getting something like that to work right is one of the central objectives of Object Oriented assignment operators. More or less... the equivalent in C++ is new
MOVE CORRESPONDING GROUP-1 TO GROUP-2
becomes
Group-2 x = new (y)// y is of type Group-1
but yes you will need to define how the constructor works explicitly because that is too dangerous otherwise.
Why? Mainframes far more modern, powerful languages and features. Why would you develop a brand new system in COBOL? What do people perceive as it getting them?
That's not entirely true. Client / server is very different than mainframe. Mainframe culture assumes the client is thin to non-existent client server just sees the server as a data repository that can answer request. The web is pretty close to mainframe.
Agreed. The companies / departments that are using COBOL are the ones that don't want to invest in their infrastructure which means they don't want to hire lots of people. There are going to be a small number of jobs forever but it will never be a job fest.
Huh? Data structures differ completely from system to system. Dictionaries are non standard. Calling mechanisms are non standard. Compilation procedures are non standard. Dependencies are non standard.
Take I/O printing are you outputting: record structures to a print system (of which there are many) EBCDIC formatted column 1 ASCII formatted EPSON record structures for metacode record structures for AFP....?
Slashdot Mirror
As for installing from the guides. I've done it many times, it does work. And they are extremely detailed. I often do look at websites for more information but the official oracle guide is my primary source.
I'm not young, I'm not a shill. Oracle's documentation is rather good. No one writes 100k+ pages of professional quality documentation per version and intentionally cripples it. Absolutely Oracle Press and other 3rd party writers do a good job in providing documentation, often because you have writers and not technical writers involved. And there is better up to the minute information in their various forums, no question.
But can you many products with better documentation?
That is kinda weird since DB2 has now used pricing as a strategy, "buy our hardware (Netezza) and get your DB2 licenses included". Which means AFAIK Oracle is now the most expensive product per CPU.
In terms of value... Oracle saves people a lot of money on hardware and telco at the high end. There just isn't any easy way to do a value computation because their just aren't the right kinds of competitors.
First off installing Oracle does not require guru knowledge. They write pretty good installation guides. Developers install Oracle for themselves all the time. I will agree it is much harder than SQLServer to install but that's a SQLServer strength.
Oracle is a professional product. It exists at the top end for people who want to be able to manually configure and tweak the database to get the most out of it. It also allows for complex configurations that the other systems don't. It the database server hardware cost is in 4 or 5 figures, and the configuration isn't extremely complex don't use Oracle. When you compare Oracle to SQLServer compare a setup of a database distributed over 4 continents involving $20m in server hardware because that's where all that complexity really shines.
I'm not sure what line you are talking about. There are a few references in the article to backup and recovery like, "In addition, you can back up and recover pluggable databases independently of the container database" which say nothing remotely like Oracle didn't have backup and recovery. The backup strategies that MySQL uses were developed by Oracle usually a decade or two before.
They don't have to do it all at once. There are a lot of good tools that help companies bridge over where they end up with a COBOL / Java hybrid for a time. A company with a system consisting of 3000 COBOL programs can be switching gradually. Refactoring is not reconstruction.
That's a different story. That is ground up recreation rather than refactoring. And the reason they fail is that old systems often involve institutional knowledge which the company (or government department) no longer posses. The 1960s air traffic control system was written by talking to air traffic controllers who ran the system by hand. Preforce they understood all the aspects of managing clusters of planes. Today's controllers are a subsystem that handles a particularly complex part of a mostly computerized system. Someone needs to look at that old code and work through what the 1960s air traffic controllers told the programmers of the 1960s.
Absolutely. But if an old accounting system is still doing its job then the company hasn't spent a lot on things like integrating ERP into their accounting system. Which means they aren's spending a lot on infrastructure.
It isn't that hard. The issue is v^2 energy.
I'm in a car. I use the same amount of energy to accelerate each second. Say acceleration is 5 mph/ sec^2
Time = 1, 1 energy used, 5 mph
Time = 2, 2 energy used, 10 mph
Time = 3, 3 energy used, 15 mph
Time = 4, 4 energy used, 20 mph
etc.... Note that energy between 5 and 10 is a double and between 10 and 20 is a double not a quadruple. The energy required for instant acceleration is a square but that's not what's happening here.
I think you can make a pretty good case that ATT offered excellent service. That list above. They didn't offer much choice.
The 5.25% came out of billings. But obviously: more investment -> more billable services -> more profit.
Just to clarify that was societal policy to have long distance subsidize local. Again part of universality. It also strongly discouraged things like non-local telemarketing.
No question. i've worked in a regulated industry. We get told pretty much what to do but had government guaranteed profits (more or less).
True but in that case the capital investment has already happened. The real question will be the 20 year record of areas with heavy competition relative to those without.
"It was character data. The compiler first packs the data to bcd, then uses decimal operations, then unpacks the result. Three instructions. Rollovers work just fine." http://slashdot.org/comments.pl?sid=3903963&cid=44106705
Wow. You should get an account. That's insane. Good fine anonymous.
As for the 286... OS/2 was written for the 286.
In any language where you platform independent file structures they are going to be portable. C is much lower level. But Java, Perl, Lisp are all equally or more portable than COBOL. I'd say COBOL is one of the least portable languages since so much of its use is tied to dictionaries which tend to be very machine (not just platform) dependent.
BCD isn't character data: http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD
If you don't know basic stuff about how your system works maybe you should stick to COBOL.
No efficiency on that level doesn't matter at all. Efficiency matters where CPUs can do something useful. A decimal conversion takes a few hundreds millionths of a second.
You are now claiming Intel does it to? You aren't reading whatever you are looking at carefully.
Read more carefully. Each byte contains more than one digit. It isn't character data. http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD
MOVE CORRESPONDING does not work consistently. Slight variants in the way the objects are defined can cause huge changes in what gets copied.
I didn't say that. I said that accomplishing overloading of assignment is handled better in OO languages than COBOL. That there should be code for constructors.
What does that even mean? A constructor is "open code" for someone debugging the library. For anyone else they shouldn't be fixing it.
M=F*A
V = A*T
Compilers don't pick data.
In any case whatever is doing decimal operations can't be doing it on character data. If you mean that the data on disk is character data, that depends on the COBOL dictionary and the CPU. I've worked with uncompressing mainframe record data without using the OS conversion and the datatypes vary. Programmers on the system don't tend to notice this because the COBOL dictionaries take care of this for them. But if you pull it off as pure binary you get the underlying structures.
This isn't Aquinas arguments for God. Working reliable in runtime on a particular machine is not tied to being "more perfect".
I'd like to see any disk what-so-ever that can read fast enough that a CPU can't do a translation like that faster than the system can read from disk. I've never seen any mention of this in things like the Hitachi emulators. So where are you getting this notion of CPUs doing decimal math and what's the point?
No if it was character data then the rollovers wouldn't have worked right. 1959 + 1 = 195(3*) where 3* is a superscripted 3 (remember this is EBCDIC so different stuff than in ASCII). It was numerical data. 0-99 is packed data on disk (generally 7 bits).
That's not a problem.
First off of course you are parsing it is just a built in decimal parser. CPU's don't do decimal math they do integer math so it has to be converted you are just doing it implicitly.
For example to read you (and really this is the library) write 1 time something like /(D*)\.?(D*)/
fun read2Digit (x) {
x =~
if $2 return $1 * 100 + $2
else return $1;
}
then you define that as the 2Digit's base reading type. So that when
X 2Digit;
X = read...
X will default to the read2Digit routine.
similarly with output. And yes there are plenty of libraries that do this google "fixed precision math".
Move CORRESPONDING is fricking dangerous code. Getting something like that to work right is one of the central objectives of Object Oriented assignment operators. More or less... the equivalent in C++ is new
MOVE CORRESPONDING GROUP-1 TO GROUP-2
becomes
Group-2 x = new (y) // y is of type Group-1
but yes you will need to define how the constructor works explicitly because that is too dangerous otherwise.
Why? Mainframes far more modern, powerful languages and features. Why would you develop a brand new system in COBOL? What do people perceive as it getting them?
That's not entirely true. Client / server is very different than mainframe. Mainframe culture assumes the client is thin to non-existent client server just sees the server as a data repository that can answer request. The web is pretty close to mainframe.
Agreed. The companies / departments that are using COBOL are the ones that don't want to invest in their infrastructure which means they don't want to hire lots of people. There are going to be a small number of jobs forever but it will never be a job fest.
Huh? Data structures differ completely from system to system. Dictionaries are non standard. Calling mechanisms are non standard. Compilation procedures are non standard. Dependencies are non standard.
Take I/O printing are you outputting: ....?
record structures to a print system (of which there are many)
EBCDIC formatted
column 1
ASCII formatted
EPSON
record structures for metacode
record structures for AFP
No it is not standard.