Re: Oracle General

Well, despite being an educator, I'll stab at it anyway.

Especially in the IBM environment, there were numerous confections of tools such as FOCUS (I will not repeat what our group's internal elaboration of that name meant) that could make flat files, VSAM and ISAM files, look somewhat like a database, to an extent.[YIKES, unintended pun.] Depending on whoever was in charge thought a database was, and what their thoughts were upon the word 'relational'.

Under VM/CMS or VM/SP or under a truck or steamroller, it is not an experience I would like to repeat again for at least 50 years.

It was fascinating to an extent, [this is awful to say, is IBI still around?], well, anyhow, it was fascinating it worked at all, in a multi-user environment. That's what sink machines are for. They queue the transactions and apply them. Eventually. We were thinking of Drano or some such to help.

In any case, it was not satisfactory for our needs, but IBI should not be blamed for it, nor IBM.

Prior to Oracle, and Informix, the only satisfactory quasi RDBMS I ever had my hands on was CDC's IPF2. It performed very well, but it was not truly relational, but then, this was 1980. And there was the bit about needing a CDC CYBER/170 to run it on, not something you generally find at Staples; needing the chilled water cooling and a $2-6 million USD price tag, and at times, parts of its hardware being considered controlled strategic items, kind of put a dent into the home video game market, with the armed guards and all.

(Or places you could manage to get lost in inside CDC and not get out of, and all you wanted to do was go get something out of the vending machines in the basement of Mod C.)

IPF2 was not ANSI compliant, but then, there wasn't anything much to comply with at the time. But it did a nice job of managing terabytes of data, and had a reasonably non-pukey interface; and, 64 bit words never hurt either. IM/DM / BASIS were also often used on the platform, as well as TOTAL - IS/ATHENA. BASIS was a textual DBMS that originated out of Batelle Laboratories' research; TOTAL of course came from CINCOM and IS/ATHENA was a more pleasant interface to it. (Which is to say, you did not have to write and compile / link a COBOL or FORTRAN program to talk to the database.)

I suppose a lot matters in what one considers a database to be. At one time, any abstraction above the file/record/field direct manipulation layer was considered as such, and welcomed. TOTAL was a pain, but was indisputably quite fast, I suppose somewhere between a network and hierarchical model.. HP ported it to MPE and called it I forget what, and I remember it running on Honeywell computers.

But the world did really change when the notion of tables and columns appeared; quite a few people had to smack themselves out of the politically incorrect terms of files, records, fields. I was surprised at the amount of psychic shock RDBMSes, well Oracle particularly (not Oracle's fault, just that we had lots of it) in the IBM-generation people that were used to ISAM, VSAM, IMS. I mean quite serious; we had a few people transfer out of our department because they could not cope (psychically, these were smart people) with the conceptual model. It didn't help slapping people with that and UNIX at the same time, I reckon.

Actually, we had to put up with quite a lot before things settled down again; we had INGRES, Informix, UNIFY, later on Oracle, and DB/2, IMS and other things running around the joint and it really was entirely too much, never mind 6 different operating systems, etc. Oh God, and NOMAD, and probably 5 or more others running loose.

In any case this is what Niall gets when he says something like 'can't imagine a database in a flat file'. I'd rather not imagine it myself, let alone remember.

Moving toward unification to at least ANSI SQL compliant, true RDBMSes was a major step that took over a decade and a half or so, for about 75% of our systems.

Collapsing toward a coherent O/S platform and gathering around a particular RDBMS took more years. We rather settled on UNIX, being able to get it on the cheap (since we wrote it) eventually, and things moved more or less toward Informix and Oracle.

Anyone that says a transition like that is seamless, painless, fast, or easy, should go boil their head. Oracle's gateway tools were a help; so were AT&T's proprietary data moving thingies like T-Tran and its successors in linking our IBM facilities with our UNIX data centers.

But SQL was definitely nice; SQL*Net and ODBC to hook up MS Access, Oracle's desktop tools, SQL Windows (a dubious benefit, if I may say so) and Powerbuilder let us have flexibility that was unimaginable, indeed unthinkable a mere decade before or so. I remember, because I remember fighting off some grotty technician who was trying to take away my CDC terminal and put this, this, THING on my desk. I believe it was called an IBM XT. "That stuff will never work out. The world needs mainframes for real work."

Isn't it odd that we have come full circle back to the thin client / centralized datastore-processing model? I remember mumbling to a Navy buddy of mine at an OOW out of the side of my mouth "er, isn't this what we used to call 'timesharing'?" 'Shut up, shut up, don't use the "T" word!'

RSH. "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:3cc80042$0$8507$ed9e5944_at_reading.news.pipex.net...
> For some reason i missed the earlier part of this thread so I apologize if
> all this has been covered already.
> "Sted Alana" <Sted_Alana_at_hotmail.com> wrote in message
> news:3cc7f075_1_at_news.iprimus.com.au...
> > "Katherine" <ktlang_at_prodigy.com> wrote in message
> > > In the early days, SQL 'standard query language' was originally
intended
> > as
> > > ASCII standard code, independent of operating system or rdbms.
however
> > > over time the standards have been stretched and there are flavors of
> SQL.
> > > Microsoft's SQL, although similar, is different enough to need a
> > conversion
> > > table.
>
> That should read ANSI standard (for A,merican National Standards Institute
> IIRC). There are several layers of compliance with the standard and none
of
> the RDBMS vendors fully comply with the full standard definition.
> > >
> > > SQL*Plus is Oracle's extension to the standard. It applies to only
> Oracle
> > > rdbms .
>
> SQL*Plus is a query tool analagous to Microsofts Query Analyzer.
>
> > However, Oracle SQL and SQL*Plus are operating system
> > independent,
> > > meaning sql code written on Dynix should work on NT.
>
> The SQL & PL/SQL will work except as far as it calls os dependent
routines -
> think external procedures, directory paths etc.
>
> <snip>
> > One last question regarding the query tools (SQL, SQL*PLUS, SQLLOADER,
> > PL/SQL etc.). To me it seems that the tools are a database itself
because
> > you can create tables that hold data (.sql files), so why need the
> database
> > part?
> >
>
> SQL & PL/SQL are not tools but languages. As to holding a 'database' in
flat
> files I'm completely at a loss as to know what to say. Perhaps one of the
> educators on the group can offer a comment.
>
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
> *****************************************
> Please include version and platform
> and SQL where applicable
> It makes life easier and increases the
> likelihood of a good answer
>
> ******************************************
>
>
Received on Thu Apr 25 2002 - 09:01:52 CDT